Skip to Main Content
Toggle
(800) 889-9659
info@levelaccess.com

Methods of Indicating the Purpose of a Link

Jonathan Avila 02/11/12

Overview

The different methods of indicating a link’s purpose are often misunderstood and incorrectly implemented. The Web Content Accessibility Guidelines (WCAG) explicitly require that link text accurately reflects the target and purpose of the link. While current Section 508 standards do not explicitly state this — many Federal Agencies in the US require similar practices under Section 1194.31 Functional Performance Criteria. The harmonization of Section 508 as indicated in the US Access Board’s last Advanced Notice of Proposed Rulemaking (ANRPM) also indicates that link purpose will be explicitly required when Section 508 is refreshed.

A number of techniques exist that can be used by developers to meet the WCAG success criteria. There are two particular WCAG success criteria (SC) that relate to indicating the purpose of link. Under WCAG SC 2.4.4 (Level A) conformance can be met by changing the link’s text, or programmatic elements/attributes associated with the link or by supplying text content in relative context to the link such as in the same sentence, paragraph, list item, heading, etc. Under WCAG SC 2.4.9 (Level AAA) the links purpose must be discernable through a mechanism other than relying on the relative context of the link. The latter is consistent with WCAG 1 priority 2.

There are many uses for links in web content, links that take the user to other pages, links that provide further details, links that are or include images, links that are part of table header cells, links that are used as UI elements such as page tabs, links that open new windows or go to external sites, etc. The method used to provide purpose is related to the type of link. This post aims to help categorize the different types or links, methods, and implementation techniques required to conform to the relevant standards and meet the needs of varying groups of users with disabilities. A clearly indicated link purpose assists users who are blind or visually impaired along with users that have cognitive disabilities. For example, many users who are blind navigate to links in such a way that pulls the link text out of context from the surrounding page content and displays it in a list. Other methods of navigating with a screen reader such as tabbing around the page also cause the user to encounter the link and only be aware of the current link’s text.

Implementation

One of the easiest ways to clarify a links purpose is to directly change the on-screen text of the link. For example, a link that indicates “click here” after a sentence about a museum’s tour schedule could be changed to “Museum tour schedule”. This approach works well for some links although too verbose of links may not be helpful to other users with disabilities or may not fit into the site layout.

In regards to WCAG Level A and AA conformance, if the text of the link can not be changed, developers must ensure that the content surrounding the link aids in identifying the links purpose. Per WCAG 2, Link Purpose (In Context): Understanding SC 2.4.4 indicates acceptable methods of providing purpose via link context include indicating the purpose in the same:

  1. Sentence, paragraph, or list item or
  2. Heading immediately preceding the link or
  3. Table cell as the link or
  4. In the table header cell for a link in a data table

