When developing using the WAI-ARIA Roles and States, you need to test your code in a screen reader to ensure everything is working as you expect. As a follow up to my presentation on Developing Accessible Widgets with ARIA and in the interest of helping other developers test their code, I thought I would provide some tips on how to configure your development environment for screen reader testing.
Before I install and configure screen readers I start by installing a virtual machine. (This is mostly out of necessity because I use a Mac and the most-popular screen readers run on Windows.) Using a virtual machine provides a couple of benefits when testing with a screen reader: To start, a virtual machine provides a sandboxed environment, so I am protected if anything goes awry when I am installing and configuring each screen reader. (So as not to give the impression that screen readers are unstable pieces of software, this is definitely the exception more than the rule.)
The second benefit to using a virtual machine is that they allow you to save and restore state. This is an especially helpful feature for efficiently testing and re-testing specific pieces or states of complex web applications. So, using a virtual machine can help save you time when testing.
Which virtual machine to use? If you use Windows, you can download and install Microsoft Virtual PC for free. As a Mac user, I have found both VMware Fusion and Parallels Desktop work well.
It is important to remember that to work, ARIA requires a team effort between the browser and the screen reader. To test ARIA you’ll need to install browsers that both support ARIA and are supported by screen readers that also support ARIA. For example, Opera has support for ARIA, but is not supported by screen readers. Currently only Internet Explorer 8 and Firefox 3 have support for ARIA, and are supported by several screen readers for Windows that also offer support for ARIA.
After installing each browser, be sure to save the state of the virtual machine. That way you’ll be able to quickly revert back to a clean, working state should anything go wrong during the screen reader installation.
With the browsers installed the next step is to install and configure each screen reader. The two most-popular screen readers for Windows, JAWS and Window-Eyes support ARIA and work with both Internet Explorer 8 and Firefox 3. Free, trial versions of both products are available for download from Freedom Scientific’s and GW Micro’s websites. The open-source screen reader NVDA also has excellent ARIA support and currently works with Firefox 3. Knowing that most visually impaired users use more than one screen reader, I recommend installing all three for testing.
As a sighted person I disable a couple of features of each screen reader and change some configurations so that I can test more efficiently. For example, most screen readers are configured to startup automatically when you start your computer. This is obviously not desirable when you have multiple screen readers installed, so I turn off that feature. Additionally, every screen reader uses a different keyboard shortcut for toggling the virtual buffer on and off. To avoid having to remember the keyboard shortcut for each screen reader, I configure them all to be the same: Ctrl + Shift + Space. (For more on the virtual buffer, read Making Ajax Work with Screen Readers.)
The following sections provide step-by-step instructions for configuring JAWS, Window-Eyes and NVDA.
By default Window-Eyes will speak in response to some mouse gestures. For example, when you press the left mouse button, Window-Eyes will say “left”. As a sighted person I find this feature unnecessary, so I disable this feature.
Like Window-Eyes, by default NVDA will speak in response to some mouse gestures. For example, when you move the mouse NVDA will play tones to help the user track the position of the mouse. As a sighted person I find this feature unnecessary, so I disable this feature.
With all of the screen readers installed and configured, restart Windows. Once Windows is restarted, take another snapshot of the virtual machine’s state. If you are using the free, trial versions of JAWS and Window-Eyes they will require you to restart Windows after using either product for ~30 minutes. Using the virtual machine, you can revert back to using JAWS and Window-Eyes more quickly than you would if you had to restart Windows.
That’s it. The steps for configuring your development environment for testing using a screen reader can be summarized as follows:
December 30, 2008 at 6:35 pm
As already said on twitter:
It’s incredible that screen reader developers still haven’t thought of making a developer edition that allows people to develop websites that integrate better with their products.
The 5 million steps wizard is just insane. Seriously.
Rant aside, this is a good post that will prove helpful, I just think there shouldn’t be the need of such a thing like this.
December 31, 2008 at 9:22 am
Firevox is a good and free screen reader for Firefox. It’s very easy to install and configure, and is a good option for developers who don’t want to deal with JAWS or other expensive options.
December 31, 2008 at 2:34 pm
Thanks, Todd!
I got a VM setup going using your suggestions in the (terrific) developing accessible widgets preso. The additional screen reader preferences details here are extremely helpful. I was only testing in JAWS before, and the requirement to reboot usually just resulted in me being done testing…
December 31, 2008 at 2:38 pm
Hi Todd,
I would also recommend disabling graphics hooking. This is especially important when running the JAWS screen reader in parallels – they totally mess up your screen. I have a JAWS configuration file and batch file around that allows you to run without installing the graphics engine hooks. Browser access is through engineered accessibility APIs.
Rich
January 1, 2009 at 6:35 am
I’m with Madness, I think if someone really wanted to promote the usage of WAI-ARIA by developers, they’d make it way easier to test in screen readers. Second to that would be finding a way to automate screen reader testing (good luck with that though).
Is there a way to install and programmatically configure these things (like using an MSI)? That would probably violate the EULA of some of the screen readers though since they are proprietary software.
January 5, 2009 at 3:09 pm
It is important to remember that the primary goal of a screen reader is not to be a testing or debugging tool but to allow visually impaired users interact with a computer. “users” is an important keyword in this context because, while it is possible to automate certain user tasks, it is nearly impossible to automate the way a visually impaired user may decide to interact with a web site (or a widget) that was not designed with them in mind. Testing with screen readers is not always easy but so is not testing your code with various browsers on various operating systems.
In my experience, VMWare Fusion on the Mac seems to be the friendliest to screen readers.
See An Introduction to Screen Readers that we did a while ago for a demo of how screen readers are used on the web.
January 9, 2009 at 1:50 am
Unfortunately, there seems to be no usable virtual machine software for PowerPC Mac computers. (Yes, there are still millions out there!)
March 16, 2009 at 5:58 am
We have been testing the websites using JAWS from a long time. Just to make sure we don’t miss anything important as far as accessibility in concerned. This is very helpful information which will surely add some more gems :-) thanks!
July 2, 2009 at 7:43 pm
[...] Setting up a screen reader [...]
August 3, 2009 at 1:24 pm
[...] Configuring Your Machine For Testing With A Screen Reader [...]
September 23, 2009 at 1:11 am
[...] mehr als einem Browser getestet werden. Todd Kloots hat hierzu im YUI-Blog einige Informationen zum Installieren und Konfigurieren von Screenreadern für Entwickler zusammengestellt. Marco Zehe gibt weitere Informationen zum Testen mit [...]
November 20, 2009 at 5:53 am
[...] YUI Configuring screen readers [...]
January 8, 2010 at 4:50 am
[...] Configuring your machine for testing with a screen reader [...]