My Web Direc­tions 2006 expe­ri­ence started on Thurs­day with a work­shop: Acces­si­bil­ity 2.0 with the inim­itable Derek Feath­er­stone.

Derek used to be a high school teacher and I think he must have been a good one — he holds the atten­tion of the audi­ence very well and makes acces­si­bil­ity inter­est­ing, even to the fully-sighted, mouse-wielding power users that most web devel­op­ers are.

Why Acces­si­bil­ity 2.0?

The web 2.0 phe­nom­e­non has led to a mas­sive increase in smart and sexy web appli­ca­tions that use Ajax to pro­vide a slick, respon­sive inter­face — the func­tional web rather than the tra­di­tional, document-based web. But as with all things, just because you can doesn’t nec­es­sar­ily mean you should, and in some cases acces­si­bil­ity is falling by the way­side. For­tu­nately, there are ways to make web appli­ca­tions avail­able to users of assis­tive tech­nol­ogy such a screen read­ers, voice recog­ni­tion soft­ware and alter­nate input mech­a­nisms. For the work­shop, Derek focused on a num­ber of com­mon prob­lems in web appli­ca­tions using real-world exam­ples, and then showed some tech­niques to pro­vide the same func­tion­al­ity in an acces­si­ble way.

The Accessibility/Usability Cross-over

The first topic cov­ered in the work­shop was the cross-over that exists between acces­si­bil­ity and usabil­ity. Many acces­si­bil­ity issues could also be called usabil­ity prob­lems, and vice versa. Often, fix­ing an obvi­ous acces­si­bil­ity prob­lem also improves the usabil­ity of an appli­ca­tion for all users.

An inter­est­ing and unex­pected point Derek raised was that in cer­tain cases, cre­at­ing an alter­nate ver­sion of a par­tic­u­lar fea­ture of an appli­ca­tion specif­i­cally for users of assis­tive tech­nol­ogy is the only way to pro­vide a great expe­ri­ence for all users.

A web stan­dards approach facil­i­tates acces­si­ble applications

While it’s not a magic bul­let, using valid code and sep­a­ra­tion of markup, pre­sen­ta­tion and behav­iour (the dubious-sounding “three-legged stool” of web stan­dards) goes a long way towards facil­i­tat­ing acces­si­ble appli­ca­tions, and the same thing can be said for usabil­ity. At the very least, web stan­dards pro­vide a solid foun­da­tion with which work from. Of course, being a web standards-focused audi­ence, this didn’t sur­prise any­one, but it’s a nice affirmation.

Myths about screenreaders

Many web devel­op­ers believe that pro­vid­ing a ver­sion of an appli­ca­tion that works with­out JavaScript equates to pro­vid­ing an acces­si­ble ver­sion. This is sim­ply not true — screen­read­ers work with mod­ern browsers — Inter­net Explorer and Fire­fox, pri­mar­ily — and they are able to access con­tent pro­vided by JavaScript. Derek demon­strated a com­mon Ajax tech­nique for pro­vid­ing form val­i­da­tion, and the screen­reader read out the val­i­da­tion messages.

Sim­ple prob­lems with sim­ple solutions

Most of the exam­ples pre­sented in the work­shop were sim­ple prob­lems with sim­ple solu­tions, but pointed to what would become the mantra of the ses­sion: proper user test­ing with assis­tive tech­nolo­gies is crit­i­cal to mak­ing an appli­ca­tion acces­si­ble. Real peo­ple do things that no web devel­oper will ever anticipate.

The Hijax tech­nique was briefly dis­cussed — and I learnt more about this on Fri­day at Jeremy Keith’s ses­sion. Essen­tially, it means first mak­ing a reg­u­lar appli­ca­tion which func­tions with­out JavaScript, then using pro­gres­sive ehance­ment tech­niques to add a behav­iour layer to “hijack” stan­dard links, form sub­mis­sions etc at par­tic­u­lar points and sub­sti­tute Ajax func­tion­al­ity. If an appli­ca­tion used this approach from the begin­ning, the task of ensur­ing it was acces­si­ble would be a lot simpler.

Some of the exam­ples covered:

• Forms for tables
  • Prob­lem: screen­reader has prob­lems asso­ci­at­ing labels with inputs
  • Solu­tion: add seman­tic labels, drop the tables, user cor­rect source order then absolute posi­tion­ing to adjust the visual layout

• Chang­ing ele­ments using JavaScript
  • Prob­lem: 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 ele­ment, the user-entered text was also cleared
  • Solu­tion: only clear input if default text is detected

• Voice recog­ni­tion and alt attributes
  • Prob­lem: voice recog­ni­tion soft­ware couldn’t acti­vate a menu image link where the alt text was dif­fer­ent from the visual rep­re­sen­ta­tion of the word
  • Solu­tion: Make the alt text match the image

• Non-semantic ele­ments
  • Prob­lem: key­board nav­i­ga­tion between links not work­ing in Google maps
  • Solu­tion: using a proper anchor ele­ment rather than a styled span with an onClick handler

• Using colour to indi­cate change
  • Prob­lem: Basecamp-style colour flashes inac­ces­si­ble to visu­ally impaired and users sim­ply not pay­ing atten­tion at the exact moment they occur
  • Solu­tion: rather than rely­ing on the colour change, also change some text or use some other per­ma­nent visual marker.

More com­plex Ajax problems

Not all acces­si­bil­ity prob­lems posed by web appli­ca­tions are so eas­ily fixed. A major issue is how to make sure that when the con­tents of the page is changed using JavaScript (the basis of most Ajax apps), screen­read­ers and other assis­tive tech­nolo­gies are aware of the change.

Derek ran through a few exam­ples using Base­camp lists and a form val­i­da­tion sam­ple, but the results were not con­sis­tent — essen­tially, the only way to know for sure if an appli­ca­tion is truly acces­si­ble is to test it with assis­tive browsers. If a par­tic­u­lar tech­nique doesn’t work, try another — there’s plenty to choose from!

Finally, Derek ran through an inac­ces­si­ble, com­plex multi-step form and dis­cussed areas that he was chang­ing to make it accessible.

Now go away and do this…

I wrote four notes at the end of the session:

• Plan­ning
  • Plan for acces­si­bil­ity at the begin­ning of the process, rather than at the end

• Do the sim­ple stuff right
  • Lay­out forms cor­rectly, val­i­date html and markup

• Seman­tic interaction
  • Use the right ele­ments for the job — e.g. links should be anchors

• Pro­vide “options“
  • Acces­si­bil­ity has the poten­tial to help all users
• And always test test test

Derek’s work­shop was infor­ma­tive and enter­tain­ing — it’s always a real priv­i­lege to lis­ten to him speak. I learnt lots and have heaps of tips I can start using in my work right away.