Web professionals are increasingly using Macs. As these web professionals become more aware of the importance of web accessibility, more and more of them are using VoiceOver to test for screen reader accessibility. This is excellent news, but there are at least three important differences between VoiceOver and most Windows screen readers that accessibility testers should understand.
The majority of desktop screen reader users are on Windows.
WebAIM regularly conducts surveys of screen reader users. The most recent WebAIM screen reader user survey was conducted in July 2015, with over 2500 respondents. When respondents were asked which screen readers they use on their desktop or laptop, 8% indicated that VoiceOver was their primary screen reader and 31% reported that they commonly use VoiceOver (rounded to the nearest whole number). While VoiceOver is a popular screen reader, you can’t ignore that it is not commonly used by over two-thirds of respondents. Although you can gain a great deal of insight when testing with VoiceOver, relying on it alone may not give you a complete picture of screen reader accessibility.
VoiceOver does not have a forms or application mode.
Windows screen readers have three different interaction modes:
1. Read/Browse mode
In this mode, the arrow keys are used for reading (e.g., the down arrow reads the next item or section, the right arrow reads the next letter). There are also a number of shortcut keys that can be used to jump to common page elements. For example, the H key moves to the next heading.
2. Forms/Focus mode
When navigating into a form control, the screen reader typically uses an audio tone to indicate that it has entered Forms mode. This mode allows the user to interact with form controls using the keyboard. Pressing the H key in forms mode, for example, will type this letter into a text box instead of moving to the next heading. Pressing the down arrow will select the next radio button in a group instead of reading the next item. A different audio tone announces when a screen reader leaves forms mode and returns to Read/Browse mode. Most screen reader users are familiar with this mode.
3. Application mode
This third mode allows screen reader users to interact with complex application widgets. For example, in an accessible tree menu, users can move between sections with the up and down arrow keys and expand or collapse these sections with the right and left arrow keys. In order to make this interaction accessible to these screen reader users, the screen reader needs to enter application mode and pass these keystrokes on to the browser and web application instead of using them for reading. This is functionally the same behavior as Forms/Focus mode, but it is not always presented as clearly to the user. Application mode is often misunderstood and many screen reader users are not aware it exists, but this third mode is at the heart of many accessibility issues.
ARIA, screen reader modes, and VoiceOver
ARIA roles that trigger application mode are often misused by well-meaning developers. For example, if the navigation links at the top of a webpage have incorrectly been assigned an ARIA role="menu" (which is appropriate for application menus, not for navigation menus), this triggers forms mode, and the screen reader user cannot read with the arrow keys. The same thing can occur with other ARIA roles such as tab, dialog, grid, and toolbar.
Alternatively, if a developer creates a widget or control and implements keyboard accessibility, but does not assign the proper ARIA roles, the widget may be accessible to sighted keyboard users, but inaccessible to screen reader users because forms or application mode is not properly triggered.
The mis-use of ARIA and lack of understanding of screen reader modes currently results in significant accessibility issues on the web. The prevalence of these issues is on the rise.
VoiceOver does not have the single-key controls (such as "H" to navigate via headings) that are common in Windows screen readers. To move to the next heading in VoiceOver, you use command + control + option + H. To read the next item in VoiceOver, the user presses control + option + right arrow. Because of these required key combinations, there is no need for VoiceOver to toggle between modes. This is good news for VoiceOver users, who may not experience issues when the above roles are misused. However, this is not ideal for testing because an incorrect ARIA role that can make a webpage highly inaccessible for the majority of screen reader users may go undetected when testing with VoiceOver.
If you would like more information about these three modes, I recommend LÃ©onie Watson’s article on understanding screen reader interaction modes.
ARIA descriptions are read after a very long pause in VoiceOver.
This issue has been resolved in the newest version of the Mac OS—El Capitan. The delay has been shortened to less than a second by default, and the ARIA description is now read at the beginning of the hint instead of the end. While this is still a relevant issue for the many people running older OS versions, it is excellent to see that this issue has been addressed.
There are often times when a text description should be associated to an element (usually a form control). For example, for a password field that presents a message of "Must be 8-16 characters and have letters and numbers", this additional information should be read by a screen reader when the password field is encountered. This can be accomplished with the aria-describedby attribute.
Unfortunately, by default, there is a very long seven second delay after a control is focused before ARIA descriptions are read in VoiceOver. This may cause users and testers to miss this important information. They may incorrectly think the description is not associated even when an ARIA description is implemented correctly. Even more significantly, it has led to a very common, and very incorrect, practice of avoiding aria-describedby completely and using aria-label or aria-labelledby to present labels and descriptions.
This delay can be shortened to less than half a second with VoiceOver settings (and it usually is by VoiceOver power users), but many testers are not aware of this setting. To shorten this delay, open yourand choose , and then drag the slider down on "Speak hints after delay"
VoiceOver is a very powerful screen reader and its usage is on the rise. In order to most effectively use VoiceOver to test web accessibility and to best ensure an accessible experience for all screen reader users, VoiceOver users should understand these differences and consider additional testing in Windows screen readers.
Note: For a more detailed guide on using this screen reader, see our VoiceOver tutorial.