The main idea is to present leading innovators and their perspectives on eAccessibility from the technical, political, and economic side. Experts on seven panels will briefly describe their own work and their view of accessibility and then discuss the issues.

There’s an illustrious line-up of speakers including Deutsche Bahn, the European Commission, France Télécom, the German Federal Ministry of Labour and Social Affairs, Google, IBM, Microsoft, Mozilla, Opera, the W3C, the Web Standards Project, and Yahoo! talking about these topics:

• Accessible Web Applications
• Mobile Access — Device-independent or Accessible?
• Comparison of National Accessibility Guidelines
• Accessible Rich Internet Applications (ARIA)
• Web Standards and Accessibility in Higher Education
• Harmonising European Accessibility Guidelines
• The Business Value of Accessibility

If you have been following my posts in the last two years this will sound slightly familiar. Furthermore I’m honored to have Linda Mauperon, Member of Cabinet of the European Commissioner for Information Society and Media (Viviane Reding) as our keynote speaker. Please see the detailed description of the panels in the conference program.

We would like to take a look on accessibility from different perspectives presenting pioneering thinkers whose organizations have established accessibility in their business and communication long since — and making serious money with it. There should be something of interest for everybody among the topics: for techies, consultants, employees from universities and companies. The conference is limited to a maximum of 200 attendees. Registration opens next week.

Of course there are various gems under the hood of the website, too. Naturally it is extensively accessible (check the cool skip links), but it is also incredibly fast because Yahoo!’s best practices for frontend performance are regarded. There are separate style sheets for printing, for iPhones, and for handhelds. The CMS is WordPress µ, having the advantage of administrating both the English and the German version with the same installation.

You can see and download the slides at Slideshare (German). As I promised to write a detailed post about ARIA enhanced tab navigation for the Webkrauts web standards advent calendar (think of a German version of 24 ways) you will be able to enjoy an English tutorial soon. Never mind the references to Chris in the slides — I had to choose an example from my flickr pictures, and I believe there are too many presentations already with kittens.

The conference was surprisingly innovative: I half expected a crowd of suits as the event was co-organized by the Austrian Ministry of Health, Family and Youth, instead there were many young faces and a fair percentage of women. Things I have learned (and tweeted about) include:

• As of January 2009, websites sponsored by the Austrian Ministry of Health will only receive funding when they are accessible. That doesn’t come as a surprise as a European Ministerial Declaration in 2006 announced that accessibility and best practices could become mandatory in public procurement in 2010.
• Artur Ortega showed examples of Dirk Ginader’s accessibility features for Yahoo! Finance, including two input fields where the labels were dynamically updated after a currency was chosen. So a screenreader read “convert pound sterling to euros” instead of “convert currency to currency.”
• One reason for JavaScript enhanced HTML controls for Flash objects like Yahoo! video is that the Flash object cannot get tab focus when the wmode param is set to opaque or transparent. Still without that param it is impossible to tab into a Flash object in Firefox 3. Or did I overlook something?
• Designer Maria Putzhuber quoted an interesting delusion: 70% of designers believe that visitors are almost always able to maintain orientation while in fact just 10% of the visitors are able to achieve this. What do you think is the reason?

Deutsche Fassung

1. Older people have difficulties with drop-down and multi-level menus, because their manual dexterity, eye-hand coordination and space perception decreases. Also some move the mouse when clicking, or tremble, hence it’s more likely they slip off the menu. Hell, that happens to me frequently!

   However, did you notice the Windows Start Menu is more forgiving when you slip off an item? There’s a little delay before the secondary level is hidden. Perhaps we need an event-capturing script tolerating a slip from the menu rather than the immediate reaction of the mouseout event.

2. Nested menus are more complex. According to Hick’s Law orientation in a multi-level menu can take longer than multiple clicks in a flat menu with good information architecture. See an earlier article for the math.

