It's official: Level Access and eSSENTIAL Accessibility are becoming one! Read the Press Release.

SSB recommends testing with multiple types of assistive technology (AT) whenever possible. The focus of AT testing is not to verify technical compliance but to understand whether the implementation is accessibility supported and whether the content is functional for people with disabilities. This functional testing optimally includes speech recognition, screen readers, screen magnification, and other accessibility features used by people with disabilities such as color and contrast software, switch control, and devices used by people who are deaf or hard of hearing etc.. Historically some people have focused testing efforts with screen readers only this does not accurately reflect the experience of all users including speech recognition users.

It is important to know the commands available with speech recognition software and to be able to identify limitations with speech recognition software versus inaccessible implementations. For example, direct voice commands to activate or focus controls by name provide efficiency to users as do keyboard commands in a site or application — these keystrokes can be voiced. On the other hand speech commands such as the mouse grid which allow the user to perform mouse operations including drag and drop by a series of steps to winnow areas of the screen are cumbersome at best and do not provide equivalent facilitation to users of speech recognition.

While many technical solutions to accessibility challenges will benefit users of multiple types of assistive technology there are certain implementations that are more likely to cause issues for users of speech recognition software. All organizations have limitations in time available for testing and thus it is helpful to focus these testing efforts to specific situations that are crucial to evaluate the functional experience with Dragon and other speech recognition software. Below is a list of implementations that may present accessibility challenges.


Scrollable containers (e.g. scrollable divs)

Unless an item in the scrollable div can be focused there are no Dragon or keyboard commands that can be voiced to scroll the div. Please note, this does not apply to pages that happen to scroll because content in the body element will not fit on-screen at one time. Speech recognition software provides commands to scroll the body of web pages.

Controls without visual text labels

When controls do not have visual text labels users of speech recognition may not know what text to voice to directly activate the control. Speech recognition software often has commands to place a number by all interactive controls or interactive controls of a certain type — then the number can be voiced to focus or activate the control. This technique however may not be as effective. Missing visual labels also provide issues for cognitive impaired users.

Visual labels that don’t match the accessible name of a control

When a field has a visual label such as “given name” but the accessible name of the field has another label such as “first name” via a title attribute, off-screen label, or ARIA aria-labelledby users of speech recognition software will not know the accessible name and will voice the on-screen label and thus will not be able to interact with the control using direct voice commands.

Form fields that use Implicit labels

Dragon does not support direct voice access for form fields that use implicit labels. E.g.

<label>First Name: <br />
<input type="text" /> </label>

Explicit labels need to be used to associate labels with form fields so these fields may be directly access by voice commands.

Rich text entry

Rich text fields like Google docs use custom coding to handle text entry, deletion, and modification. These fields may not work as expected with commands in speech recognition to manipulate text. Voiced keyboard commands may be helpful.

Mouse heavy interactions

Mouse heavy interactions such as rollovers or drag and drop commands may be difficult for users of speech. Keyboard equivalents may not be apparent. Be sure to provide instructions and advise users of all keyboard commands.

Custom keystrokes

Speech recognition users can voice keyboard commands to interact. When custom keyboard commands are required to access content but not available on-screen speech recognition users are likely to not know the custom commands.

Simulated controls such as modal dialogs

Simulated dialogs may pose focus issues and may be absolutely positioned on-screen and artificially hide content in the background via a mask. Be aware that speech recognition software may present or allow activation of content that is not in the dialog to the user.


Dragon prior to version 13 did not support the Accessible Rich Internet Application specification (ARIA). Dragon users may not be able to access fields with direct voice commands and commands such as “click checkbox” may not work at all if ARIA is used indicate the role of checkbox. Even in Dragon 13 some ARIA properties such aria-label are not supported.

Hidden content for assisted technology

Some pages contain hidden links or hidden text aimed to assist users of screen readers. Some of these hidden links or text may benefit speech recognition users but if they are hidden these users will not be aware of them. For example, hidden text that provides keystroke information or custom labels for form fields would not be available to users of speech recognition.

Alternative pages

Alternative pages may be used to meet accessibility requirements. One common technique is to provide a hidden link to the alternative page that can be access by users of screen readers. If users of speech recognition are not aware that they need to/can use the alternative page then they may continue with the standard page and run into accessibility issues.

Fixed positioned links

Fixed position links such as sticky menus that stay with the user when the page scrolls may not work correctly when the user voices “click link” as Dragon will only display numbers of links to choose when it believe links are on screen. Dragon does not accurately work with fixed positioning and won’t display the links unless the user is at the top of the page.

Other Speech Recognition Considerations

Currently, speech recognition is generally not available in the same manner as Dragon to interact with and control applications on mobile devices such as iOS, Android, and Windows Phone and thus is less relevant to mobile web navigation unless a browser that supports speech is used. Speech recognition on mobile platforms is often limited to system commands and dictation and is generally available within application input fields.

Both Windows and OS X also include speech recognition. The Windows Speech Recognition features are very similar to those found in Dragon. Mac dictation is enabled available by default but speech control on the Mac must be enabled and downloaded. The Windows and Mac speech solution also do not support ARIA as of this post.