CSS for “rollovers” aids screenreader accessibility

Using the css :hover pseudoclass on links for a rollover effect is better for screenreader users than using JavaScript.

Remember my genuine menu that I used previously to show that the Web Standards method of using nested unordered lists for navigation menus allows screenreader users to understand the hierarchy of nested menus?

I used it to compare the “traditional” way of making a rollover with JavaScript onmouseover with using the css :hover pseudoclass on the link.

Since doing the test and posting it (I’ve been on my holidays; it was very nice, thank you) an interesting commenter on Derek Featherstone’s site wrote,

JAWS and others seem to be well intentioned but what I have noticed with the few blind and low vision students we have here is that they turn off as many features as possible … JAWS gives them too much information and it is distracting.

Jesse

Both tests looked exactly the same, but on the JavaScript version, the phrase “onmouseover” is read against each link (listen to mp3 of JavaScript version). This is clearly too much information – why would a screenreader user give a damn about a visual effect?

Even though my re-written :hoverversion doesn’t kill the table layout or use lists, it doesn’t pollute the screenreader user’s ears with repeated useless utterances of “onmouseover” (listen to mp3 of CSS version).

Obviously, using an unordered list in a div would be even better, but even so, it works for people who don’t have JavaScript, keeps the markup clean and keeps the page light (blah blah, you know the arguments).

Now this is hardly ground-breaking research for the Standards evangelists reading this – but it’s further real-world evidence that using semantic mark-up that seperates content and presentation definitely enhances acessibility.

6 Responses to “ CSS for “rollovers” aids screenreader accessibility ”

Comment by Lachlan Hunt

Is there a difference between when the event handlers are dynamically attached from the script and when they’re attached with the onevent attributes? If they’re attached dynamically (i.e. without using the attributes in the markup), does Jaws still say “onmouseover“?

Comment by Bruce

It’s well beyond my JavaScript knowledge to even understand your question, Lachlan.

The JavaScript links I was testing are coded

<a class=nav onMouseOver="on('whoweare');" onMouseOut="off('whoweare');"
href="anout us.htm">Who we are</a>

If you don’t have access to JAWS 6.1 and want me to test out the questions you have, please email the code to me; I’ll test it over the weekend and post the results here.

Derek Featherstone notes,

[JAWS] seems like it was designed to deal with things like JavaScripted menus and the like from Dreamweaver. The problem that I found is that if you attach your JavaScript dynamically, JAWS doesn’t seem to recognize that there is anything there because “onmouseover” isn’t declared inline.

Is that what you were asking?

(My next project is to learn unobtrusive DOMscripting;-)

Comment by Jules

Bruce, it is my understanding that JAWS “depends” on the inline event handlers to be able to announce their presence. Therefore, using unobtrusive DOM scripting and event listeners are beyond the capabilities of JAWS. This of course has both pros and cons: useful content provided would be missed and useless content would be avoided.

Comment by Bruce

Sounds like a job for a pressure group interested in working with screenreader vendors to help them support Standards. If only I knew of such an organisation ….

Comment by five mistakes

Your site is pretty cool to me and your topics are very relevant. I was browsing around and came across something you might find interesting. I was guilty of 3 of them with my sites. “99% of site managers are doing these five HUGE mistakes”. http://tinyurl.com/6o9euxt You will be suprised how simple they are to fix.