3. The navigation must be accessible by keyboard alone. The result should be the same, whether you hover over an item or tab to it. So check for the focus event and CSS pseudo-class. Don’t forget to test backwards tabbing (shift tab). By the way, mobile devices have no mouse either…

   The tab order should be consistent and logical, i.e. not jumping around on a page. Also the focused item should be visible, for example highlighted with the default 1px dotted border some browsers draw around it. Some people think this is ugly and remove the default border. That is a no-no.

   And if you really want desktop behavior, add support for the arrow keys (event.keyCode 37-40). Keep in mind though that screen readers have predefined functions for the arrow keys in combination with the ctrl, shift, or alt keys. In JavaScript those keys can be detected with the event.ctrlKey, event.altKey, and event.shiftKey properties. Also crossbrowser event delegation for focus or blur events can be a bitch, thankfully PPK has a solution.

4. Users of AT should have means to skip content. That’s possible with semantic markup: a menu as (nested) list(s) enables them to jump to the next block. Also there should be a few skip links at the beginning of the code pointing to important sections on the page, such as content, navigation, or search. Mobile users also profit from that technique (try surfing eBay with Opera Mini ).

5. Pages never link to themselves. When I click on a link (the menu being no exception) I expect to land on a different page. Therefore it’s confusing to land on the same page. This happened to me recently when I was filling out a form on my mobile phone and got the same page with an error message. It took me a while to realize where I was. It’s the same whether you have a tiny screen or a low screen resolution to see things larger when you are visually impaired: you only see a small part of the page, so it’s hard to realize when something unexpected happens.

6. You can add some semantic sugar with the ARIA role property. In this case <ul role="navigation"> would be appropriate. I strongly encourage you to use ARIA as it is widely supported by browsers and screen readers, enhances a disabled user’s experience, and doesn’t break old browsers. A most recent introduction has been written by Gez Lemon for the Opera Developer Community.

7. If a second level navigation is initially hidden with display:none it won’t be in the screen reader buffer. Therefore off-screen positioning is a better idea, else you need to update the buffer by writing random values into a hidden input field.

8. A common problem in menus is limited horizontal space. Text should be scalable, and it must not jut-out into other page elements when it is enlarged. Even normal text can break a narrow menu when you think of internationalization. In German there are many composite words. While building a website for a competing brand I came across a menu item on the Philips website for “male grooming.” The German word „Körperhaarpflegesystem” is guaranteed to blow every menu!

   Another common problem that prevents scaling in menus are text graphics. I know marketing just loves to see the corporate font in the main menu, but text in images can’t be scaled, people with visual impairments can’t change text and background colors for higher contrast, and Flash Image Replacement like sIFR still has accessibility issues, is known to distort fonts, is CPU intensive and slow. The bottom line is: don’t use text as images, make textual information text.

So much for accessibility. Besides there are a few technical issues to consider: mobile devices often have problems with JavaScript or with layers. Some proxies in large companies filter JavaScript for security reasons, so you can’t rely on the ubiquitous availability, your script has to be unobtrusive, and you can’t rely on noscript either. Don’t even think of creating a menu from JavaScript arrays.

Moreover there’s a well-known bug in IE6 responsible for showing select lists always in front of any layers (like your second level menu), regardless of a z-index. Thankfully there are plugins like bgiframe for jQuery to solve this. Multi-level menus can bloat the code, event handling can be CPU intensive (use event delegation). And if large amounts of menu code is at the beginning, the real content gets further behind and less relevant for search engines.

In conclusion, for an alleged quicker entry you pay with many disadvantages. Often drop-down menus just conceal a poorly planned information architecture. I would reconsider their usage.

Did I forget something? What’s your opinion on drop-down menus? Love them or hate them?

Other conferences

The next geek meeting held in Frankfurt will be the Webmontag (Web Monday) on September 1st where I will give my presentation about canvas a short test drive.

A few days later on September 4 I have the honor of the opening talk at the Web Congress at the University of Erlangen, again about canvas, only this time a full hour.

On September 25 there’s the Best of Accessibility Symposium in Düsseldorf where I hold a workshop about hands-on ARIA (you recognize the pattern?).

