It was Jeffrey Zeldman’s excellent book Designing with Web Standards (soon to be published in its second edition) that drove home to me why accessibility is important.
You see, Web accessibility is more than simply allowing blind or disabled computer users’ access to your content. It is also about allowing users who view your website on their mobile phone, or on a small screen PDA, and it is also about allowing users who haven’t upgraded their web browser from Opera 5.14, because Opera stopped developing for your chosen operating system (EPOC R5/Symbian OS v.5, since you were asking). Web Accessibility is more than simply applying real world disabled access concerns to the Web; accessibility is as much about physically able-bodied users as much as it is about users who cannot view a screen, or use a mouse.
That said, I jumped at the chance this week to watch someone from church use their PC using Jaws for Windows, one of the world’s most popular screen reading applications for the Microsoft Windows operating system.
I’ve read about screen reading software, but never seen it (or heard it) in action. I’ve been encouraged to include
alt tags in image code, so that screen reading software can read out what the image is of. I’ve been encouraged to set up
accesskey attributes in links so that users can access the links quickly using keyboard shortcuts (eg Alt+2). I’ve been encouraged to write pages so that the page hierarchy makes it easier for users to navigate (using different levels of headings within a page, for example).
George — a member of one of the congregations I’m working with just now, who is blind — booted up his PC and introduced me to Jaws. A few things struck me as I witnessed George navigating the Windows XP desktop and then his browser (Mozilla Firefox, I’m pleased to report).
For some reason, with screen reader software I assumed that the user would wait until the software had read the whole screen (or window) from top to bottom, starting with the window title and working its way down until he or she made their next move. But why would they? That’s not what sighted users do. Sighted users quickly scan the page, find what they are looking for and click through to the next experience.
George did exactly the same, only his was an audio scan. Using a combination of key presses (and trust me, with Jaws there are many, many, many key combinations to learn) George was able to hear what was on the screen. In Firefox, for example, he was able to immediately hear how many links were on a page (and have them read to him one by one — he could quickly skip to the next with a key press until he found what he was looking for). Or how about headers? Jaws could give George a quick overview of the structure of a page by reading out the headers in order (and their level of heading: 1, 2, 3, up to 6). The same was true with tables, lists, images and just about any screen element, or window element.
What I also found a little surprising — though not as surprising as George — was the
accesskey settings on my blog. They conflicted with Jaws’ built-in shortcuts. The accesskey keyboard shortcuts use the Alt key plus a key that you can specify in your code. When George pressed Alt+3 my accesskey page setting took precedence and whisked George off to the Archives page on my blog.
“Oh! What happened there?” said George, rather surprised.
I explained that I’d set accesskeys to make the page more accessible, but that I now realised that it interfered with Jaws’ default keyboard shortcuts. I’m not sure what the way around this might be. Presumably there may be some users who would appreciate the shortcut keys who don’t use screen reader software, while the Jaws’ users who might not use the shortcuts find that it interferes with their setup. Hmmm…
I was there for over an hour, carefully watching and listening, and asking George questions about what he was doing, and why. The experience has made me realise that when I do Website usability studies in the future it would be important to include at least one study with a screen reader and/or braille keyboard user.
Sadly George’s braille keyboard was being sent back for repairs, otherwise that too would have been fascinating to watch. Seemingly the keyboard is two way: you can read the screen contents, created using on long line of interactive braille dots on the keyboard, but you can also enter text in a similar way that you can on a standard braille typewriter. You what this means? I’ll just have to go back!
All in all we’ve come along way towards making computers and the Web accessible. But there is still a long way to go.