Barrier-Free Web Surfing

Report by Chris Hoffman

June 2007

On Thursday, June 7, 2007, Amy Ruell, President of the Visually Impaired User Group (VIBUG), demonstrated barriers people who are blind experience when surfing the Web using the JAWS screen reader. P.J. Gardner, founder of Boston-IA, demonstrated the exact same barriers from the technical point of view and talked about how to solve them.

Amy Ruell is president of the 50-plus member Visually Impaired and Blind User Group and program manager for the ReadBooks! national children's Braille literacy program for the National Braille Press.

P.J. Gardner is Founder and President of Boston-IA, and a consultant in universal and accessible web design through her company, Gardner Information Design, Inc.

At past meetings of Boston-IA, previous speakers have demonstrated the use of the JAWS screen reader and their frustrations in trying to use inaccessible Web sites. What set this meeting apart was a side-by-side comparison of the barriers encountered by people who use screen readers to access Web sites, and the code that causes those barriers to exist.

Amy visited a series of Web sites (four inaccessible Web sites and one accessible Web site), and P.J. evaluated why the problems occurred and showed ways the problems can be solved or avoided.

• Review the list of sites visited at the June 7 meeting.

Navigation Issues

JAWS provides users with a variety of methods for navigating within a Web page. Amy demonstrated how to bring up a list of headings (<h1>, <h2>, etc.), a list of links, a list of images, or even a list of lists, and showed how she could jump from one element to another.

She was quick to point out, however, that many JAWS users are unaware of sophisticated navigation techniques, and that they simply let JAWS read the entire page from beginning to end, perhaps using the tab key to move through the page.

That being said, Amy demonstrated some navigation issues, and P.J. provided some tips to Web designers and developers for making navigation easier for screen reader users:

• Use headings. Heading elements, when used properly, can provide a helpful overview of a page's structure.
• Start link texts with different letters. JAWS lets users move through alphabetically sorted lists of links by pressing the first letter of each link's text. For example, a user might press c if she is trying to find a "Contact" link. If every link text starts with the same letter (imagine a series of links like: "Our About Page," "Our Products Page," "Our Contact Page," etc.), the user won't be able to use such first-letter navigation.
• Beware of repeated text. To a screen reader user, repeated phrases on a Web page can be very disorienting. It's like driving down the highway and seeing the exact same sign you saw twenty minutes ago. The feeling is that you have somehow mistakenly ended up where you have already been, and that you are unable to navigate competently from one place to another.
• Clearly identify the current page. Users will (hopefully) be navigating between different pages on your site, and making it obvious which page they are currently viewing makes navigating much easier (for example, by using descriptive titles and breadcrumbs).

Form Issues

Amy explained that filling out poorly labeled forms is often a matter of a lot of guesswork and experimentation for users of JAWS and other screen readers. P.J. stressed that it is very important, therefore, that Web designers and developers use <label> elements and associate them properly with form fields.

To make a form truly accessible, however, it isn't enough just to make sure that fields and labels are correctly associated with one another. You also need to specify exactly what needs to go into each form field.

Consider the following sample form:

Sample Form

Name:

Address: Apt. No.:

City: State: ZIP code:

How does a user know what information is supposed to go into the "Address" field? If she can see all of the fields at once, then she knows that there is an "Apt. No." field coming up later in the form, so she enters just her street address. If the user is relying on JAWS or another screen reader, though, the situation is different.

In that case, the user has no way of knowing that there is an "Apt. No." after the "Address" field. Not knowing any better, she might include her apartment number in the first field. The "Address" field label is so ambiguous, in fact, that she might even decide to include her city, state, and ZIP code. She won't realize her mistake until she gets to the "Apt. No." field, at which point she will have to go back to the "Address" field to re-edit it. If the form is particularly long, the process can be incredibly aggravating.

To see a live example of a form with particularly ambiguous field labels, visit The Christie Cookie registration page, one of the pages Amy used during her presentation. [As of April, 2008, the form is still as inaccessible as it was in June, 2007.]

Finally, it is important that form elements do what the user expects them to do. For example, it is not too uncommon to encounter a drop-down list with a JavaScript form.submit() method attached to the onchange event. The designers of such forms believe that they are doing the user a favor by saving the extra step of clicking on a Submit button. As long as the user can see that the form has been submitted and the browser is loading a new page, they are. For a screen reader user, on the other hand, such automatic form submissions and page refreshes can be quite disorienting.

Rich Media Issues

The issue of Flash^® and rich media was raised when Amy visited Pandora.com, a site that offers a streaming music service. When she first navigated to the Pandora.com page, music began playing automatically. To a sighted person, the location of the "Stop" button was obvious, and it would have been easy enough to click quickly if sudden loud music was not wanted. A person using a screen reader wouldn't have that luxury, though, and would have to go through the page from top to bottom until she found the "Stop" button.

So the rule is: Don't have audio or video start automatically, but, if you absolutely must, make it extremely obvious how to turn the audio or video off.

Amy also pointed out that many blind and visually impaired users do not install Flash^®, or keep it turned off, so mission-critical content should not rely on Flash^® for delivery. Plain old semantic HTML is much more reliable.

A Few Final Issues

I already alluded to another issue that came up during Amy's presentation in the section on forms: Automatic page refreshes can be very disorienting to screen reader users. Web developers might use automatic page refreshes whenever there is constantly changing content, such as on a news site or in an email Web application. The problem is that whenever the page is reloaded, JAWS and other screen readers will begin reading from the top of the page, and the user will have no idea why. The solution is to give the user control over when the page refreshes, rather than letting the browser do it automatically.

[Although it goes beyond the scope of Amy's presentation, I should point out that there are emerging technologies, namely the WAI-ARIA standard from the W3C, that allow Web developers to specify regions of a Web page that are automatically refreshed and to communicate the status of those regions to screen readers.]

The issue of trust also came up, namely, whether a screen reader user can be absolutely certain that a Web page is displaying the information it claims to be. Imagine a travel site with a list of airplane tickets sortable by airline, departure time, and price. If you sort the tickets from lowest price to highest, how can you be sure that the first ticket in the list is the best deal?

If you can see all of the other tickets at the same time, then it is clear that the first ticket has the lowest price (or, if it doesn't, you can easily choose the ticket that does). A screen reader user, on the other hand, can only hear one ticket price at a time, and so has no way of knowing whether they have been sorted properly. The solution is not clear, and it remains a provocative problem.

Finally, Amy and P.J. made an important point about user testing: You need to test your site with actual users of assistive technologies. Doing so, they said, is the only way to be absolutely certain that your site is accessible.

Back to top

© 2008 Chris Hoffman. All rights reserved.

Photograph of Amy Ruell, © 2007 P.J. Gardner. All rights reserved.

Back to top