On October 10-11 an internal namics conference called T-Camp is held in Basel, with my colleague Alex Stirn and me speaking about Professional Frontend Engineering.

A conference I’m looking forward to because of the many experts attending and the fair prices is the A-Tag (Accessibility Day) in Vienna, Austria, on November 21. Again I will sing praises of ARIA. This innovative technique can’t be evangelized enough! There’s no website yet for the A-Tag, but I’d recommend to book your journey well in advance to catch the inexpensive flights to Vienna. The conference itself cost only € 35 last year is free because it is sponsored by the Austrian government.

If you happen to be around, don’t hesitate to speak to me.

Also ARIA became a bit of a buzz since only three days before Microsoft announced support for it in Internet Explorer 8. So there is partial support in Firefox 1.5, more in Firefox 2.0, and full support including liveregions for dynamically updated content in Firefox 3.0. Also Opera 9.5 has it. It can be used today as it doesn’t break old browsers, they will simply ignore the new attributes. Don’t hesitate, you can do good with it right now.

In the meantime Aaron Leventhal and his fellows were busy negotiating with members of the HTML5 working group to find a way of implementation without namespacing. So as of Firefox 3.0 it will be <img role="checkbox" aria-checked="false" /> instead of the previous namespaced notation aaa:checked="false".

Microsoft also thought about addressing the new attributes in the DOM, alas they did it the old proprietary way instead of sitting at a virtual or real table with the other browser vendors and thinking of a common way to do this. Opera’s Anne van Kesteren and the participants at the Browser Wars panel at SXSW were picking heavily on that subject. I believe the IE team got the message, but for the moment I would suggest to ignore the non-standard DOM attributes.

Thanks again to Gez, Becky, Lisa, and Shawn for their input and help. You made this a first-class experience!

Further reading

• W3C WAI-ARIA Overview
• Mozilla Developer Center ARIA FAQ
• A List Apart: Accessible Web 2.0 Applications with WAI-ARIA

When I started to work for BlueMars, most of the websites still had table layout, but my colleagues soon adopted CSS floats. They did a brilliant job, and after a while everything we produced was semantic and validated. We even did some guerilla accessibility without the project managers or clients knowing, but appreciating the cleanness of the code anyway.

Then came the day when Web Standards Project colleague Glenda Sims asked in her blog “do you love your job?” And I had to admit I wasn’t challenged anymore. I was still learning new things, but my daily work offered few opportunities to implement them. What I really wanted was building accessible, inclusive websites in a company that understood the challenges and consequences of Web 2.0 — an enterprise 2.0 looking for staff 2.0. Where I wouldn’t “run against walls” so often. Where empathy wasn’t just something left to the Dalai Lama.

My new employer is the Swiss company namics, in particular the branch office in Frankfurt. Since Yahoo! was always a benchmark for me — with their openness, their attitude of sharing, their communication — I was surprised to find a European company apparently performing great against those benchmarks. They have internal and external blogs and wikis, they hold internal barcamps and encourage people to speak at conferences. Some of them participate in the technology and usability juries of the Best of Swiss awards, and their CEO is also on the managing committee of the Swiss Library for Blind and Visually Impaired People.

My first job will be accessible, with the client not only knowing, but actually asking for it. Also in March they send me over to SXSW where I will hold a core conversation together with Gez Lemon about Accessible Rich Internet Applications. I’m really looking forward to work for namics. It feels like coming home, already. Thanks to Glenda Sims and Jessica Feldmann for unknowingly encouraging me to take that step. And yes, I will continue to blog here as I own this domain now.

Otherwise the draft’s abstract and introduction are vague and leave room for interpretation what this is exactly about. What I have understood is:

1. This module defines a new element with the name access.
2. The element can be used to define an access key for any other element.
3. Another usage could be as a skip link as there is a targetid and targetrole attribute.

For me it remained unclear whether this element belongs in the head like link elements, or in the body like anchors or label elements. Anyway, among other Common attributes it can have a title plus a few new attributes: key, targetid, targetrole, and activate.

