There is currently a lot of confusion regarding ARIA control types like Listboxes, Tabs, and Menus that do not work as expected in voice navigation software such as Dragon NaturallySpeaking.

The mistaken belief is that if users cannot interact with these controls in Dragon as expected, then they aren’t programmed properly. Often, things are confused even further when ARIA widgets are not programmed properly to begin with, causing accessibility issues for all users, including screen reader users.

However, even assuming that ARIA widgets are programmed properly with full keyboard support so that the ARIA attributes appropriately match the movement of focus, the widgets still won’t work as expected in voice navigation software like Dragon.

Developers can test examples of this issue with any of the ARIA widgets in the Coding Arena included in the archive at, which have been fully verified for both keyboard and screen reader accessibility, and which are specifically programmed according to spec.

The reason why the ARIA widgets don’t work as expected using voice navigation software is because there is no ARIA support built into Dragon. This is because of a deficiency in Dragon NaturallySpeaking, not in any of the correctly programmed ARIA widgets. This means that ARIA Links, Buttons, Checkboxes, Radio Buttons, Menus, Listboxes, Tabs, Sliders and many other controls are not intuitively operable using voice navigation software.

Here is a simple example of this issue, using an ARIA Button:

<a href=”#” role=”button”> Test </a>

The class uses CSS to make this link visually look like a button, and the role=”button” specifies through ARIA that this element should act like a button for assistive technology users, so screen readers like JAWS, NVDA and Voiceover identify this as a button as expected. However, Dragon does not recognize this as a button, only as a link, because the ARIA attribute role=”button” is ignored. Therefore, it is vitally important to ensure that all ARIA widgets and simulated controls are fully accessible from the keyboard. This is the only way to mitigate this deficiency in Dragon.

Mitigating this deficiency makes it possible for voice navigation users to voice standard keyboard commands to interact with controls, such as “press tab,” “press enter,” “press down,” “press space,” and “press escape.” Ensuring full keyboard accessibility also makes it possible for other assistive technologies like Switches for people who are quadriplegic to tie into standard keyboard commands by interacting with virtual keyboards. This is another reason why keyboard support is a critical component of accessibility for all web technologies.

Please note that Dragon 13 now contains support for ARIA. The issues discussed in this post still apply to Dragon Naturally Speaking versions less than 13. For more information on this topic please refer to this Dragon 13 ARIA Support post.