This is not a technical article. You will not learn how to code AJAX by reading this; either in an accessible and usable fashion or otherwise. This is a conceptual article. It will run through basic user-interface issues with AJAX (and other rich media). These are the reasons that AJAX functionality can be a problem for users — if you consider these issues carefully during development, it should greatly enhance the usability of your end product.
The basic limitations encountered with AJAX are threefold:
Best practice in any rich media format should always ensure that these three limitations are dealt with for all users.
I’m making the basic assumption that any Javascript discussed in this article has been designed sensibly with the concepts of “Progressive Enhancement” in mind. This is an article about the design of the Javascript-based user interface and making allowances for usability and accessibility within that Javascript-based interface.
Discoverability of Functionality
The first challenge is to simply be aware that additional functionality is available. Discovering that a box is draggable, that a text field is editable, or that an image can be annotated requires some form of user notification. With some applications (like Flickr, for example) the richness of interaction means that it is very difficult, practically speaking, to visibly label every possible interaction.
The usability issue is divided between two problems: either you don’t label every feature, or you overwhelm the design and the user with information. A page which is utterly coated with “Edit this,” “Drag that,” and “delete these” is not particularly more user friendly than a page devoid of labels, where actions require experimentation to be discovered.
The most common solution is through varying uses of tool tips, subtle graphic indicators, and other changes triggered by the mouse hover action. These solutions, while very effective for experienced, traditional users, are highly problematic for many others. People not using a mouse will never see them. Have you ever tried to use Flickr with only a keyboard? This is not a successful experience. Most functionality is completely lost to the keyboard navigator.
Some possible ways to solve these issues include limiting the use of AJAX functionality, so that you can clearly label all functions without cluttering the information display. This is a start, and will certainly be of use to sighted, mouse-using visitors, but doesn’t really cover all the bases.
The most effective method is to provide the option to enter a more traditional editing interface. Provide your AJAX methods, but also include a single “Edit” link (for example) which switches the user into an editing mode. This can enable all of the editable fields, and provide a standard method for inputting changes. Do not only provide this when Javascript is not available, however — it is a devastating error to assume that the only people needing assistance with AJAX functionality are those for whom Javascript is not available.
Usability of Rich Media Functions
Naturally, the previous subject did bleed over into this one. Division of concepts in the user interface realm is not exactly clean, as every decision is liable to impact multiple areas. Nonetheless, there are many issues of usability with rich media which require their own discussions, assuming that whatever function is provided has already been discovered.
The biggest issue, and the most obvious, is that many rich media functions are triggered by mouse-specific commands. “Hover” or “Drag” are interface methods very easily embraced by a mouse user and completely unavailable to a keyboard user.
The fallback method can be to provide an alternative interface for all editing, of course, as described above. However, as much as possible, you should attempt to integrate alternative methods to provide an optimal experience for all your users. Function triggers should be:
- Keyboard focusable
- Described in a manner which allows for multiple uses
- Described in a manner which specifies what will happen
I wouldn’t say that you should discard your draggable, rearrangeable layout. You should, however, provide the option to rearrange the layout without a mouse. A set of keyboard selectable “Up-Down-Left-Right” arrows is a common and easily understandable approach.
Making certain that a function is possible to use for keyboard or screen-reader users is relatively trivial — consistently using anchor elements or form controls to trigger events will make that functionality pretty reliable for most users. One remaining user group which may experience difficulties is mobility impaired users.
One difficulty of trying to incorporate numerous interface elements into a space is that, inevitably, the trigger elements become smaller and smaller. This can have a significant impact of mobility-impaired users. Making certain that elements are keyboard-accessible and have strong :focus
states will help.
Discoverability of Feedback
For visual users, this is usually not a great challenge. Exceptions might include low-vision users who require substantial magnification or who are affected by a disease such as Retinitis pigmentosa, a disease characterized by tunnel-vision. Either of these situations can make it difficult for the user to discover changes in the page which occur outside their limited viewable area.
To make the feedback obvious and effective, some thought is still required, of course. Feedback should be clearly separated from the rest of the page; such as through an overlay technique. It should always be visible in the current viewscreen — changes made outside of the currently viewable area should still be reported in a visible location. Subtlety isn’t really all that valuable: focus on understanding, first.
It has to be noted that the tests which this article is based on were not performed using the most current versions of the relevant software. One chart can be seen at Access Matters — this is the data relevant to the Gez Lemon article. It’s not immediately obvious what versions of screen readers and browsers were used in the SitePoint article, but the article is dated May 5th, 2006 — which makes the options limited.
For the record, the current version of Freedom Scientific’s JAWS (Job Access With Speech) is 8; which was released in November of 2006. Although the version tested is not specified, the tests were conducted before the current version came available. Dolphin’s Hal is now also on version 8, released apparently in the 2nd quarter of 2007. GW Micro’s Windows-Eyes is now on version 6.1; tests were done up through 5.5 (beta.). IBM’s Home Page Reader has not been in development for some time; those tests are current as regards the screen reader, although NOT in regards to the browser tested.
For aural users, this is a huge challenge. Not insurmountable, necessarily, but certainly a major hurdle. Gez Lemon covers the problems with providing focus in screenreaders in detail in his article “Making AJAX work with screen readers.” The problems are numerous, and different for each major screen reader user agent. What it comes down to is that, at the time these tests were performed, there was no reliable and consistent way of notifying screen readers that a change has occurred.
This is a big disappointment. The conclusion reached by many is that AJAX functionality is, for the moment, beyond the realistic reach of screen reader users. This isn’t precisely accurate; since I’d argue you can still possibly make use of functions where the result of the function is patently obvious from the description of the function; however, you’d need to allow error messages to be handled using non-AJAX methods.
Fundamentally, in order to provide accessible interactions for a non-visual user, you need to provide a non-AJAX response. It will need to require a page refresh, and use in-page anchors to send the user directly to the relevant response message or a prominent link which will direct the user to that message. A clear statement about what has changed is absolutely required.
Additional Articles and Resources on Ajax Accessibility
- WebAIM: Accessibility of Ajax Applications
- Becky Gibson, IBM: Ajax Accessibility Overview
- James Edwards: Ajax and Screenreaders: When can it work?
- Gez Lemon: Making Ajax work with Screen Readers
- W3C: Dynamic Accessible Web Content Roadmap
- W3C: Roadmap for Accessible Rich Internet Applications (WAI-ARIA)
- Max Kiesler’s List of AJAX and Accessibility resources.
Joe Dolson
Thanks, Christopher.
Personally, I consider it to be a shift beyond accessibility; the alternate version needs to be available just to make the interface seriously usable. Granted, that may be an extreme interpretation… 🙂
Christopher Phillips
Thank you for a very reasonable overview. I appreciated the examples of how different groups might be affected. It is interesting as Mike notes, how Web 2.0 ajaxian interfaces may actually require a step backward in forcing the addition of an accessible version of a page.
Joe Dolson
I like that…it’s got a nice ring to it! 😉
It’s really a pretty straightforward concept…it’s just a matter of being alert to the issues associated with accessible interfaces, I think. Education, education, education…
Mike Cherim
You pretty much hit the nail on the head when you suggested an alternative or option has be offered (be it a special mode or a different content delivery method). A one-size fits-all solution is next to impossible, and putting all of the functionality (of something like Flickr) and accessibility on one page will likely ruin the site for both. What’s need is big “Accessibility Mode” link to a sister interface drawing from the same database, but with a lot less inaccessible functionality.
In the words of the WCAG (Web Content Accessibility Guidelines) 1: When you can’t 6.2, then you better 11.4. 😉
Joe Dolson
Honestly, that’s just a fundamental principle which I chose to assume. Any Javascript development should be approached in that manner. That doesn’t change the fact that the Javascript-based enhancements to the interface should be carefully planned to be as usable and accessible as possible. Simply making it usable when Javascript isn’t available is insufficient, since there are many users who will have Javascript available — but not in a manner which will allow them to use the feature.
(I’m adding a note to the top of the article, however, to clarify this.)
marc mcneill
Interesting article, but how about designing without the javascript goodness first, and layering on later as with progressive enhancement.
http://en.wikipedia.org/wiki/Progressive_enhancement