• The key attribute is optional and defines an access key in a generic way. So far there was only the accesskey attribute for anchors and form elements, now any fancy Web 2.0 div element impersonating something else can receive focus by striking a key. Browser vendors are encouraged to emphasize the responsive character in a word, like underlining it. Also the working draft provides a description what user agents should do if there are conflicts with existing shortcut keys. So the team paid attention to the discussions about the reasonableness of the accesskey attribute.
• The targetid and targetrole attributes assign targets by id or role. There can be more than one of each, comma separated. I imagine that’s like tabbing through elements, but with a shortcut key.
• The last new access attribute is activate. I must admit I have no clear idea what “activate” could mean or what this attribute is good for. An element receives focus, so there should be a perceivable effect, some sort of feedback to the user. If an author does not want this, there are ways to suppress default renderings by CSS. If she doesn’t want the focus event to trigger something, there’s JavaScript to cancel it.

I thought of playing with the new element, but it’s too early for a test implementation. The working draft still lacks a XML Schema that could be used in namespaces. It would be possible to extend a DTD without much conflicts, alas the module doesn’t come in one box, but in two (again). So you would need to append both the qname module and the access module instead of simply adding the access module. I don’t understand the rationale for this separation, but I see it’s more painful for an author to implement it that way.

However, the access element provides a better and more generic functionality than existing alternatives, it fills the gap of missing access keys, and if I got it right it defines a standardized method for skip links, although this could be expressed clearer. Apart from the usual suspects there is Google’s accessibility specialist T. V. Raman on the team, and Richard Schwerdtfeger from the team that built more accessibility into Firefox, the Open Document Format, and IAccessible2 as an accessibility interface for screen readers. So my bet is we will see support for this element in our favorite browser as soon as this draft is more mature. Your turn, Microsoft.

South by Southwest (SXSW) is a huge conference for interactive media as well as a film and music festival in Austin, Texas, March 7-11, 2008. Every year it attracts the best designers and developers, and there is an immense number of panels to choose from. Exactly 128, out of which 80 are chosen from an open submission process.

Gez Lemon and I plan to run a panel called “Get Rich, Remain Accessible,” naturally about WAI ARIA (Accessible Rich Internet Applications). Gez wrote a great article about ARIA liveregions, and I wrote that article at A List Apart, so it’s the perfect team. Together we would like to present:

1. The accessibility problems introduced by the current trend of web applications,
2. new ways to add semantic meaning, communicate importance, define relationships, and give focus to elements using WAI-ARIA,
3. how to limit the impact of these problems whilst WAI-ARIA is gaining support by user-agents, and techniques that work right now.

It would be nice if you took the time to vote for us at the SXSW panel picker application. The voting process is open until 11:59 pm, September 21. If you push our presentation to the top 80 you will ensure Gez and I actually make every effort to attend the conference as we will get free tickets for ourselves. Spread the word …

The W3C’s standards draft for Accessible Rich Internet Applications (ARIA) addresses those limitations. It provides new ways of communicating meaning, importance, and relationships, and it fills gaps in the (X)HTML specifications and increases usability for all users by enabling navigation models familiar from desktop applications. Best of all, you can start using ARIA right away to enhance the accessibility of your websites.

I held talks about the upcoming standards in Cologne and Frankfurt, which resulted in writing a blog entry about the topic that eventually became an article for A List Apart.

Update: there’s also a German translation of the article at Barrierekompass.

If you’d like to learn more I’ll be speaking at the BarCamp in Frankfurt on April 21-22, and the Infopark Internet Congress in Berlin on May 11th.

Speakers

• Richard Schwerdtfeger (IBM)
• Marian Oosting (anderslezen.nl)
• Chris Heilmann (Yahoo!)
• Miguel González-Sancho (European Commission)
• Michael Cooper (W3C WAI)
• Dominique Hazaël-Massieux (W3C Mobile Web Initiative)
• Dave Wilton (Legal & General)

