I'm a developer in Melbourne, Australia, and co-founder of Hello Code.

Published Sun 30 September 2007

← Home

JavaScript and screen readers

I wanted to share with you a couple of points I learnt while at the conference. Andrew Downie and Grant Focas presented an excellent talk on JavaScript and accessibility, and what they said certainly came as a surprise (and a bit of a relief) to me. It basically boils down to this:

It's okay to use JavaScript in your pages as long as you observe some basic rules.

I had never really thought about it up until now, I must admit, as most of the web applications I write are internal and thus only need to conform to the company's guidelines. But Grant and Andrew reassured us that screen readers have come a long way in the last few years, and can handle dynamic content and functionality fairly well. Their view is the onus is mostly on the manufacturers of the software to keep up with recent developments in web technology that the rest of us already use. This certainly sounds good to me.

There are, however, a couple of things you should be doing if you want your sites to be as accessible as possible.

Use focus and blur events to mimic mouseover and mouseout events

It makes a lot of sense, doesn't it? Those using screen readers primarily navigate with the keyboard, so any necessrary functionality (like a dropdown menu, for example) needs to be accessible through keyboard events also.

Display new content directly after the element that triggers it

As people with visual impairment cannot see when you update an area of the screen, they must rely on the screen reader to tell them what the page contains. So for example, if your button element triggers the display of a new form or element, if it doesn't appear right after the button in the page flow, it may very well get lost. Of course the user can always cycle back through the page from the top but if you give them no reason to believe anything has changed, they may not think to do this. So the solution? Insert new content directly afterwards in the page flow, or for input elements, you may call the focus method.

And the final rule doesn't really concern JavaScript, but I thought it was useful to reiterate it anyway.

Use semantically appropriate elements — they really are useful

Yet another reason to use h1, h2 tags instead of styled spans — a screen reader can use these tags to add functionality to a page. For example, a user can jump between heading tags; an ordered or unordered list will be read out with the number of items it contains; and (a fairly basic one) labels will be read out when the related input is focussed.

And finally, to find out what your site will 'look' like to a screen reader, you can download the Fangs plugin for Firefox, a screen reader emulator.

To top