1. Accessibility

  2. The myth

    Screenreaders don't have JavaScript capability

    Not true: many screenreaders function on top of Internet Explorer

    Progressive enhancement works for JavaScript on and JavaScript off. But what about the middle ground?

  3. Generated content

    This isn't just an Ajax issue: it doesn't matter whether the generated content is coming from the server or not.

    The question is: do screenreaders "see" this content?

    The answer is: it depends. How is the screenreader congigured? What is the generated content?

  4. Triggering a re-read

    Screenreaders are biased.

    They have a forms mode, a tables mode, etc.

    They favour named anchors over ID'd elements.

  5. Solutions?

    You could provide a checkbox (hidden from visual browsers) that, when checked, will trigger an alert dialogue when a portion of the page is updated.

    Using tabindex="-1" with focus() to jump to the updated portion of the page.

  6. A modest proposal

    Should we encourage people with screenreaders to switch off JavaScript?

    If we're building our apps the right way (with graceful degradation), we can deal with having JavaScript switched off.

  7. Trailblazers

  8. It's not all bad news

    Joe Clark (with James and Derek) tested Basecamp:

    What we can say, then, is that this Ajax application is usable by screen-reader users some of the time. They aren't totally shut out, but it isn't totally easy for them, either.

  9. Conclusions

    There are no easy answers.

    It's a jungle of screenreaders and configurations out there.

    More hands-on research is needed.

  10. Next

    Using JavaScript libraries