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.
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.
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).
- 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.
- 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.
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.
Great article, as usual.
I would also add: If you are using CSS to hide part of a link (as in Sufficient Technique C7 in WCAG 2), do not hide the first part of the link. Doing this will make the trailing, visible, part of the link in effective.
Remember a simple phrase: “Say what you see” and you should be OK.
Of course, a Dragon user may be aware that you can just say “Links” and all links will be presented with a numbered value. Speaking the desired value will activate the appropriate link.
Thanks for wrting the article, it’s good to see a technology that is often over looked as AT given a write up. The observations for developers are important considerations.
However, I think you are wrong to dismiss the need to test with Dragon as it has quirky behaviour and nothing beats real world testing. Also isn’t your assertion that Dragon is expensive at $200 a little at odds with the fact that the accessibility community is pretty keen on encouraging developers to test with Jaws and ZOOMTEXT which are more expensive and have smaller numbers of users.
Great point, Neil.
Especially on the cost aspect.
I wonder what the total cost actually would be to set up a test environment with the “most used” AT?
Just the purchase cost, not the most important factor of training and education of the testers.
Excellent post! Thanks for sharing it. I was always keen on knowing about speech recognition interaction on websites from Accessibility point of view since I have not been able to try it myself as yet.
I have couple of questions based on your post:
1. You have recommended to avoid using drop-down menus working on hovering the mouse: fair enough but wanted to know does it work fine if the drop-down menus are made keyboard accessible or drop-down menus are a complete no-no?
2. How does Dragon react to image icon button/links, such as ‘Search’ or ‘Start/Stop’ buttons? How can a user know what is the alt specified and how do they give command to activate the same? Does Dragon display the alternate text for users?
I feel my second question is sounding basic but would love to know answers to both of them.
Dragon Naturally Speaking (DNS), works better with IE, but there is a plug in for Firefox that helps, though I do not know if it works with the newest version of Firefox (or if there is an updated plug in).
When you try to access labels that have the same name, DNS numbers the ambiguous labels and you pick the one you want by its number.
I noticed the ‘push’ this holiday season for a version of Dragon. One thing I noticed is that all selling of Dragon is based on ‘normal’ people using it as a productivity tool. For people that have a speech impediment, I would guess that Dragon and other tools would be crippled (sorry for the pun) in accurately writing what is said.
I bring up this point to say that visual and cognitive are not the only disability types. Also, they are not usually one OR the other.
Great article though. It is so refreshing to see a real review when selling is not the goal!
I am curious, Is this software recommended for persons with dylexia only or vision impairments as well? What percentage of folks use this software?
This Software is truly for anyone Nancy. It’s not that you have to have a problem that doesn’t allow you to type (It could help for that situation) but it can also help increase your productivity at home or even work!
Just as a note, great article. If you can try testing with ZoomText and Dragon at the same time. You will find the results quite productive.