Three things I learned about screen reader users

Belorussian translation provided by Fatcow.
German translation provided by Alexey Gnatuk.

As many of you know, I’m currently working on my HCI master’s thesis which is investigating the convergence of accessibility and usability in web design. (My research has considerably changed its focus since my original entry on the project.) In the past two weeks, I’ve tested with two vision impaired users and three completely blind users. Going into the tests, I had my own ideas about how screen reader users browse the web, so when I observed them actually using screen readers I was quite surprised. Not necessarily related to my research, here are the three biggest finds that I made during those tests along with my recommendations on what you can do about them:

  1. No one that I observed used the access keys that I specified in the main navigation. When I asked them why, the response was always the same: because they often conflict with other programs. My recommendation is to take a good hard look at the access keys you specify on your website and make sure they don’t conflict with browser or screen reader shortcuts. Thankfully, the good folks at Web Accessibility Testing and Services have already started looking at this. Here’s their article on the topic.
  2. Everyone that I observed used the JAWS screen reader. Before the main and sub navigation, I created a skip navigation link and hid it using display: none in the CSS. In each test, JAWS failed to read the skip navigation link, rendering it useless. My recommendation is to make sure most major screen readers can read your skip navigation link. Thankfully, the good folks at the CSS Discuss Wiki have researched the issue and designed an improved method that works in 11 major browsers.
  3. Finally, here’s a more obscure yet useful find. JAWS has a special mode for entering information into forms, aptly called forms mode. When you’re in forms mode, you can manipulate the control using the up, down, left and right arrow keys, move to the next control using TAB and move to the previous control using SHIFT+TAB. The form I created had a few text inputs for entering credit card details, then a heading which read “Enter billing address,” then a number of inputs for entering the billing address. So after entering their credit card details, they hit TAB as they normally would. The next thing they heard was “Address Line 1,” but they didn’t know what address it was asking for because forms mode skipped over the heading in the middle of the form. If you have a form on your website with descriptive text in the middle of a form, such as a heading or paragraph, my recommendation is to do one of two things. Either explicitly label each control so that it’s completely understandable when taken out of context. (For example, use “Billing Address Line 1” instead of “Address Line 1.”) Or split the form between two pages so that it’s more easily understood by screen reader users. use the fieldset and legend elements as suggested by Derek Featherstone’s comment. Thanks Derek!

I hope you find these findings and recommendations helpful. I’d love to hear more interesting findings and recommendations from others so share ‘em if you got ‘em.

Comments

  1. A nice post, Joshua… Just a couple of quick comments about forms:

    Either explicitly label each control so that it’s completely understandable when taken out of context. (For example, use “Billing Address Line 1” instead of “Address Line 1”) Or split the form between two pages so that it’s more easily understood by screen reader users.

    I’d suggest another alternative: use <fieldset> and <legend> to group related form sections. This has the advantage in forms mode to actually announce the legend text, then the field name so you can keep your labelling a little more concise (though I can’t argue with your example that “Billing Address Line 1” is better than “Address Line 1”)

    Not only does it give nice structure for screen reader users (I’ll have to check to see if WindowEyes announces the legend text… I can’t remember at the momemt), but it also provides nice structure for all users, including those that have full vision.

    Cheers,
    Derek.

  2. I’ve never been able to test my work with vision impaired or blind people, so these insights are very valuable. Thanks for sharing!

  3. Like the above poster, I have never tested anything with the vision impaired. In fact, I have to admit that it hadn’t really occured to me. Thanks for the post.

  4. cafedave.net linked to this interesting post, Three Things I Learned About Screen Reader Users on http://unraveled.com. You should hope over there and read the whole thing, but here are my notes: Make sure [access keys] don’t conflict with browser or

  5. A few good links to get you into the fall/school season: A better image rotator by Dan Benjamin (from A List Apart) Three things I learned about screen reader users by Joshua Kaufman (Unraveled) Real World Web Design by D. Keith Robinson (Asterisk) Dyn…

Comments are closed for this entry

Please send your feedback via Twitter to @jmk.