I recently finished a tutorial on using JAWS to evaluate web content. This article provides an overview for beginners on how to use screen readers to evaluate the accessibility of web content.
Many people seem to treat screen reader testing as something that should be left to experts or to blind screen reader users. It is true that screen readers are complex, and that user testing with blind screen reader users is important, but I still believe developers should evaluate their own web content with screen readers. Here are a few things I think they can learn from doing this.
Accessible design does matter
One of the easiest ways to show someone the potential impact of accessible design is to show them the difference it can make when using a screen reader. The significance of things like a "skip to content" link, a Table of Contents, headings, lists, etc. becomes much more apparent after using a screen reader. Something like a fieldset for grouped checkboxes may seem unnecessary until you try accessing an unfamiliar form in a screen reader.
Screen reader testing is an especially good way of demonstrating the importance of good alt text. A screen reader user may be able to compensate for missing headings or table headers, or poor link text, but can do little, if anything, to compensate for missing or improper alt text.
Your content may not be as accessible as you thought
Tables that seem to be clearly organized visually may be more confusing to a screen reader than you thought (I have seen screen reader users that are unable to follow tables with two rows of headers, even when they are properly formatted). Alt text may seem less helpful than you thought, or it might be too detailed or repetitive.
Screen reader users are not helpless
A screen reader allows navigation to and through content in a number of ways. The same block of text may be found by using Find, navigating by headings, navigating by links, etc. Using these many options, screen reader users can often navigate less-than-ideal sites quite capably, depending on their level of expertise. It is important that developers understand that screen reader users are capable people using capable software to accomplish a task that may seem almost impossible–navigating through a visual and mouse-dependent environment using a auditory and keyboard-controlled "interface".
I welcome feedback on the article, especially from sighted users who test with screen readers. Please post your comments below. I would also like to know how interested our readers would be in a similar article on testing with or other common screen readers (e.g. Window-Eyes), screen enlargers (e.g. ZoomText), or other assistive technologies.
Update: Maurício Samy Silva of maujor.com has provided a Portuguese translation of this article.
great article. Watching JAWS users in action is a great experience and something I insist on for all my training courses.
I try to demonstrate that on a particular page, if marked up correctly, a blind user can have an “equivalent” experience to a fully sighted user, and at times, can consume the same content, just as quick, if not quicker.
While it’s not the same thing, I recommend that everyone reading download JAWS in 40 minute mode, print out Jon’s Quickkeys (or Freedom Scientific’s shortcuts) and turn off your monitor to see how your page is read out.
It’s also a great technique to use in presentations – a real penny-dropper for those who might not understand accessibility.
On a similar note, Jakon Nielsen has released a 2001 report as a FREE download: http://www.nngroup.com/reports/accessibility/ – a good intro to accessibility
This is a great article. Do you know of any websites listing the popular screen readers comparing their functionality?