Richard Schwerdtfeger works for IBM and is a member of the W3C WAI and the HTML working group, among others. I assume he had been invited because the organizers only knew him for having developed IBM Home Page Reader back in the 1990ies. But his current work involves the W3C working drafts for Accessible Rich Internet Applications (ARIA) and other core technologies that his team developed in cooperation with vendors of Assistive Technologies (AT, e.g. screen readers) and the Mozilla Foundation.

There’s a paradigm shift in the usability and accessibility of Web 2.0 applications. ARIA adds meaning, importance, relationships, fills the gaps in (X)HTML, and increases usability for all users through familiar navigation models from desktop applications.

From Marian Oosting (anderslezen.nl) I learned about DAISY. It’s a library standard mostly used for talking books for the blind. Based on MP3 and the W3C XML standard SMIL, it combines strong compression with superior navigational features. Quite intriguing to use that format for audio books, and since 2006 it’s becoming available and more attractive for non-disabled users. For example, talking books are quite popular with elderly people who constitute about 60-80% of public library users.

In his presentation Chris Heilmann (Yahoo!) emphasized the need to ask people with impairments because they use assistive technologies in other ways than a non-disabled developer might foresee. Don’t assume, integrate their advice!

Miguel González-Sancho (European Commission, Information Society Directorate General) presented the European programs for e-Accessibility, e-Aging, and e-Inclusion. ICT is becoming essential for socio-economic participation, yet 40% of the European population is left behind. Functional limitations and disabilities increase due to aging. About 20% or 100 million of the European population is concerned. Thus accessibility is gaining relevance and becomes a social imperative.

In “Web Accessibility in the Future” Michael Cooper (W3C WAI) was rather giving the big picture and avoided to announce a release date for WCAG 2.0. Although the updated version will definitely play an important role in the future of accessibility, so does the development of a common Accessibility API or authoring interfaces that generate accessible content (ATAG). Think of user contributed content where the authors are usually unaware of accessibility requirements. Moreover, professionalization of accessible design, programming, and manual and semi-automated evaluation will gain importance. We must keep an open eye on developing technologies (MathML?, Second Life?), advocate accessibility in early stages, and keep accessibility awareness in legislation and society.

Dominique Hazaël-Massieux (W3C Mobile Web Initiative) talked about the mobile web, of course. There are more mobile phones than computers, they are cheap, and about 80% of the world population has mobile network coverage. Mobile access is everywhere, will become ubiquitous. There are some limitations like the tiny screen, the lack of a proper keyboard, diversity is large and access slow. In fact mobile and impaired users have so many challenges in common that Dominique estimates an accessible website already meets half the requirements of the Mobile Web Best Practices. Bad news for militant accessibility advocates who keep emphasizing the differences between accessibility, universal access and device independence.

Dave Wilton from the large British financial services supplier Legal & General gave some real world examples why it literally pays to become accessible:

There are nine million people with disabilities in the UK. If 1% just bought a £300 policy, his company will make £27 million: “The cost of making the site accessible pales into insignificance.” If people can’t buy from Legal & General, they will go to their competitors. In surveys, helpdesk and logfile analyses they found 10% of their visitors don’t make it past the home page. That’s equivalent to slamming the door into the faces of 20,000 visitors each month. 30% never open a PDF file. Besides, every third Briton is older than 50, and as we have heard before, the incidence of disabilities increase with age. There are not only people with cognitive impairments, but also 3 million people who speak English as a second language, 1.5 million people lacking basic language skills, and 5.2 million adults who have sub-GCSE level English.

Next time somebody tells you “disabled people are not our target group” show ‘em these results:

• Online traffic surged with a 50% increase in natural search engine listings.
• The number of visitors receiving quotes increased by 100% within three months.
• The new content management system cut site maintenance costs by 66% with an annual saving of £200k.
• Without changing products or prices, conversion rates improved substantially, ranging between 26% and 300% increase with an average of 200% (something Jakob Nielsen seconds).
• The entire project delivered 100% return-on-investment (ROI) within just 12 months.
• Customer satisfaction was improved (not one accessibility complaint!)
• It was great PR!