Evaluating accessibility with ChromeVox
Google ChromeVox has a very low learning curve and is perhaps the easiest screen reader for web production folks to use for accessibility verification. ChromeVox is intended to be the native screen reader for Chrome OS, but it has the worthwhile side benefit of being available as an extension for the Chrome browser. It has a very simple command set. Basic navigation is as follows:
- Alt + Control + Down Arrow = Navigate forward
- Alt + Control + Up Arrrow= Navigate backward
- Alt + Control + Right Arrow = More detail
- Alt + Control + Left Arrow = Less detail
- Enter = Activate current item
- Space = Force click on current item
There are many other commands at your disposal to navigate particular page elements, but these commands will suffice for most testing. View a list of ChromeVox shortcut keys (PDF).
Because it is brand new, ChromeVox depends on experimental Chrome APIs, and you can’t install ChromeVox without first enabling them in Chrome. To enable the experimental APIs, enter
chrome://flags in Chrome and click
Enable under Experimental Extension APIs. Or, you can run Chrome from the command line with the
It would be nice if you could toggle ChromeVox from an icon on the menu bar, but at present, you need to open up the extension window in Chrome and enable or disable the extension from there. A bit clunky but it gets the job done.
The testing procedure
The following is a sample testing sequence using ChromeVox that you can use as a starting point for your evaluation.
- Download and install ChromeVox.
- Open ChromeVox by enabling the extension in the extensions window. From the wrench menu select
Tools > Extensions, and then click the
Enablelink underneath ChromeVox.
- Type in the address you want to check in the address/search field.
- Select the “object” parsing granularity (
alt+control+right_arrowonce). This granularity ensures that links will be read. After you are feeling comfortable, explore the other granularity settings.
- Listen to the page from top to bottom (
- Return to the top of the page (
- Listen to the page title. It should be read automatically after reloading the page. Does it uniquely describe the page content?
- Tab through links and form inputs (
tab). Are they read in an order that makes sense? Does any content receive focus besides links and inputs?
- Scan the headings (
alt+control+p+h). Does the page have headings? Are the heading levels read?
- Scan the link phrases (
alt+control+p+l). Do the individual phrases make sense? Are there ambiguous or redundant entries?
- Tab through the links:
- Does each link work? (press
- Does each link phrase match the destination page title?
- Does each link work? (press
- Test any web forms:
- Go to the next form field (
alt+control+n+efor text fields and
- Are form labels announced with input boxes or operations?
- Do the forms work?
- Can data be entered and the form submitted? (
- Go to the next table (
- Are table captions or summaries read?
- Does the table information make sense navigating between cells? (
- See if you can get the headings to be announced for each cell (
- Is the type of widget (e.g., “drop down list”) announced when it receives focus?
- Can the widget be manipulated using the keyboard?
- Is it clear how to use it?
- If it is not clear how to use the widget, is an explanation provided?
(This is list is a modified version from the original JAWS protocol published by the Usability & Accessibility Center, Michigan State University)