Screen Readers Suck 8

There has been some mumbling about accessibiliy and javascript for quite some time now and today I read the following at the DOM Scripting Task Force blog:

It’s also all but impossible for some applications, such as Google Maps. In fact, after some preliminary testing our own Derek Featherstone was so dismayed by the state of JavaScript in screen readers that he recommended screen reader users turn off JavaScript. Hardly an encouraging sign.

This makes me very dissapointed. The problem is not with javascript, it is with the most popular screen reader, JAWS, from Freedom Scientific. I’ve had the displeasure of using this crappy product for some time now and I must say I feel sorry for blind and visually impared users. (JAWS is not unique here, other products have other issues.)

Let’s say you have created a product that is fully keyboard navigatable. Then you start JAWS and for some reason keyboard navigation is no longer working? Why is this you may ask? It is because JAWS disables all the DOM keyboard events. Don’t visually impared people need to use the keyboard? Maybe they prefer the mouse which they have a hard time to see?

To get the keyboard events to work at all you need to get JAWS into forms mode. However this cannot be done programmatically and it requires user interaction. This can be achieved in a fairly easy way but it decreases the usability when we are really striving to improve the user experience for visually impared users.

The next issue is to get JAWS to read out information about the UI to the user. This is very tricky. How do you get JAWS to understand that the currently focused DIV is a slider? HTML does not have sliders and HTML is the only thing JAWS understands. And please don’t say use a text input. That is not acceptable. The UI must be the same and the screen reader should read out information that will help the visually impared person to understand what to do.

There are currently three ways to go here:

  1. Shut out visually impared people. (Is this what Derek Featherstone is suggesting?)
  2. Create a less usable application that only uses text inputs, links and other non intuitive controls and continually go back to the server ala ASP.NET and make the user frustrated of the bad responsiveness of the application. Visually impared people don’t need less UI feedback. They need better UI feedback.
  3. Use complicated hacks and odd behaviors to get the major screen readers to treat your web application just like any other Microsoft Active Accessibility application (Win32 app).

All is not lost here. Aaron Leventhal is doing a great job implementing the WAI roles in Mozilla. This means that you can set the wai:role attribute on your DIV, representing a slider, to “slider” (I’m not really sure that there is such a role.) and the screen reader will then only need to support MSAA (and they all do but some think they can do better for HTML which they clearly can’t). All you have to do is to make sure you set the role correctly and implement keyboard navigation (and get screen readers to not suck ass :evil:)

  • Erik Arvidsson

    Here are the pages at Try these in Deer Park Alpha 2 with MS Narrator (JAWS chokes)

  • Derek Featherstone

    There are currently three ways to go here:

    1. Shut out visually impared people. (Is this what Derek Featherstone is suggesting?)

    No, actually, that is most definitely not what I was suggesting. To provide some context, I was actually making the following points:

    1. Screen reader software is getting better in its support for scripting
    2. Where screen reader software fails (for example, in certain AJAXian techniques), if we’ve built things “correctly” using progressive enhancement, graceful degradation and unobtrusive scripting, we should be able to tell screen readers users to turn JS off so that they actually get a better experience.
    3. Turning JS off may be more important for people using older versions of screen reader software.

    That’s what I was suggesting – certainly not suggesting that they be shut out, in any way shape or form.

    Hope that clarifies…

  • Erik Arvidsson

    That makes a bit more sense. However I do not agree with you that people should turn off js to get a better experience. If you turn off js you will limit keyboard navigation and visually impared users are people that really make use of improved keyboard navigation.

    Take a tree as a good example. With scripting enabled you can allow the user to navigate using the arrow keys and you can make the tree have one tab index, instead of each item having its own entry in the focus chain.

  • Derek Featherstone

    If you turn off js you will limit keyboard navigation and visually impared users are people that really make use of improved keyboard navigation.

    That entirely depends on context and how the “thing” was built. I say “thing” because interacting with an application will be entirely different than interacting with a page, for example, that shows and hides content using DOM Scripting.

    The tree example you mention is a good example, in theory. It might still be a situation where a user of some older screen reader “insert version here” might not handle that interaction properly, and if so, if we’ve built things “correctly” even with JS off, that tree example might be less than optimally usable, but better than not being able to interact with it at all.

    Believe me – as a member of both the DOM Scripting Task Force, and the Accessibility/Assistive Devices Task Force – I want nothing more than to move this stuff forward so that we can use modern scripting techniques along side assistive tech in a complementary way, rather than in a limiting way.

  • Peter Krantz

    Good news is that screen readers are getting better. The mozilla DHTML accessibility support ( is apparently already supported by the upcoming version of Window Eyes 5.5 (beta 1:

  • Pingback: Web Site Accessibility Blog “ Joe Clark’s ScreenReader Rant()

  • Pingback: Maria Carter()

  • Pingback: Is the Writing on the Wall for AJAX? | Richard Leggett()