The simple fact is that the web has been dramatically changing over the past couple of years, with Web 2.0 and Ajax. And what is happening is not good for accessibility. The issues raised in the last section are everywhere. Interaction widgets are popping up all over and often screen reader and keyboard users haven't a clue about what is going on. A strange fact is that it used to be that there was always a page reload when anything significant changed - that often put the screen reader user at the top of the page where they then had to figure out what happened. At least they were aware that something happened. Now you press enter and nothing happens - well, nothing seems to happen.
Most Web 2.0 social computing sites are rich with inaccessible - or questionable - controls. I'll just mention one such site - my favorite photo site. The following is a screenshot of part of a Flickr page of mine displaying a "Set" called "Minneapolis" and a photo (the Collapsed bridge in Minneapolis) plus three thumbnails. As I (the owner) of a Flickr Page move the mouse over an editable area it becomes highlighted in a yellow background as shown in the screenshot. A clue is provided with a text pop-up "Click to edit".
There are two editable areas in the screenshot - the title of the set (here, "Minneapolis") and a description of the set (here, "The LEAD Conference at the Guthrie Theater in Minneapolis. August, 2007"). A keyboard user has no idea that these regions are editable. They do not meet the fundamental requirement of keyboard access discussed above. The keyboard user can activate the edit menu above the pictures to change the titles and captions on the individual pictures, but I didn't find a way to edit this information about the set. I would not be surprised to find that there is a way to do it. This untenable situation could be changed easily; if the editable regions had tabindex="-1" then they would be in the tab order as Martin Kliehm pointed out in his A List apart article on Accessible Web 2.0 Applications with WAI-ARIA. I believe that if they were in the tab order, then either the enter key could open the edit window (see below), or perhaps they would become editable with the onFocus event.
The story is different and a little better for a blind user. JAWS announces the Set title, Minneapolis, (which is an h1) as "clickable." Using the left mouse button with JAWS (the Slash-key(/) on the number pad) the edit box opens up as shown in the following screenshot.
It is a normal edit field (input with type="text" ) and JAWS knows it. The buttons seem to be HTML buttons but access to them with JAWS was flaky at best. The input field opens with everything selected (highlighted). That means that typing one letter deletes everything. Escape brings it back.
The fact that JAWS knows that the text is clickable does not satisfy the requirement of knowing the role (WCAG 2.0 SC 4.2.1) of interface elements. Once you activate the object, then the role and value are known.
Ajax is appearing everywhere. Probably the most important development in this area is the work of the W3C Protocols and Formats Working Group, which has a draft Roadmap for Accessible Rich Internet Applications (ARIA). Basically this is a strategy for providing the role, state and value information for those scripted controls.
Martin Kliehm, in the article referenced above, says:
Do we have to wait another ten years until other browsers support these techniques? Actually, no. You can start using roles, states, and properties right away. Currently only Firefox 1.5 or later and three major screen readers (Window Eyes 5.5+, Jaws 7.0+, ZoomText) support them, but the extra attributes won't hurt other browsers.
Though ARIA is not a Technical Recommendation of the W3C yet, you can add the state and role information to your Ajax widgets and test them with Firefox.
There are two excellent articles on this subject on the JuicyStudio site. The first is titled, "Making Ajax Work with Screen Readers," May, 2006, authored by Gez Lemon and Steve Faulkner (of Web Accessibility Toolbar fame). Here's the summary.
The Web Accessibility Initiative's Protocols and Formats working group directly address the issue of making rich Internet applications accessible, and we borrow some of their concepts to investigate methods of ensuring that Ajax applications work with leading assistive technology products. The bad news is that it isn't possible to make Ajax work in every known assistive technology, in the same way that it isn't possible to get Ajax to work with older browsers, but we explain the fundamental issues; how to inform users of assistive technology that a change has taken place, and how they can interact with the content. To illustrate our findings, we summarise the behaviour of popular screen readers.
The follow-up is "Improving Ajax applications for JAWS users", January, 2008 again by Gez Lemon and Steve Faulkner.
Popular screen readers use a virtual buffer to allow users to interact with web content. This article uncovers undocumented behavior in JAWS 7.1 and later, which allows web developers to build Ajax applications that update the virtual buffer without any interaction from the user.
I want to conclude this brush with Ajax with an example I came across - this is not a web 2.0 site. If you perform any product search on the web site of the major recreational equipment provider, the search results are prefaced by a filtering control that is actually a tab control shown in the following screenshot.
When you use a mouse, this acts like a tab control (like what you find in Internet Explorer, Tools > Options). Click on "Price" and several price ranges appear in the tab panel. Click on "Categories" and you are back to the tab panel as shown in the screenshot. There are no page reloads.
None of this works from the keyboard. The tabs, which visually look like links, are not. Adding tabindex="0" to each of the tabs would put them in the tab order.
Then they would be in the Tab order, but how could you know these are tabs? How could you know their roles? You should code this as prescribed by ARIA and discussed in the articles above. There is even an elegant Ajax sample of a tab controll. That sample works the way a tab control is supposed to work from the keyboard, but I could not get it to work with Window-Eyes in Firefox, where it is supposed to work. I never heard the roles. If you do code this tab control like that, and this is a guess, 90 percent of disabled users won't know that you have done that work. Only the small percentage using Firefox.
Given that lack of support, I suggest using a hack! Add an invisible image to each tab, with alt="tab" - the roles. Then add an invisible image to the current tab - alt="current" (its state). Now when a screen reader tabs to a tab, he would hear "Tab current categories", "Tab link Brands", etc.
This tutorial is based on Webucator's Web Accessibility and Section 508 Training for Experienced Web Designers Course. We also offer many other Web Accessibility Training courses. Sign up today to get help from a live instructor.