Jaws screen-reader vs. Javascript modifying the DOM

Adam Alton - November 6th, 2009

We’ve just finished building a site that is aimed largely at users with disabilities, and as a result we did quite a bit of testing with the Jaws screen reader to see how the site appears to a blind user.

I got into quite a fight with Jaws, Javascript and bad magic.  I was adding some Javascript to modify a Wysiwyg editor to make it a bit more screen-reader friendly.  At first it seemed that the Javascript just wasn’t working, but further playing revealed that it was but that Jaws wasn’t seeing the modifications that Javascript had made to the page, which was odd, as Jaws was able to see the Wysiwyg editor which itself had been created by Javascript  And sometimes the Javascript just made Jaws read out the text for one link when the keyboard focus was clearly on another.

It turns out that (apparently) Jaws scans the web page when it finishes loading and creates its own copy of the elements on the page, so that when the user tabs through the items on the page Jaws tabs through its own copy of the page and reads out the elements.

Tbe problem is that a lot of Javascript gets run at page load time, (either because the <script> tags have been put at the end of the body, or because there’s some kind of jQuery type $(document).ready() thing in use).  And it’s at page load time that Jaws makes its secret copy of your page.  So if your Javascript is fast enough then it will run before Jaws reads the page, but if it’s too slow then Jaws wont know about the changes to the page, and so when your user tabs through the items on the page Jaws will read out the item that it thinks is there, even if it’s not.

4 Responses to “Jaws screen-reader vs. Javascript modifying the DOM”

  1. Owen says:

    I had a thought the other day: a graceful way of doing accessible wysiwyg would be to use ARIA alerts to read out the input label.

  2. Rick Hurst says:

    This is really interesting. I wonder how many common accessibility techniques are implemented on the basis that screen readers don’t do javascript at all, when really the issue is which bits of javascript are being used. I think many people (including me) work based on completely wrong assumptions about the way screen readers work, and would really benefit from being able to get hold a free version of Jaws for testing purposes…

  3. AdamA says:

    Owen do you know if Jaws is clever enough to understand Aria stuff? I know it should be, but jusding by the pictures on the box I’d say they haven’t made any updates to it since 1803.

    Rick, yes, it’s quite interesting seeing how it works, and I would guess that most people use it with Javascript switched on. If you find a way of getting a free demo then let us know! It’s about £800 for a single licence, so at the moment we’ve just got it running on one XP machine. Apparently the open-source NVDA is much better, but I think there’s quite an IE6-style wont-go-away thing with the old Jaws.

  4. Owen says:

    @Rick
    You can get the 30 min trial for free and after that you have to restart the machine. This sounds annoying but can be circumvented by using VMware’s rollback feature. I have a few screen readers set up on my machine. There really is no excuse not to test.

    @Adam
    Yes it is clever enough although implementation varies depending on which browser you are using with JAWS. We have used ARIA alerts in other projects. Admittedly older versions of screen readers don’t support ARIA but there’s not much that can be done about that. People need to upgrade, NVDA is free, again: there is no excuse.

    Signed Owen “no excuse” Curtis-Quick

Leave a Reply