Text Links: Best Practices for Screen Readers

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