First I talked about the term of disability in a changing social and political context, then I lead to the demographic trend, hence to accessibility as an economic imperative. I showed a few barriers and techniques in practical examples as “virtual wheelchair ramps” and ended with an outlook on the challenges we currently face in the W3C HTML Accessibility Task Force.

The slides are currently available only in German at Slideshare where they can also be downloaded (15 MB). I will further adapt the slides and translate them for a Mozilla P2PU course in September, I appreciate your patience. There are also notes in the powerpoint file for a more detailed description.

But the story continues: beginning in the winter semester I’ll have a lectureship once a week at the university, teaching organic frontend development with contemporary techniques.

1. What are the issues of accessibility in HTML 5?
2. What is the canvas element?
3. What is the difference between video built in natively in the browser or provided through a Flash plugin?
4. Why are people in the HTML 5 working group so nasty to each other?
5. Why is accessibility important in an emerging standard?
6. Can’t accessibility be added later?
7. What is the state of support of HTML 5 in browsers?
8. When can we start to use HTML 5?
9. What can geolocation do for accessibility?
10. Does assistive technology support HTML 5 features?

So please vote for it now, and while you’re at it, show your love to some other accessibility and web standards proposals as well. </thxkbay>

The rules: a haiku “is a form of Japanese poetry, consisting of 17 moras, in three metrical phrases of 5, 7, and 5 moras respectively.” I think it’s legitimate for the sake of simplicity to translate “moras” with “syllables.” A reference to a season or nature is a bonus.

A crude example, my Japanese readers may forgive me:

Show us the studies /
says hixie, experts shout fail. /
It’s about people.

And another:

For assistive tech /
canvas is invisible /
like tears in the rain.

So here is my challenge: twitter a haiku about HTML 5 and tag it with #html5haiku. There aren’t any prizes yet apart from the innocent fun of participation, but perhaps somebody would like to donate something?

• A link to Google Maps when JavaScript is disabled.
• Support for the Google AJAX API Loader.
• Using the small map control.
• Keyboard accessibility for all control elements within the map.

As a fallback without JavaScript — because people disable it, because their mobile device doesn’t support it, or because it gets filtered by corporate proxies — Patrick used the little known Google Static Maps API, but for some reason he missed adding the link to Google. Here is the fix:

1. <div id="map">
2. <a href="http://maps.google.com/maps ?f=q&amp;output=html &amp;q=50.110950+8.684666" title="Google Maps">
3. <img src="http://maps.google.com/staticmap?hl=en &amp;center=50.112267,8.678384 &amp;markers=50.110950,8.684666,red &amp;zoom=15&amp;size=500x300 &amp;key=[Your API Key]" alt="City map of Frankfurt" width="500" height="300" />
4. </a>
5. </div>

Then I changed how the map is embedded. As it seems that the API loader is more current, I preferred that way:

1. <script type="text/javascript" src="http://www.google.com/jsapi?key=[Your API Key]"></script>
2. <script type="text/javascript" src="/js/accgmap.js"></script>
3. <script type="text/javascript">
4. google.load( 'maps', '2', { 'language' : 'en' } );
5. google.setOnLoadCallback( GMAP.initMap );
6. </script>

Using the small control elements is trivial: SmallMapControl(). The next thing I wanted to change was keyboard access to all controls, in particular for the map type, i.e. Map | Satellite | Hybrid. Patrick refers to an id, but I found that all relevant controls have a title, so I just checked for that attribute. I also dropped setting the style attribute in JavaScript as that belongs in the CSS file. His original function GKeyboardPatch() now looks like this (note the while loop for a slightly better performance):

1. GKeyboardPatch: function( map ) {
2. var button, divs = map.getContainer().getElementsByTagName( 'div' );
3. var i = 0;
4. while ( divs[i] ) {
5. if ( divs[i].getAttribute( 'log' ) || ( divs[i].getAttribute( 'title' ) && divs[i].getAttribute( 'title' ) != '' ) ) {
6. button = document.createElement( 'button' );
7. button.setAttribute( 'value', divs[i].getAttribute( 'title' ));
8. divs[i].appendChild( button );
9. if ( divs[i].getAttribute( 'log' )) { // only control buttons
10. // override the IE opacity filter that Google annoyingly sets
11. divs[i].style.filter = '';
12. // should really set to 'transparent'
13. divs[i].style.background = 'url( http://www.google.com/ intl/en_ALL/mapfiles/transparent.png )';
14. }
15. }
16. i++;
17. }
18. }

Now remember I said I’d rather separate style and behaviour, so here are a some lines of CSS with the setting of width and height for the #map being most relevant, otherwise it will collapse:

1. #map {
2. height: 300px;
3. overflow: hidden;
4. position: relative;
5. width: 500px;
6. }
7. #maps-static, #maps-static img {
8. display: block;
9. }
10. #map span.note {
11. display: none;
12. }
13. #map button {
14. background: transparent;
15. border-style: solid;
16. border-width: 0;
17. cursor: pointer;
18. height: 100%;
19. left: -2px;
20. margin: 2px;
21. overflow: hidden;
22. padding: 2px;
23. position: absolute;
24. text-indent: -100em;
25. top: -2px;
26. width: 100%;
27. }
28. #map a:focus, #map a:active, #map button:focus, #map button:active {
29. outline: 2px dashed #61bf1a;
30. }

And that’s it, thanks again to Patrick for the solid foundation I built upon. Now download the JavaScript code and try to tab through the map below.

Actually on the other website I extracted hCard microformats from the page as well and displayed the addresses on the map, but I was lazy and used jQuery. I thought it doesn’t look well here mixed with Patrick’s clean DOM scripting, but feel free to take it from the original website.

I was responsible for most of the programming beneath the navigation bar on the home page, and every time when I book a ticket there’s a small feature I enjoy so much I want to tell you about it: the buttons on the date selector are really, really tiny (16 × 8px). As you know thanks to Fitt‘s Law, there are even formulas to calculate how much better big buttons can be hit.

So I just added some padding. And that makes a huge difference: try to click on the same buttons later on in the booking process where the padding is missing.

If I could make one improvement I would add keyboard functionality to those buttons. Alas as the datepicker itself came from a third party, the assembled code was beyond my control. But I know that the Deutsche Bahn is listening to the needs of people with disabilities and their disability advisory board members are highly competent, so I trust these and other issues will be fixed soon …

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

Now there’s light at the end of the tunnel: a few days ago Apple filed a patent for multi-touch in combination with features such as voice commands and speech recognition, facial recognition, gestures, fingerprint input, body temperature, heart rate, skin impedance, and pupil size.

With that range of input possibilities, accessibility on the iPhone (and on other devices) could be significantly improved. Also other visionary devices come into range, like the Charmr for diabetes management.

The Charmr was a great design study by Adaptive Path, although a touch screen is a problem for people with diabetes who are more likely to develop vision impairments and lose tactile sensitivity. Speech recognition is an obvious solution.

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.