Links: Name, role and states

A link needs to have certain properties programmatically exposed so that users who rely on assistive technologies know what component they’re dealing with.

Programmatically exposing content means assigning certain markup to it so that software or machines can reliably interpret what it is.

To learn about why it’s important to programmatically expose certain information about user interface elements, see the Knowledge Areas:

Accessible name

A link must have a programmatically determinable accessible name. This name is how assistive technologies (AT), like speech recognition or screen reader software, identify and refer to the link. Ideally, the name clearly indicates the link’s target or purpose — for example, ‘Buy now!’ or ‘All about tuatara’.

Meeting the Web Accessibility Standard

When a link has an accessible name, this helps meet WCAG 2:

Interactive components like links can get their accessible names in different ways. Most of the time, a link’s accessible name is derived from its visible text.

To learn how components get their accessible names and how AT present them to users, see the following Knowledge Areas:

Link text should describe link purpose

Ideally, a link’s text — which normally contributes to the link’s accessible name — will describe the link’s target or purpose so that users know upfront what activating the link will do.

Providing clear, descriptive link text also helps screen reader users. Screen reader software allows the user to call up a list of all the links on a page for quicker access. Since, in this view, each link is removed from its surrounding page context, it can be difficult to determine the link's purpose if the link text alone does not make the target of the link clear.

For more information and examples, see:

Note: In some cases, a link’s target or purpose is not clear from the link text alone, but it is clear from the link text along with the link’s surrounding context.

Example of link text that’s not clear on its own

In a list of blog posts, each post is introduced with a heading and a summary paragraph, followed by a "Read more" link. By itself, "Read more" does not clearly indicate the link’s target. But when taken with the heading and paragraph that come before it, the link’s target becomes clear.

In this scenario, it’s important that all users, including AT users, can access the link's surrounding context in order to figure out the link’s purpose. To do this, make sure that the link’s surrounding context can be programmatically determined.

A link’s programmatically determined link context is any information that a browser or AT can reliably determine is associated with the link. This includes information that is:

  • in the same sentence, paragraph, list item, or table cell as the link
  • in the table header cell for the data cell that contains the link
  • in the preceding heading (if the heading’s text makes the link’s purpose clear and distinct from other links under the same heading).

For more on programmatically determined link context and how to use it to clarify a link’s purpose, see:

Meeting the Web Accessibility Standard

When a link’s target or purpose can be determined from the link text alone or from the link text plus the link’s programmatically determined link context, it meets WCAG 2 Success Criterion 2.4.4 Link Purpose (In Context) (Level A).

Accessible name must include any visible text label

If a link has a visible text label (link text), its accessible name must include all of the text in the label, no matter how the accessible name is derived.

To learn more about the difference between an interactive component’s label and name, see “Label” and “Name” as Defined in WCAG — WebAIM.

Typically, a link’s accessible name will be derived from its visible text label, in which case the accessible name will exactly match the label.

However, if a link’s accessible name is derived from some other content, make sure that the accessible name includes all of the text that’s in the link’s visible text label, if it has one.

Example of a visible text label in a hidden accessible name

A link to an application form has the visible link text, ‘Apply now’, but a visually hidden accessible name of ‘PDF form’ programmatically assigned via the aria-label attribute.

In this case, a speech recognition user might be saying the link's visible text label, “Apply now”, to activate the link, but nothing happens because the link’s accessible name is actually ‘PDF form’.

To solve this, ensure that the link’s accessible name includes any text that’s visually presented in the link — for example, aria-label="Apply now (PDF form)".

Meeting the Web Accessibility Standard

When a link’s accessible name includes all of the text that’s in the link’s visible text label, this meets WCAG 2 Success Criterion 2.5.3 Label in Name (Level A).

Role

A link needs to have a role of link, so that users who rely on assistive technologies can know what type of user interface component it is. This lets them know what to expect and how to interact with it.

Meeting the Web Accessibility Standard

When a link has a role of link, this helps meet WCAG 2:

If you create a link using native HTML methods, such as <a href> or <area href>, the browser already assigns it a role of link.

If you create a custom link out of other elements, the link role needs to be added explicitly.

This requires using ARIA to give the element a role attribute with a value of link.

Example of a role attribute with a value of link

<span role="link">

States

All interactive elements, like links, have different states.

A link can have the following basic states:

Meeting the Web Accessibility Standard

When a link’s state is visually indicated and also programmatically exposed, this helps meet WCAG 2 Success Criterion 1.3.1 Info and Relationships (Level A).

When a link’s different states are programmatically exposed, this helps meet WCAG 2 Success Criterion 4.1.2 Name, Role, Value (Level A).

Programmatic presentation of states

States need to be programmatically exposed so that users of assistive technologies know, for example, if the link has focus.

States exposed by the browser

A link’s basic states are automatically registered and exposed programmatically by the browser, so no further work is needed.

Custom states

If a link is used in some custom widget, it might have other states that the developer will need to ensure are being programmatically exposed for assistive technologies. What those states are will depend on the function of the link.

Visual presentation of states

To help sighted users, a link’s states can be styled visually using the related CSS pseudo-classes:

For more on styling the different link states, see:

Focus state

A link’s focus states needs an obvious visual style so that sighted keyboard users know that the link has focus and is ready to be interacted with.

For more, see Visible focus indicators — Knowledge Area: Keyboard accessibility.

Limitations to :visited styles

There are some restrictions to how much one can visually style visited links using the :visited pseudo-class. For more information, see: