/Opinion/ Ajax and accessibility, part one
23/12/2008 | Filed under Discover > Opinion
In the first of a two-part opinion piece, Nomensa’s Alastair Campbell explains what you can do to work around Ajax’s accessibility issues
Developing a Rich Internet Application (RIA) that’s accessible has historically been somewhere between difficult and a nightmare, even with seemingly common technologies such as HTML/CSS and JavaScript.
The issues with the accessibility of RIAs tend to revolve around Ajax. Sites such as kayak.co.uk and flickr.com use Ajax to update content without refreshing the page, but currently some users may not be able to use those controls or get at the new content. The issues with RIAs are not due to JavaScript as such, but more from trying to make up for deficiencies in HTML. With HTML’s history as a document format, it doesn’t intrinsically support many types of control. For example, you can visually indicate that a slider-control will affect the number of search results with CSS and JavaScript, but you can’t indicate that non-visually.
Some access technologies and browsers are so poor at using scripts that JavaScript guru James Edwards said: “Stop using Ajax!”. He demonstrated that many instances of Ajax were unnecessary, and that you can usually achieve the same thing without it. However, with a little thought, most issues can be worked around.
This basic issue is not an accessibility one per- se, but some people (most often on corporate networks) don’t have JavaScript enabled, or it may be filtered out on the way to the browser.
Defensive development
Jeremy Keith outlined Hijax a couple of years ago, which is applying progressive enhancement to Ajax. While the concept of using <noscript> tags is outdated, building an application with semantic HTML and server-side scripting as a foundation is not. With a wide variety of browsers and situations, this type of defensive development is just good practice. Once the back-end functionality is in place, layering on the behaviour (front-end scripts) can greatly enhance pages without requiring JavaScript. With this in place, you can also provide a mechanism to turn off scripts where they’re causing difficulties for people with partial JavaScript support.
Not all HTML elements can be focused on with the keyboard, so some scripted events won’t be accessible if they rely on a mouse. At the moment the safest approach is to use standard HTML controls (links and form controls), as these are keyboard accessible by default.
When part of a page is updated, people using screen readers or magnifiers may not be aware something has changed. Often doing something on a page causes an update of another part of the page – for example, adding something to your basket on an ecommerce site. Yet people using screen readers or magnifiers will have no means of telling something has happened. It could end up being an expensive shopping experience!
There are often visual indicators of updates, such as the ‘yellow fade’ technique popularised by 37signals, but there’s no indicator for someone on a screen reader. Even worse, some screen readers take a cached copy of the page, and the user can’t get at the updated content. Thankfully, Gez Lemon and Steve Faulkner solved the caching problem with a function that updates the screen readers’ cache after an update.
Make sure someone using a screen reader knows if an update is tricky. Currently, you can only use content (including a hidden statement to refresh the page after making a change), or allow people to select an option where updates cause JavaScript pop-ups, or an option to turn off scripts.
For those using a screen magnifier it’s good practice to make it apparent that something is happening where they clicked (an example is Basecamp’s progress indicator), as their view follows the mouse closely.
There’s a learning curve however the strategies and fallbacks are carried out. Ajax isn’t going away, so we need to know how to make it accessible. Next month we’ll look at a new spec that allows new controls to be added and people to be automatically informed about updates – ARIA.
The director of user experience at Nomensa, Alastair Campbell blogs at alastairc.ac.
Bookmark with:
Comments
Tai / 09/07/2010 / 13:02 / http://www.newsparkdesigns.com
This is pretty dated now. With JQuery-style Ajax, cross-browser issues are almost entirely defeated.
You can base almost any kind of enhancement based on a HTML form control. Great for screen readers and people without JavaScript.
I do think that trying to cater to folks without Javascript on defunct browsers is inherently absurd. Catering to those with screen readers is important however backwards compatibility has been taken too far.
Lets build great websites and not worry about people with broken and disabled equipment!
