HTML5 accessibility testing?

Question

For all the HTML5 how great it is for accessibility readers/devices hype, I haven't even seen one of these readers/devices yet that works with HTML5. After I create an HTML5 webpage, where do I go to test it? I'd like to hear what it sounds like in an accessibility reader.

I know the Text To Speech on a Mac has no idea about HTML5. That is like most text to speech software unfortunately.

Answer 1

There are a couple of levels to this.

Browsers

The first level is the browsers, how well do they map the HTMl5 elements to the accessibility API? Steve Faulkner of The Paciello Group maintains a website that has a good amount of information about HTML5 Accessiblity.

Firefox, pretty good. Others, ok in places. It does depend what you mean by support though. For example, what should a screen reader do with <section>? Probably nothing, but it doesn't freak out, so is that a problem?

Assistive Technology

The second level is then how various assistive technologies support HTML5 elements. 4thspace linked to some testing of screenreader support of HTML5 section elements, but overall WAI-ARIA support is much better.

Looking beyond screen readers: Screen magnifiers don't do anything in particular with HTML5, nor does Dragon (voice recognition), so be careful what you rely on. For example, Dragon doesn't recognise HTML elements you make into interactive elements that are not natively interactive (e.g. buttons/links work but a <div> scripted as a button does not).

HTMl5 tends to encompass anything in the modern web-stack, so a more specific question would be needed for more.

Answer 2

One of the tools we use in our corporate environment is NVDA. It's a great tool and freely available.

JAWS is one program that is popular with corporate clients, but it is very expensive. Older versions predated the ARIA standards and it took a few versions for those features to become supported so your results will definitely vary by version.

This question is kind of objective. Screen readers treat things differently and people are typically slow to upgrade to new versions that are more supportive of the ARIA standards. The main reason why people are slow to upgrade is due to the cost (primarily JAWS and ZoomText).

Typically, the way we go abut testing these things is with a combination of keyboard testing and screen reader verification. If you can get through the application with a keyboard and the screen reader reads all of the cues it needs to be able to understand what is going on without being able to see the content, you are in pretty good shape.