My editor, Simon St. Laurent, and I both agreed that with the new book, Adding Ajax, the work would all be valid and accessible. Some of this effort is easy; much is not.
One particular area has to do with updates. When using a screenreader, or when using a screen magnifier, if the data in the page is updated, the web page reader may not be aware that such updates have taken place. You then need to provide some form of cue, and I don’t mean the color fade (which if you think on it, is about the most unaccessible Ajax effect there is).
As has been discussed elsewhere if screenreaders didn’t support JavaScript, life would be simpler because the readers would then get the no script version of the page contents. Screenreaders do support JavaScript, though, and that plays all sorts of havoc.
Anyway, while researching the current state of accessible Ajax (which threatens to be an oxymoron), I came across some resources I thought might be of interest.
- IBM’s Ajax Accessibility effort
- WaSP announcement of IBM and DOJO collaboration and interesting comment thread
- W3C Accessibility role and state metadata effort
- Juicy Studio: Making Ajax work with screenreaders
- Latest on the discrimination lawsuit filed against Target (thanks to Head Lemur for heads up on this one)
- Ajax and Accessibility
- The Web Accessibility Test
- WatchFire WebXact: test your site’s accessibility
- Ajaxian’s Accessibility posts
- W3C’s listing of accessibility tools
- Sitepoint’s Ajax and Screenreaders: when can it work?
- Mozilla’s Accessibility Project
Regardless of whether you’re a web developer or not, it’s a good idea to test your page as it appears in screenreaders. I use Apple’s VoiceOver, which is built into Mac OS 10.4 and up. Unfortunately, its behavior differs from other screenreaders, such as JAWS.