My Web Directions 2006 experience started on Thursday with a workshop: Accessibility 2.0 with the inimitable Derek Featherstone.

Derek used to be a high school teacher and I think he must have been a good one – he holds the attention of the audience very well and makes accessibility interesting, even to the fully-sighted, mouse-wielding power users that most web developers are.

Why Accessibility 2.0?

The web 2.0 phenomenon has led to a massive increase in smart and sexy web applications that use Ajax to provide a slick, responsive interface – the functional web rather than the traditional, document-based web. But as with all things, just because you can doesn’t necessarily mean you should, and in some cases accessibility is falling by the wayside. Fortunately, there are ways to make web applications available to users of assistive technology such a screen readers, voice recognition software and alternate input mechanisms. For the workshop, Derek focused on a number of common problems in web applications using real-world examples, and then showed some techniques to provide the same functionality in an accessible way.

The Accessibility/Usability Cross-over

The first topic covered in the workshop was the cross-over that exists between accessibility and usability. Many accessibility issues could also be called usability problems, and vice versa. Often, fixing an obvious accessibility problem also improves the usability of an application for all users.

An interesting and unexpected point Derek raised was that in certain cases, creating an alternate version of a particular feature of an application specifically for users of assistive technology is the only way to provide a great experience for all users.

A web standards approach facilitates accessible applications

While it’s not a magic bullet, using valid code and separation of markup, presentation and behaviour (the dubious-sounding “three-legged stool” of web standards) goes a long way towards facilitating accessible applications, and the same thing can be said for usability. At the very least, web standards provide a solid foundation with which work from. Of course, being a web standards-focused audience, this didn’t surprise anyone, but it’s a nice affirmation.

Myths about screenreaders

Many web developers believe that providing a version of an application that works without JavaScript equates to providing an accessible version. This is simply not true – screenreaders work with modern browsers – Internet Explorer and Firefox, primarily – and they are able to access content provided by JavaScript. Derek demonstrated a common Ajax technique for providing form validation, and the screenreader read out the validation messages.

Simple problems with simple solutions

Most of the examples presented in the workshop were simple problems with simple solutions, but pointed to what would become the mantra of the session: proper user testing with assistive technologies is critical to making an application accessible. Real people do things that no web developer will ever anticipate.

The Hijax technique was briefly discussed – and I learnt more about this on Friday at Jeremy Keith’s session. Essentially, it means first making a regular application which functions without JavaScript, then using progressive ehancement techniques to add a behaviour layer to “hijack” standard links, form submissions etc at particular points and substitute Ajax functionality. If an application used this approach from the beginning, the task of ensuring it was accessible would be a lot simpler.

Some of the examples covered:

• Forms for tables
  • Problem: screenreader has problems associating labels with inputs
  • Solution: add semantic labels, drop the tables, user correct source order then absolute positioning to adjust the visual layout

• Changing elements using JavaScript
  • Problem: a form input area had default text which was cleared when the input received focus, but when focus was removed and then returned to the element, the user-entered text was also cleared
  • Solution: only clear input if default text is detected

• Voice recognition and alt attributes
  • Problem: voice recognition software couldn’t activate a menu image link where the alt text was different from the visual representation of the word
  • Solution: Make the alt text match the image

• Non-semantic elements
  • Problem: keyboard navigation between links not working in Google maps
  • Solution: using a proper anchor element rather than a styled span with an onClick handler

• Using colour to indicate change
  • Problem: Basecamp-style colour flashes inaccessible to visually impaired and users simply not paying attention at the exact moment they occur
  • Solution: rather than relying on the colour change, also change some text or use some other permanent visual marker.

More complex Ajax problems

Not all accessibility problems posed by web applications are so easily fixed. A major issue is how to make sure that when the contents of the page is changed using JavaScript (the basis of most Ajax apps), screenreaders and other assistive technologies are aware of the change.

Derek ran through a few examples using Basecamp lists and a form validation sample, but the results were not consistent – essentially, the only way to know for sure if an application is truly accessible is to test it with assistive browsers. If a particular technique doesn’t work, try another – there’s plenty to choose from!

Finally, Derek ran through an inaccessible, complex multi-step form and discussed areas that he was changing to make it accessible.

Now go away and do this…

I wrote four notes at the end of the session:

• Planning
  • Plan for accessibility at the beginning of the process, rather than at the end

• Do the simple stuff right
  • Layout forms correctly, validate html and markup

• Semantic interaction
  • Use the right elements for the job – e.g. links should be anchors

• Provide “options”
  • Accessibility has the potential to help all users
• And always test test test

Derek’s workshop was informative and entertaining – it’s always a real privilege to listen to him speak. I learnt lots and have heaps of tips I can start using in my work right away.