Accessibility Testing with Voice Recognition Software
Posted by Steve Green on 09 February 2013.
We have recently conducted an expert review with voice recognition software (Dragon NaturallySpeaking v10) and found some issues that may be of interest to developers and testers. We have not yet investigated the cause of some of these issues, so we will post more information when we do so.
In most cases there are workarounds, such as using mousegrid or saying "link" so that Dragon puts numbered tags next to all the links. However, these workarounds are a relatively poor user experience.
Unfortunately this is a client's website so we are unable to share the URL.
- In order to be able to give focus to a form control by speaking its text label, it is necessary to do either of the following:
- Put the text label in a <label> element with a 'for' attribute that matches the 'id' attribute of the form control. Obviously this should always be done for WCAG-compliance, but if it isn't the following technique works.
- Make the text label the same as the 'name' attribute of the form control, or a subset of it.
- If a form control does not have a text label, the only way to give it focus (apart from tabbing or mousegrid) is to say the 'name' attribute. Of course users don't know what the 'name' attribute will be, so it is best to make the 'name' attribute match the form control's default text if possible.
- If you put the focus in a textbox then say a word that appears in a link that is in view on that page, the link is operated instead of the word being typed in the textbox. That is bad enough, but...
- If you put the focus in a textbox then say a word that appears in a link that is out of view on that page, nothing happens at all!!! The link is not operated and the words you spoke do not appear in the textbox. Weird!!!
- The website contains a form with about 40 checkboxes, but only the first 16 can be selected using voice commands. I have no idea why.
Quite a few commonly-used words trigger the browser's menus rather than the links in the website. For example:
- Close. It is not a good idea to use the word Close as the link for closing a lightbox, because it is also the command for closing the browser. And guess which one takes precedence. This causes a dilemma because Close is so widely used and we can't think of an alternative that wouldn't be confusing e.g. Exit.
- View and Edit. The website we were testing contains View and Edit links, neither of which work because the browser menus trigger instead.
- Print. Many pages contain a Print button that is supposed to launch the Print dialog (it does if you click it). However, the word 'print' is also the command for the browser's Print button, which prints immediately and does not launch the Print dialog. And again this takes precedence. In most cases this probably won't matter, but it will if someone doesn't want to print to the default printer or wants to change other print settings.
[Comment added in 2016: Dragon didn't integrate with the DOM at all until version 12, meaning that it could not interact with dynamic content before then. Support is still not good even in version 13].
Dragon does not appear to recognise words that are not in its dictionary. An example is Prev, which is commonly used as a pagination link - if you say "prev", nothing happens. Therefore we recommend that full words are used instead of abbreviations.
Links with identical anchor text
If pages contain two links that have identical anchor text but point to different URLs, neither link works when you are on either of those pages. This means you cannot navigate directly from one to the other. This is likely to be rare, and is bad practice, but it does happen on the site I am testing.