Text Links: Best Practices for Screen Readers

Share on FacebookShare on LinkedInShare on Twitter

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

  1. Different title and anchor text:
    Annual Report 2013
    Markup: <a href="#" title="Download PDF">Annual Report 2013</a>
  2. Identical title and anchor text:
    Annual Report 2013
    Markup: <a href="#" title="Annual Report 2013">Annual Report 2013</a>
  3. Aria-label present besides anchor text:
    Annual Report 2013
    Markup: <a href="#" aria-label="Download PDF">Annual Report 2013</a>
  4. 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

Screen Reader Output
LinkJAWS 15NVDA 2013.3VO on OSX LionVO on iOS (iPad)
A. Different title and anchor text:Anchor text + titleAnchor text + titleAnchor textAnchor text + title
B. Identical title and anchor text:Only anchor textAnchor text + titleAnchor textAnchor text + title
C. Aria- label present besides anchor text:Aria-labelAnchor textAnchor text + aria-labelAria-label
D. Both Aria-label and title present besides anchor text:Aria-label + titleAnchor text + titleAnchor text + aria-labelAria-label + title


  • 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.


  • 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.


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