d.construct, Accessible Web Applications In A Post Web 1.0 World

A presentation by Derek Featherstone

[Derek waves his arms and steadfastly refeses to use the phrase "web 2.0"!]

Derek is an accessibility expert who is trying to get the message across that, even in a web2.0 world, accessibility should still be a goal, and and achievable one.

The web now is moving towards functionality and applications, and away from the document-centric approach. To make apps accessible, it is vital to separate the app into three distinct areas:

• Content (eg semantic, standards-compliant XHTML)
• Presentation (CSS does all the hard work)
• Behaviour (javascript, AJAX or other behavioural language)
  

All too often, 1 and 2 are adhered to, but 3 still remains buried in the page, and therefore accessibility issues begin to kick in. What happens when someone doesn't have JavaScript enabled? Can they still see the content, etc.

One common example Derek mentioned was the default text you often find in a search box, which some JavaScript removes when the element gets focus. What happens if you're a blind user who fills in the box, tabs to the next form element, decides to tab back to the first, and can't understand why the text they thought they'd typed had disappeared!

Fix senarios - either make the JavaScript check, and ONLY removed the default text, but retain the user-input text. Or, perhaps don't use default text at all, but instead use a Tool Tip on the form element to give some more information.

Similarly, validation error messages should always appear near the form control they validate. If you put it at the top of a page, and a user has the screen hugely magnified, they will never see the error text as it's well out of their portion of the viewport. Perhaps changing the background colour of an element which fails validation could also be useful.

So if it's easy to get such simple things wrong, what about applications using AJAX which can be very complex? The answer is, wherever possible, to try and make the content linearised within the page by setting tab orders etc to "lead" users through their application journey in a sensible way.

Tabindex="-1" might sound like an invalid value, but it is supported by IE and Firefox. It can be programmatically, as it does not show up in a tab set, but you can use it to force focus onto an element.

Drag and Drop interactions are great for the mouse-enabled community, but pretty hopeless for those only using a keyboard. So don't make it the ONLY way of doing something. Also, make the "hit area" of links or things to drag as large as possible, so that users with impaired mobility don't have to be so accurate with their mouse movements.