Configuring Your Machine For Testing With A Screen Reader

By Todd KlootsDecember 30th, 2008

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.

Step 1: Install A Virtual Machine

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.

Step 2: Install Browsers

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.

Step 3: Install & Configure Screen Readers

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.

Configuring JAWS

Changing The Virtual Buffer Toggle Keyboard Shortcut
  1. Open the “Keyboard Manager” dialog by selecting “Utilities” -> “Keyboard Manager” in the JAWS application menubar. Screen shot of the JAWS menubar.
  2. Select the “default” profile in the left, “Profile” pane.
  3. In the right pane, sort by the “Script Name” column, then find and select the item named “VirtualPCCursorToggle”.
  4. Open the “Change Keystroke” dialog by either right clicking on the “VirtualPCCursorToggle” item, or by pressing Ctrl + H. Screen shot of the Keyboard Manager dialog in JAWS .
  5. In the “Change Keystroke” dialog, choose the new keystroke by pressing the desired keys. (I use Ctrl + Shift + Space.) JAWS will warn you if the keystroke you choose in already in use. Screen shot of the Change Keystroke dialog in JAWS.
  6. Press the “OK” button to close the dialog.
Disabling JAWS From Starting Automatically
  1. Open the “Basic Settings” dialog by selecting “Options” -> “Basics” in the JAWS application menubar. Screen shot of the JAWS menubar.
  2. In the “Basic Settings” dialog, make sure the checkbox labeled “Automatically start JAWS” in not checked. Screen shot of the Basic Settings dialog in JAWS.

Configuring Window-Eyes

Changing The Virtual Buffer Toggle Keyboard Shortcut
  1. Open the “Browse Mode Hot Key Definitions” dialog by selecting “Hotkeys” -> “Browse Mode…” in the Window-Eyes application menubar. Screen shot of the Window-Eyes menubar.
  2. In the “Browse Mode Hot Key Definitions” dialog, scroll down to the item named “Browse Mode” in the scrollable “Keys” list. Screen shot of the Browse Mode Hot Key Definitions dialog in Window-Eyes.
  3. Select the “Browse Mode” item and then press the “Capture Key” button.
  4. Press the keyboard combination you want to use. (I use Ctrl + Shift + Space.)
  5. Press the “OK” button to close the dialog.
  6. Save the configuration by selecting “File” -> “Save” -> “Set File and All Dictionaries” in the Window-Eyes application menubar. Screen shot of the Window-Eyes menubar.
Disabling The Mouse Voice

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.

  1. Open the “Mouse Voice” dialog by selecting “Mouse” -> “Voice” in the Window-Eyes application menubar. Screen shot of the Window-Eyes menubar.
  2. Select the “Off” item. Screen shot of Mouse Voice dialog in Window-Eyes.
  3. Press the “OK” button to close the dialog.
  4. Save the configuration by selecting “File” -> “Save” -> “Set File and All Dictionaries” in the Window-Eyes application menubar. Screen shot of the Window-Eyes menubar.
Disabling Window-Eyes From Starting Automatically
  1. Open the “Startup Options” dialog by selecting “File” -> “Starup Options…” in the Window-Eyes application menubar. Screen shot of the Window-Eyes menubar.
  2. In the “Startup Options” dialog:
    • Uncheck the checkbox labeled “Run Window-Eyes at the Login Screen”.
    • Uncheck the checkbox labeled “Run Window-Eyes after login for all users”.
    • Select the radio button labeled “Never” under “After login for Current User, Run Window-Eyes”.

    Screen shot of the Startup Options dialog in Window-Eyes.

  3. Press the “OK” button to close the dialog.
  4. Save the configuration by selecting “File” -> “Save” -> “Set File and All Dictionaries” in the Window-Eyes application menubar. Screen shot of the Window-Eyes menubar.

Configuring NVDA

General Settings For Efficiency
  1. Uncheck the checkbox labeled “Show this dialog when NVDA starts” that pops up the first time NVDA starts Screen shot of the NVDA welcome dialog
  2. Disable the confirmation dialog that pops up when you exit the application:
    1. Open the “General settings” dialog by right clicking on the NVDA system tray icon and selecting to “Preferences” -> “General settings” in the context menu. Screen shot of the NVDA system tray context menu.
    2. In the “General settings” dialog, uncheck the checkbox labeled “Warn before exiting NVDA”. Screen shot of the General settings dialog in NVDA.
    3. Right click on the NVDA icon in the system tray and select the “Save configuration” menu item in the context menu. Screen shot of the NVDA system tray context menu.
Disabling the Mouse Voice

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.

  1. Open the “Mouse settings” dialog by right clicking on the NVDA icon in the system tray and selecting “Preferences” -> “Mouse settings” from the context menu. Screen shot of the NVDA system tray context menu.
  2. In the “Mouse settings” dialog, uncheck both “Report text under the mouse” and “play audio coordinates when the mouse moves”. Screen shot of the Mouse settings dialog in NVDA.
  3. Right click on the NVDA icon in the system tray and select the “Save configuration” menu item in the context menu. Screen shot of the NVDA system tray context menu.
Changing The Virtual Buffer Toggle Keyboard Shortcut
  1. Shut down NVDA – right click on the system track icon and choose “Exit” from the context menu.
  2. Navigate to the path “C:\Program Files\NVDA\appModules”. Screen capture of the contents of the appModules directory.
  3. Open the file named “_default_desktop.kbd”.
  4. Find the line: “NVDA+space=toggleVirtualBufferPassThrough”.
  5. Change to: “Control+Shift+space=toggleVirtualBufferPassThrough”.
  6. Save the file.
  7. Restart NVDA.

Step 4: Restart Windows & Save State

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.

Steps Summary

That’s it. The steps for configuring your development environment for testing using a screen reader can be summarized as follows:

  1. Install virtualization software
  2. Install browsers & take a snapshot of that state
  3. Install and configure screen readers
  4. Restart the virtual machine & take a snapshot of that state

Resources & Further Reader

13 Comments

  1. 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.

  2. 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.

  3. 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…

  4. 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

  5. Robert Stackhouse said:
    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.

  6. Victor Tsaran said:
    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.

  7. Unfortunately, there seems to be no usable virtual machine software for PowerPC Mac computers. (Yes, there are still millions out there!)

  8. 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!

  9. [...] Configuring Your Machine For Testing With A Screen Reader [...]

  10. [...] 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 [...]

  11. [...] Configuring your machine for testing with a screen reader [...]