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 your and choose , and then drag the slider down on "Speak hints after delay"
Conclusion
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.
This is good information. I would add a couple more points:
1. In order to test keyboard accessibility (with or without the screen reader) you have to first turn on keyboard accessibility in the operating system (system preferences > keyboard > shortcuts > all controls) and in Safari (Safari > Preferences > Advanced > Accessibility > Press tab to highlight each item on a webpage)
2. I think Apple eliminated the long delay in recent OSX updates. I don’t know which update did it, but everyone I’ve asked in the last 6 months or so who has never changed the VoiceOver settings tells me that the slider is set to no delay. So my understanding is that the delay is no longer a problem unless the person hasn’t updated the OS in a while.
Hello and thank you for this very interesting article.
In this article you write: “VoiceOver does not have the single-key controls (such as “H” to navigate via headings) that are common in Windows screen readers.”
It is possible to use single-keys like h for headings in VoiceOver. In the VoiceOver utility, go to commandor, select quick nav mode. See article on how to use quick nav mode.
Best
Sylvie
I just checked the settings for “Speak hints after delay”, the default is “short” on OSX El Capitan.
Thank you Paul for your excellent feedback, and to Gijs for verifying. I will update my post with additional details. A couple things:
1. I chose not to include the “All controls” setting because this setting is automatically toggled when you start VoiceOver. However, I completely overlooked the Safari setting. We recommend changing these two settings as part of keyboard testing anyway. I’ll update the post soon to reflect this (or better yet, our main VoiceOver and keyboard articles).
2. Thanks for pointing out that support of aria-describedby changed in El Capitan. The long delay for hints is gone, and the description is now read at the beginning of the hint instead of the end! This is a huge improvement and I will update the post with this additional information.
Hello,
I found out the differences you describe here when I compared accessibility testing results using VoiceOver on IOS to JAWS/NVDA on PC with a site that constantly threw the PC screen reader into application mode, but generally had litle or no difficulties on my mobile device.
I find this paragraph confusing …
“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.”
1. There is no intrinsic difference between using a menu to present navigation functions and using a menu to present application functions.
2. A correctly implemented menu does not reduce readability with any screen reader on either Windows or Mac.
While simply adding menu/menuitem roles on a static list of navigation links is an error, it does not follow that implementing menu widgets for navigation is not appropriate. There are lots of sites where the interaction model of the navigation matches the ARIA menu pattern and such sites are more accessible when the pattern is used correctly. Even better is when they degrade gracefully.
As far as I know, JAWS is the only screen reader that distinguishes between its “forms” and “application” modes. NVDA and Window-Eyes, at least, do not have a third mode.
I wish freedom Scientific would have never introduced the idea of a third mode. Life was already confusing enough with 2 modes.
Fortunately, in version 1.1, I think we have finally perged the specification of any language that may have inspired the third mode. I rewrote the application role and carefully scrubbed the spec for all other places where the word “application” was used in a confusing way. The APG is undergoing similar treatment.
Thank you Paul Bohman! I was going mad trying to figure out why Chrome and Firefox on the Mac were skipping over most links including Skip Navigation. I didn’t know I had to turn on All Controls in keyboard settings till I found this.