Assistive Technology Experiment: Dragon NaturallySpeaking

This is a continuation of a series of posts about my personal quest to learn more about some common assistive technologies. In my first post, I outlined my experiences with ZoomText. Since then, I have become more familiar with the speech recognition software Dragon NaturallySpeaking (Premium) by Nuance.

Using Dragon

Speech recognition software such as Dragon serves two roles: it converts speech into text and it allows users to navigate through content using spoken commands. It is typically used by individuals with motor disabilities, but may be used by people with other disabilities (e.g., cognitive) or in conjunction with other AT for users with multiple disabilities (e.g., Dragon and JAWS). Speech-to text has little impact on accessible web design, so I will not focus on it in this post. Instead I will look at how Dragon is used to navigate through web content, and what this means for developers.

Design Recommendations

Dragon navigation functions can be divided into keyboard interactions (navigating to links and form controls) and mouse interactions (moving the mouse cursor). Recommendations for each type of interaction are identified below. A few notes/disclaimers first:

• I do not rely on Dragon due to a disability.
• Commands that allow a user to navigate through tabs and windows, search within a page, scroll up and down, etc. have more to do with interaction with the browser than with web content, so they are not addressed below.
• Although Dragon supposedly "supports" Firefox, I had a great deal of difficulty using Dragon in Firefox and ended up relying on Internet Explorer 9 for all of my testing.
• Nuance has also created Guidelines for Speech-Accessible HTML (PDF).

Keyboard Navigation

Links

• Do not disable visible keyboard focus indicators (by default, a dashed line around focused links). Users may navigate through links and form controls by saying "Tab", but it is very difficult for the user to access these links if they cannot see which of the links currently has focus.
• Ensure that the visual order and tab order of content is the same — typically navigation first, then left to right, top to bottom.
• If the link is an image, alternative text should match the text in the image. For example, if an image displays the word "Continue" visually, the user will probably say, "Link continue" to activate the link. If the alternative text does not match the text that appears visually the link will not be activated.
• Use unique link text, when appropriate, especially if the links go to different pages. While the user can select from multiple links that contain the same text, it requires an additional step and may be more confusing for some users.
• Avoid starting links with generic text like "click here", "read more", "learn more", "link to", etc.

Forms

• Use form labels. A user can navigate to a specific form control by saying the label name (e.g., "click First Name"). This process becomes much more difficult if labels are absent. If form labels are not correctly associated to their controls, Dragon will try to guess the correct label based on proximity, with varying success.
• Use the appropriate form control. Users can navigate to form controls based on the control type. A user may try to submit a form by saying "click button", but if the button is not a true button or is an image that uses JavaScript to submit a form, nothing will happen and the user will have to find a different way to submit the form.

Mouse Navigation

Dragon can also emulate mouse interaction. While there are several commands that allow you to do this, my favorite was the MouseGrid. Upon saying the words "MouseGrid", a 3 X 3 grid appears on the screen, with each region given a number from 1 to 9. The user says the number closest to the link that needs to be activated with a mouse, which will cause another 3 X 3 grid to appear. The user continues this process until the grid is small enough that the user can click on a mouse-dependent element on the page, such as an image that uses JavaScript to submit a form, like a button. For example, to return to the homepage on this page (by clicking on the logo), a user would say something like "MouseGrid, 1 [moving the mouse to the upper left corner], 5 [moving the cursor to the center of this area], click". MouseGrid can also be used to quickly navigate to a link that cannot be activated using the link text, such as a linked image with no alternative text.

I found that being able to replicate a mouse click was very handy, but it was a very time consuming process and had limitations.

• Avoid content that requires hovering with a mouse (e.g., dropdown menus). They may be difficult or impossible to access.
• Make clickable items sufficiently large. A small clickable target, such as a tiny radio button or image, may be very difficult to access with the MouseGrid. If checkboxes and radio buttons are properly labeled, the user can speak or click on the label, not just the control itself.
• Make sure clickable items look clickable. It was frustrating to activate something with my cursor only to discover that it could not be clicked on.

Shortcomings of Dragon

Although Dragon is a very capable program, I found a couple issues that made using Dragon much more difficult:

• It appears that Dragon recognizes the title attribute on all links and form controls, including images with alternative text and form controls with labels. This can sometimes be frustrating, especially if multiple elements have duplicate title values. Dragon should approach this issue the same way it is approached by many assistive technologies–only use the title attribute if there is no alternative text or label present. This is another reason that the title attribute should be used sparingly.
• When navigating very large pages, Dragon sometimes displays the following message: "Voice commands were not generated for some links; too many links on page". This is because dragon only analyzes the first 200 links and form controls on the page. Links beyond this limit are not accessible by speaking the link text, but they are still accessible through MouseGrid. Form controls beyond this limit cannot receive dictated text, a much more significant issue. While Nuance offers instructions on how to increase this limit (PDF), I would guess that very few Dragon users know this. It may be impossible to account for this limit on very complex pages, but the problem can sometimes be addressed by removing redundant links, or by combining duplicate links (e.g., a product image and the adjacent text description) into a single link.

Is testing with Dragon Necessary?

The question of whether testing with Dragon should be part of developer testing is a difficult one. While we at WebAIM will probably use Dragon for testing of mission-critical pages in larger evaluations, it is not practical to expect most developers to test with Dragon. The reality is that the cost of Dragon Premium can be high (close to $200), and the purchase of a high-quality headset is usually necessary as well. Training Dragon can also be time consuming, though this is less important if you are not using Dragon for dictation.

While it is important to consider the needs of users who rely on speech recognition software, these needs can probably be addressed without actually testing with Dragon. Almost all of the principles identified above can be detected with WAVE or through basic keyboard testing. If you are interested in trying speech recognition without purchasing Dragon, less feature-rich speech recognition software is built into the Windows and Mac operating systems.

Next Up: Contrast

Next I will explore the high contrast options within the operating system. This should be much simpler than learning ZoomText or Dragon. Look for a write-up soon.