Anchor link accessibility considerations

Machine readable accessibility guidelines

Of late, I have been experimenting with housing accessiblity guidelines in YAML files, as part of a design system GitHub repository.

For each component, I have include a list of accessibility considerations, so that humans and robots can consume the guidance.

With a single source of truth, this makes the information easy to find, ensures re-usability, and alignment across teams.

This process made me look again at the different accessibility considerations relating to links.

Link accessibility consideration summary

1. Link text should be meaningful

   Avoid vague labels like click here or read more where possible. Good link text helps people understand where they are going before they activate the link.

   People can skim links and miss the context.

   Users with screen magnification can be more likely to miss context.

   Assistive technologies can list out available links and 20 'click here' links don't offer many clues.

   This supports WCAG 2.4.4: Link Purpose (In Context).

2. Links should make sense in context

   A link such as View details can be acceptable when its purpose is clear from the surrounding programmatic context, such as the same sentence, paragraph, list item, table cell with associated headers, or a preceding heading.

   This matters because people using assistive technologies may navigate links separately from the visual layout. The relationship between the link and its context needs to be available in the HTML, not only implied by visual grouping.

3. Links should ideally make sense out of context

   Screen reader users can navigate a page by listing all links. In that experience, repeated links like Learn more or Read more can become difficult to understand.

   Where possible, use link text that describes the destination on its own, such as Read the accessibility guidance.

   This relates to WCAG 2.4.9: Link Purpose (Link Only).

4. Inline links need clear visual affordance

   Links within body copy should be visually distinguishable from surrounding text. Colour alone should not be the only indicator that text is interactive.

   Underlines, or another clear non-colour indicator, help people with low vision, colour blindness or cognitive load recognise links more easily.

   This supports WCAG 1.4.1: Use of Color.

5. Focus must be visible

   Keyboard users need to see which link currently has focus. A visible focus state should be deliberately designed and should not be removed.

   This supports WCAG 2.4.7: Focus Visible.

6. Focus contrast matters

   It is not enough for focus to technically exist. People need to be able to perceive it. Focus indicators should have enough contrast against adjacent colours, including across different themes and backgrounds.

   This supports WCAG 2.4.13: Focus Appearance and WCAG 1.4.11: Non-text Contrast.

7. Links and buttons are semantically different

   A link navigates to another destination. A button performs an action.

   Using the correct HTML element helps browsers and assistive technologies communicate the right role, behaviour and expectation to users.

   Use an <a href=""> element for navigation, and a <button> element for actions such as submitting, saving, deleting or opening a modal.

8. Target size for standalone links

   Target size of standalone links, out of context need to be easily clickable, in line with best practise touch target sizes or WCAG guidelines.

Final thoughts on links

Using the right semantic element helps assistive technology communicate the correct expectation to users. It also supports predictable keyboard behaviour.

For me, the lesson is that a link component is not just styled text.

It needs decisions around language, context, semantics, colour, focus, states and usage.

Example of machine readable link guidelines

For an example of machine readable link guidelines, you can view my link YAML file on my accessible design system GitHub (work in progress).