Three things I learned about screen reader users
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:
- 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.
- 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: nonein 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.
- 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
legendelements 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.