Like many web accessibility folks, I spend quite a bit of time using screen readers. I use them when conducting accessibility evaluations and when training others. Hardly a week has gone by in the last few years that I haven’t spent some time using a screen reader. They are unique programs that deserve special attention.
With all the time I’ve spent using screen readers, I wonder if my view of accessibility is a bit screen reader-centric. I’m not suggesting that I ignore other accessibility issues. I test for color contrast, enlarge content, check keyboard accessibility, look for visible focus indicators, etc. These principles and activities are part of our trainings as well. But most of this testing and training is done in the browser or by using tools like WAVE or the Web Developer toolbar. The truth is, with the exception of screen readers, I spend very little time using assistive technologies.
The experiment
In the next few months, I plan to familiarize myself with other common assistive technologies (AT) and share some of my experiences. First on my list is a screen enlarger or magnifier, probably ZoomText. I plan to spend a week or so just playing around and getting used to it. During this time, I will also search for articles, tutorials, forums, etc. that might help me get up to speed. Next I will try tasks, such as checking and composing email or ordering something on Amazon. My "final exam" will be a full day relying on the assistive technology. I am quite nearsighted, so I will probably remove my glasses to keep me from cheating. This will probably be more difficult than it sounds. I am sure it takes much longer than a few days to become proficient with any assistive technology.
At the end of the experience, I will write a blog post recapping my experiences and possible frustrations, with a focus on practical accessibility recommendations that I discovered or that were reinforced during my experience. If the experiment is a success, I may follow up with other assistive technologies or configurations every month or so. A few come to mind:
- Voice-controlled software, such as Dragon Naturally Speaking
- Windows high contrast mode
- Keyboard-only, maybe using some kind of AT
I am open to recommendations, but will probably limit this to AT that is relatively easy to learn, and will yield valuable accessibility recommendations.
As I embark on this experiment, my goal is not to promote myself as an AT expert, or as a spokesman for those with disabilities. Spending a few weeks using ZoomText is not a substitute for a lifetime of experiences of individuals who rely on a screen enlarger for their daily computer use. My primary goal is to acquire and pass on a better understanding of how we can make web content more accessible for all users, and how these tools can be used in our own training and evaluations.
Is AT proficiency necessary?
Am I suggesting that every website must be tested with a dozen unique assistive technologies before it can be pronounced "accessible?" No. That would be a step backward. I do not want to return to the days of "until user agents…." any more than web developers want to go back to testing for Netscape 4. WebAIM has always advocated a principle-centered approach to accessibility, and we know that encouraging developers to follow good accessibility principles is challenging enough. However, I think personal experience with some common, but often overlooked, assistive technologies could help me, and hopefully others, better learn and address the diverse needs of users who benefit from accessible design.
Hi Jon, I’m Blaine Clark. I’d like to suggest Vinux for one of your trials. Vinux stands for Linux for the Visually Impaired. It’s a project that is over two years old and is gaining momentum. On the web site I’ve provided you can find much more info and links. Linux has been lagging behind other OS’s in fine-tuned accessibility features and Vinux is working on addressing this and putting focus on the issue.
Thanks,
Blaine.
Hi Jon:
It would be wonderful if you could try out some text reader software designed for people with learning disabilities, such as Kurzweil 3000 or WYNN (both of which have self-contained browsers). It’s often assumed that screen reader compatibility equals compatibility with these programs, and that’s not necessarily true. Thanks–
Jane Vincent, Center for Accessible Technology, Berkeley, CA
Jon,
Great initiative! Re ZoomText, will you try out the screen reading functionality in ZT, or stick to the magnification feature set?
Nice going Jon! I like your approach here. I don’t know if you’ve tried out the System Access Mobile browser yet, but I’m a huge fan. It can be used with other screen readers too, not just System Access. I’ve never done this but it is listed in Serotek’s very well-written documentation. In addition, I recently upgraded to Internet Explorer 9 on my apartment computer and really like it. A colleague of mine upgraded downstairs in my building and he asked me to test out IE9. I tried it with NVDA and SA, and I found it to work a bit better with SA. I think Microsoft has done a great job with accessibility. I’ve heard a lot of complaints from people, but thus far I have very little if anything negative to say about Microsoft.
Great post Jon. For me, the money is in the last paragraph:
About ten years too late I’m starting to see developers show some interest in assistive technology. They get to play with new software and hardware, always a strong motivator, and the company gets to show intent with receipts from software and hardware purchases. Win, win. But from this Mac designer’s perspective, mastering JAWS on a PC well enough to say problems were with page code and not user error is way beyond my ability. We have instances of JAWS popping up all over, but no one seems aware that JAWS and WindowEyes may give different results. It’s wonderful to see awareness growing, even if it’s linked to software play. I think it would be better to see standards awareness growing, too. Standards that Freedom Scientific are working towards as well as are GW Micro, Mozilla, Safari, and Adobe. It’s really hard to argue with the “intent” shown by the purchase of several JAWS Pro licenses at $1095 a pop, but in reality, following standards and contributing to their development may actually solve problems without the cost.
Hi Jon –
Great idea, I’m looking forward to your impressions and thoughts. I’d love to see what you think of VoiceOver on a Mac. I like it on the iPad, but haven’t tried the full version on a Mac yet. It would be great to know how it works compared to JAWS and NVDA.
I’m really glad to see that you’re doing this. All of my testing involves Dragon NaturallySpeaking because, well, it has to for me to be doing it. 🙂 But lately I’ve been trying to do a lot of testing with NVDA as well, and you are right, I should be looking at ZOOMtext and the other kinds of assistive technology we don’t tend to think about that much.
I would love to see more accessibility engineers testing with NaturallySpeaking, because it’s a very different kind of accessibility need than screenreaders, and I’d like more accessibility engineers and advocates to understand the specific complications of hands-free computer use.
Hi Jon.
I broadly agree with drs18’s comments. I think developers should work to standards as the best way to ensure accessibility. If that were more common and more vociferously supported by developers then creators of browsers, etc., would be more inclined to fall into line.
But to come back to your experiment: good idea! I also tend to be rather screen reader-centric although I do test with Dragon. ZoomText – not so much, so I look forward to your conclusions.
One point – if you test with screen readers a lot then doesn’t that pretty much cover keyboard only?
Good to hear you’re doing this. Not to sound negative or equally single-issued, but I get tired of hearing web developers or programmers say that they’ve tested with JAWS and therefore the site or application is accessible and Section 508-conformant. When I remind them about speech recognition software, it’s rather cavalierly dismissed. At best, they’ll respond that designing to and testing with JAWS covers that. If I can’t see what the real code is for an on-screen command button or icon (which a screen reader user will hear), I still have no idea what to speak to the computer to get it to do anything.
My suggestions:
1 – Code to the Standards
2 – Have testers who are fluent users of assistive technology do the usability and AT testing.
Great questions and responses. Sorry for not replying more promptly; I was out of the office for about a week and spent the last day or two playing catch-up. I’ll try to respond to most of the comments throughout the day, starting with Gary (since his comment is only a day old) and then going back to the beginning.
Gary, I agree that you should start with standards, and I am glad you mention usability testing, not just AT testing. In our trainings we often discuss the difference between “technical” accessibility and “true” accessibility. AT testing can be valuable, but the focus is often compliance with a specific AT, or “technical” accessibility. Including users with disabilities in your user testing is often a better way to evaluate “true” accessibility.
Hank, Jake, and Kim-
I don’t have any plans to look at any additional screen readers (Vinux, System Access, and VoiceOver) at this time.
Kim, Jared Smith and I gave a presentation in March at CSUN comparing JAWS, NVDA, and VoiceOver. A PDF version of the presentation slides is available online. The bottom line is that no screen reader is perfect, but all provide an adequate experience. As a matter of fact, NVDA is quickly becoming my preferred screen reader for testing. I’m not a Mac user, but I know that Jared uses VoiceOver extensively likes it quite a bit.
Jennison-
Although I experimented a bit with the screen reader in ZT, I have decided to focus on the magnification feature set.
Hi Jon
I work for the Herefordshire council testing websites that are already live and about to be published. I test with JAWS and Voice Over and on an ipad too. I’ve seen a vast improveemnt over the past few years regarding accessibility and it’s people like us that can make a difference.
I wondered if you have ever used software called BrowesAlowed? It’s free software that you can download and use on any BrowesAlowed enabled website. It can translate text into other languages, as well as some other neat features. It does have several downsides, like it’s very slow, needs to be used with amouse and only works on BrowesAlowed enabled websites. Currently there are only 2000 sites with the software but my boss is insisting that I test with it on all the sites I test. it’s a nightmare. I’d like to see what you thought of it.
best
Rachael Donnelly
Jon,
I’ve been testing Win XP and Win 7 High Contrast themes and have found them lacking (they seem to require a bit of tweaking in my experience). I’ve also stumbled upon slips, oversights, and less than excellent design on sites that are supposed to meet the minimal requirements of ADA 508, though at least in our institution, things are much better than even a three or four years ago.
Yet, for example, something as common as Zimbra’s web-based e-mail, which our institution is pushing users to adopt as the only way of managing e-mail, has obvious flaws in high contrast mode (e.g., can’t see selection check-boxes or other columns for tagging etc…).
I’ve searched for two items that may be of interest to your readers:
(1) Something analogous to “Nocturne” (currently only for Mac) for PCs
(2) Better high-contrast themes for Win XP and Win 7 than the stock ones (is it possible the problems with Zimbra have to do with the theme?).
If you could find and test either of these items (I’ve had no luck), that may be helpful to some.
Cheers,
F.