Sometimes, the visible anchor text as mandated by the user interface design is not very meaningful to vision impaired users. One could use aria-label or the title attribute or even off-screen text on text links. But what’s the best practice based on current assistive technology support?
Comparing Screen Reader Behavior for Aria-label and Title on Text Links
Links used for this test
- Different title and anchor text: Annual Report 2013 Markup: <a href=”#” title=”Download PDF”>Annual Report 2013</a>
- Identical title and anchor text: Annual Report 2013 Markup: <a href=”#” title=”Annual Report 2013″>Annual Report 2013</a>
- Aria-label present besides anchor text: Annual Report 2013 Markup: <a href=”#” aria-label=”Download PDF”>Annual Report 2013</a>
- Both Aria-label and title present besides anchor text: Annual Report 2013 Markup: <a href=”#” aria-label=”Download PDF” title=”2013- Annual Report”>Annual Report 2013</a>
The Comparison
| Link | JAWS 15 | NVDA 2013.3 | VO on OSX Lion | VO on iOS (iPad) |
|---|---|---|---|---|
| A. Different title and anchor text: | Anchor text + title | Anchor text + title | Anchor text | Anchor text + title |
| B. Identical title and anchor text: | Only anchor text | Anchor text + title | Anchor text | Anchor text + title |
| C. Aria- label present besides anchor text: | Aria-label | Anchor text | Anchor text + aria-label | Aria-label |
| D. Both Aria-label and title present besides anchor text: | Aria-label + title | Anchor text + title | Anchor text + aria-label | Aria-label + title |
Notes:
- For JAWS, the above behavior is the same in Firefox and Internet Explorer (Windows 7).
- NVDA was tested only with Firefox
- VoiceOver was used with Safari on OSX and iOS
- Default verbosity settings were used for all screen readers. The test links are not indicative of markup to be used for download links for PDF (or other) file types.
Conclusion:
- JAWS 15 provides the best user experience followed by VoiceOver on iOS
- The title attribute is read by VoiceOver on OSX when the user explicitly checks for presence of help text on the element (VO+Shift+h). This is akin to interrogating a link for presence of a title attribute with JAWS (or Window-Eyes)
- NVDA developers are working on providing a better experience when a link contains aria-label as per the thread Regarding the accessible name calculation for aria-label within links?, which in part, motivated this article.
Both aria-label and the title are listed in the text alternative computation algorithm with the title having the lowest preference. The aria-label gains preference even over the anchor text in determining the accessible name for a link. In situations where text that is different from the anchor text needs to be rendered to aid vision impaired users, the aria-label is the better choice. When the link’s name (i.e. anchor text or aria-label) needs to be supplemented with advisory text, the title is more suitable. This will reduce the dependence on the CSS off-screen text method for providing such supplemental text to aid non-sighted users. It may be noted that neither aria-label or title is available to keyboard-only users; but the title is exposed as a tooltip when one mouses over the element.
Update:
Results with NVDA 2014 are better now. So the outcome in situations B, C and D above are different:
- NVDA ignores title if it is identical to anchor text
- NVDA reads aria-label and ignores anchor text
Update 2020:
Since the last update to the article in December 2015, there have been some changes to browser acceptance and usage by screen reader users:
- Chrome is used more extensively now in addition to Firefox
- Support for Microsoft Edge has improved significantly leading to an uptick in usage
- Mobile platform: Chrome with TalkBack on an Android device is the next preferred alternative after VoiceOver and Safari on an iOS device
Reference: WebAIM: Screen Reader User Survey #8(2019)
Therefore as the new year rolled in, the following screen readers and browsers were re-tested for this update. The examples used here are the same as thos used in the original write-up over five years ago.
Browsers on Windows 10 laptop
- Chrome 79 and Chrome 78
- Firefox 71 and Firefox 68.3.0 ESR
- Internet Explorer 11
- Microsoft Edge
Mobile Testing:
- VoiceOver and Safari on an iPhone 11 with iOS 13.3
- TalkBack 8.1 with Chrome on a Pixel with Android 10
Results
Screen readers consistently and correctly expose aria-label overriding the anchor text on the Windows 10 platform as well as on mobile devices- iOS and Android. This demonstrates good support for the WCAG technique, ARIA8 – Using aria-label for link purpose, which depends on the aria-label text overriding the anchor text.
Results with JAWS 2020 / JAWS 2019
- JAWS behaves identically across Chrome, Firefox and Internet Explorer with the identical title in Case B being ignored.
- The only failure noted is with Microsoft Edge: JAWS simply fails to read the title attribute for all the four links.
Results with NVDA
- With Internet Explorer, NVDA does not expose the title attribute for any of the links.
- NVDA reads the identical title text (Case B) when using Chrome or Edge. The user experience with Firefox is better as previously updated in 2015
Results on Mobile Devices
- No change in VoiceOver behavior.
- TalkBack repeats the identical title text with Chrome on the Pixel with Android 10
All in all, the only aberrations that need to be resolved are for exposing the title attribute when using Edge and IE 11 with JAWS and NVDA respectively. That a change for the better will happen for IE 11 and NVDA combination is quite unlikely.