Back in the day when web pages were web pages and not web applications you could just about get away with not testing with a screen reader. Using a combination of text based browsers, accessibility testing tools such as the Web Accessibility Tools consortium Accessibility Toolbar and and browser tools such as Preferences settings in Opera (see Opera > Quick preferences or Preferences), you could more or less muddle your way through.
This is not the case now though as browsers, screen readers, guidelines and technology has moved on and in many ways is catching up with one another. What follows are some tips to get you started when setting up a screen reader testing environment.
Why test with screen readers
- Browser support for WAI-ARIA: Varying levels of support can be found in Opera 9.5, Firefox, Safari and IE8.
- Screen reader support for WAI-ARIA: Screen readers are also catching up with varying levels of support in Jaws, WindowEyes, NVDA and Orca.
Set up a sandbox
Whether on Mac or PC you want to set up a screen reader testing sandbox. This means you can isolate glitches with installs as well as crashes and reboots. If you’re on a Mac there is more need for a sandbox as screen readers tend to be built for Windows. There’s plenty of virtualization software out there to help you do this including Parallels, VMWare, Virtual PC and so on.
Test with a variety of screen readers
Next you need to find screen readers that support WAI-ARIA. It’s not practical to buy every screen reader on the market although it is advisable to get what you can. If budgets are low there are plenty of free options available to you:
- Jaws from Freedom Scientific: designed for Windows the free demo allows for you to test for 40 minutes at a time before rebooting.
- WindowEyes, GW Micro: a fully functional demo is available for Windows but times out after 30 minutes.
- NVDA, NV Access: again just for Windows and only works with Firefox however it is available in full for free.
- Firevox: available in full for free on Windows and Mac but only works with Firevox.
- Orca: available on Linux, free and open source.
- Fangs: this screen reader emulator is a Mozilla Firefox extension that displays a text representation of a web page similar to how a screen reader would read it.
- Thunder: available for Vista or XP.
Configuring screen readers
Screen readers are designed for the non-sighted user so you may want to set preferences to disable or change what you don’t find useful. For example I always switch off automatic page scroll in Jaws as I don’t want the page to scroll in line with the content being read out. You may also want to disable features that have the screen reader start up automatically as you boot your system up.
You may also find it useful to configure your screen reader keyboard shortcuts so that they are all the same in each one. That way you don’t have to remember one thing for Jaws and another for NVDA.This can be especially useful with regards to shortcuts for switching the virtual buffer on and off.
One final tip is to take a snapshot of everything once it is installed, this means you have it at hand to revert back to should anything go wrong. This can be done at various different stages throughout the set up on the sanbox.
Ensure that you have all the browsers that support ARIA installed on your machine (see above).You really should be testing across browsers just as you would in any development process.Note that while Opera is building in WAI-ARIA support that it works best with a screen reader on Mac with Windows to follow.
- Get comfortable with a screen reader first: finding your way round using a screen reader can be a tricky process. I’d recommend never diving in and testing unless you’ve spent some time just browsing the web in general and getting familiar with the environment. One really good trick is to spend an afternoon, day or a week browsing the web with just a screen reader with the monitor and mouse switched off. This is the ultimate crash course and once you’ve done it you’ll have a much better understanding of the types of challenges people face when browsing.
- Use real users: ultimately real users will reveal much more than just you testing or even just one genuine screen reader user testing. Use any screen reader users in-house you may have but also make sure you test with regular users. Often screen reader users within a development team are power users so mixing it up a bit with regular users is important. Never assume you know what the best solution is.
- Switch off the monitor: so often it’s not the technical accessibility that is a problem but how easy it is to follow and discover information. Simply put is what the user hears making sense? Have you described roles, states, properties and live regions appropriately? Do you need to teak the text on the page to make it clearer what the page is doing?
- Disable your mouse: check that all widgets and functionality can be accessed and triggered using only the keyboard just as you would if accessing desktop widgets. Check that you can use either shift or arrow keys to get focus onto elements and manipulate them. For example tab onto a slider then use the arrow keys to move the slider back and forth.
- ARIA test cases: Before you start testing make sure you know what support there is for the ARIA being tested. The best plac to look for this is the ARIA test cases page on Codetalks.