There are however, a number of reasons to provide the link purpose directly in the link so it may be understood out of context For example, it may not be possible to provide context depending on the placement and purpose of the link, developers may want to provide enhanced functionality to users with disabilities, meet WCAG 2 Level AAA requirements (see Link Purpose (Link Only): Understanding SC 2.4.9, or meet the implementation requirements of specific US Federal Agencies that require the link’s purpose be understood within context (VHA Section 508 Functional Checklist). In these cases the techniques described below should be used.

The title attribute can be used to supplement the link text or off-screen text using CSS can be positioned within the link. The ARIA aria-describedby attribute can also be used in situations where ARIA is supported by the assistive technology and user agents in the technology stack. ARIA is also a good choice where a link represents a user interface element such as a page tab. Appropriate aria roles such as role="tab" and role="tablist" along with states such as aria-selected can be used rather than using CSS off-screen text or the title attribute to indicate the purpose and active state of the page tab link. Finally, an image can also be inserted inside the link with appropriate alt text indicating the context (e.g. using a PDF icon to differentiate a PDF link from an HTML link). This approach works well for links that direct users to other sites or open new windows. In these cases an icon image with appropriate alttext should be used to indicate the actions.

The Title attribute

The title attribute is not announced by default by many major screen readers, JAWS, Window-Eyes, or NVDA. The JAWS screen reader can be configured to speak the title attribute for links and a keystroke is available (insert+tab) to announce the title attribute. In Window-Eyes, the insert+e keystroke will announce title attribute information by bringing up a dialog. With NVDA, the title attribute can be announced by pressing the insert+tab keystroke. The presence of the title attribute is not indicated to the user automatically. For users who are not using a screen reader, the title is also displayed when the mouse is moved over a link, however, this feature is not keyboard accessible in nearly all user agents. This is one reason why only supplementary information can be provided via this method.

CSS based Off-screen Text

Text that is position off-screen using CSS can be a good solution for screen readers, however, this text is not accessible to anyone who has CSS turned on and is not using a screen reader. For this reason it is recommended that this method only be used with this supplementary information is only needed by users of screen readers or where it is duplicated using other method such as the title attribute. Typically this method works by creating a CSS style such as hide and then applying it to a span element within the anchor that contains the text to hide. The CSS positioning is usually set to absolute with overflow turned off, the left edge set to a negative number and the width restricted.

Other considerations

Only supplementary information should be placed in title attributes or CSS off-screen text and never content that is required to name the link. For example, if a link contains no text and only and image, the alt attribute of the image must be used to provide the textual name of the image link. This technique would then require use of inline images rather than CSS background images as CSS background images can not have altattributes.

Developers should be aware that overly verbose supplemental information can be distracting for users of assistive technologies such as screen readers. For example, when sortable links are used in table header cells and contain off-screen CSS text providing instructions about the sorting. In the case of screen readers this text and instructions will be announced each time as the user navigates from data cell to data cell along with the header cell content. In cases such as this it may be useful to use the abbr attribute to provide a more concise abbreviation of the table header cell that does not contain the instruction text but does indicate the current sort direction. The JAWS screen reader automatically supports this attribute, it is a setting in the Winodw-Eyes screen reader and it does not appear to be supported by NVDA. The abbr attribute for table header cells is not defined in HTML 5 – thus for HTML 5 based content other approaches may be necessary.

Frameworks for Categorization

In order to determine the correct solution for providing link text, developers must consider the following factors:

  • The purpose must be understood visually
    • If the visual purpose is not always on-screen it must be displayable regardless of input method (keyboard, mouse, etc.)
    • Color must not be the sole means to indicate the link purpose
  • The purpose must be understood without vision
    • It must be supported by assistive technology

Link Scenarios

The following table outlines different link use scenarios with recommended methods of implementation.

Type of link Recommendation Comments
Link with no text and only image Assign appropriate alt text to the image Meets all standards except when text of images are used
Link with image where alt text of image would completely duplicate the link text Assign a null alt="" attribute to the image inside the anchor Assume the link text describes the purpose of the link.
Link with text where an image could be used

  • Links to different file formats such as PDF, HTML, Word, etc.
  • Links that take the user to different sites
  • Links that open new windows or frames
Alt text to an existing image or add an image inside the anchor with appropriate alt text clarifying the purpose of the link.

Note inline images must be used as alt text can not be assigned to CSS background images.

For WCAG Level A and AA compliance this is only required if the format is not programmatically discernable (such as via the href attribute) or within the surrounding context.

Additionally WCAG Level A and AA do not require notification of new windows when opened on user request.

Text link where an image will not be used Add on-screen text to clarify the purpose of the link For WCAG Level A and AA compliance this is only required if the purpose cannot be determined within the surrounding context.
Add CSS based off-screen text to a span element within the link (best if combined with the technique below) This text is only available to users of screen readers when CSS is turned on.

For WCAG Level A and AA compliance this is only required if the purpose cannot be determined within the surrounding context.

This technique alone can not be used to meet WCAG Level AAA as the text is not visible with CSS turned on.

Add a title attribute to the link (best if combined with the technique above) This text is only available via mouse over or when a keystroke is pressed by the user of a screen reader. The JAWS screen reader does have an configuration setting to atomically announce the title.

For WCAG Level A and AA compliance this is only required if the purpose cannot be determined within the surrounding context.

This technique alone cannot be used to meet WCAG Level AAA as it is not keyboard accessible.

 

Use the aria-describedby attribute to provide supplement the text of the link with other page content that purposefully describes the link. ARIA is not support by all screen readers and user agents including the Window-Eyes screen reader.

For WCAG Level A and AA compliance this is only required if the purpose cannot be determined within the surrounding context.

This technique alone cannot be used to meet WCAG Level AAA as it does not provide the text directly within the link.

Links that represent sortable table headers (may or may not use images) Indicate sorting information via alt text on an image. If alt text is not possible, use CSS off-screen text to indicate sorting information. Additionally, use the abbr attribute to provide a shorted abbreviation that will be announced to the user as the column header as data cells are traversed with the screen reader. The abbr attribute is not supported in HTML 5. Consider using ARIA.
Links that represent UI elements such as page tabs Use a visual indicator in addition to color to indicate the active state and use a programmatic method such as CSS off-screen text or ARIA to indicate the state and role of the UI element. Visual indication should be available regardless of input method used (i.e should always be present or be available whether the user is using the keyboard or mouse).

ARIA should only be relied upon when it is known that the ARIA is assistive technology supported by the technology stack.

Conclusion

While there is no specific method to clearly indicate a links purpose for all link types and situations, there is a framework in place to assist developers in creating informed decisions that meet the needs of users with disabilities, are supported by assistive technology, fit within the site’s design, and increase search engine optimization.

Additional WCAG Resources

2 Comments

  1. If you place a null alt attribute on the image inside an anchor, won’t most screen readers attempt to render the filename of the image? I’m not sure there’s a good solution for duplicate links where text and image links exist both pointing to the same destination.

  2. Sam, in this case the recommendation to use alt=”” is only for links that contain sufficient text within the anchor element. In these cases the image would be duplicative of the link text. When an anchor contains text and an image with alt=”” most screen readers do not announce the source of the image. The source would generally only be announced in the case where the image is used within a link with no text.

Comments are closed.