Why a11y?

Accessible Links and Buttons

Why Accessible Links and Buttons Matter

  • Descriptive links and buttons help all users, including those with visual impairments or cognitive disabilities, understand the purpose of an action without relying solely on visual cues.
  • Ensuring focusability makes it easier for users who navigate by keyboard or other input devices to interact with links and buttons.
  • Proper labeling helps assistive technologies, like screen readers, announce the purpose of interactive elements clearly, enhancing the experience for users with disabilities.

Key Requirements for Accessible Links and Buttons

Descriptive Text for Links and Buttons

Links and buttons should always include descriptive text or labels to ensure users know what will happen when interacting with them. Vague labels like "Click Here" or "Submit" should be avoided.

Good Example (Link):

<a href="/download-report" aria-label="Download the 2023 Annual Report">Download Annual Report</a>

The purpose of this link is clear: the user knows they are downloading the 2023 report.

Good Example (Button):

<button type="submit" aria-label="Submit the Contact Form">Submit</button>

The button provides a clear action (submitting a form) with a descriptive aria-label.

Bad Example:

<a href="#">Click here</a>

This lacks context and meaning for users relying on screen readers.

Focusable Links and Buttons

Links and buttons must be focusable and usable via keyboard alone. This means they must appear in the natural focus order of the page and be styled to make focus visible.

Keyboard Navigation: Users must be able to navigate using the Tab key, moving from one focusable element to the next.

  • Links (<a>) and buttons (<button>, or buttons styled with <div>) should be focusable by default.
  • Custom Focusable Elements: When using non-semantic elements (e.g., <div> or <span>) styled to act like buttons, ensure that they are made focusable using the tabindex="0" attribute.
<div role="button" tabindex="0" aria-label="Open Menu">Menu</div>

Visible Focus Indicator

When links and buttons receive focus (through keyboard or other non-mouse navigation), there should be a visible focus indicator to guide the user’s interaction.

a:focus,
button:focus {
	outline: 2px solid #0056b3; /* Custom focus color */
}

This ensures that users can visually track which element is currently focused.

WCAG 2.4.7 - Focus Visible:

Requires that any keyboard-operable interface element must have a visible focus indicator.

Programmatic Labeling Using ARIA

For custom buttons or interactive elements, use ARIA (Accessible Rich Internet Applications) attributes to ensure screen readers understand the purpose and function.

  • aria-label: Add this attribute to provide an accessible name for links or buttons where visible text might not be enough. Example: For an icon-only button (e.g., a "hamburger" menu icon), use aria-label to add context. 
    <button aria-label="Open the navigation menu">
	<svg>...</svg>
</button>
  • aria-labelledby: Use this when you want the button or link to be labeled by another visible element. 
    <span id="login-label">Login</span>
<button aria-labelledby="login-label">Sign In</button>
  • aria-disabled: If a button is disabled, use this to communicate its state to screen readers. 
    <button aria-disabled="true" disabled>Submit</button>

Context for External Links and New Windows

If a link opens a new tab/window or directs users to an external site, this should be communicated to the user. You can do this visually (with an icon) and programmatically (using aria-label or title attributes).

<a href="https://external-site.com" target="_blank" rel="noopener" aria-label="Opens in a new window">
	Visit External Site
</a>

Avoid Non-Descriptive Link Text

Avoid using non-descriptive link text like "Click here" or "Read more" without context. These phrases provide no information about what the user is interacting with, especially for screen readers.

Solution: Add more context to links by making the text descriptive of the destination or function.

  • Bad Example: 
    <a href="#">Read more</a>
  • Good Example: 
    <a href="/about-us">Learn more about our team</a>

Group Buttons with Fieldsets for Better Navigation

For groups of related buttons (e.g., form buttons), it’s helpful to group them within <fieldset> elements for better clarity, especially when screen readers are in use.

Additional Considerations for Accessible Links and Buttons

Avoid Links Styled as Buttons (or vice versa)

  • Links should navigate between pages or external resources, while buttons should trigger actions (e.g., submitting a form, opening a modal). Don’t use one for the role of the other.
  • Keep the intended functionality clear to avoid confusion for users.

Buttons Should Be Usable Without JavaScript

Buttons should always have a fallback function if JavaScript is disabled. If the button is essential to functionality (like submitting a form), make sure it’s operable in all circumstances.

Testing Tools for Accessibility

  • WAVE Accessibility Tool: Provides an in-depth look at link and button accessibility on your site. https://wave.webaim.org
  • Axe DevTools: Identifies accessibility issues, including for buttons and links, within your browser. https://www.deque.com/axe
  • NVDA or JAWS Screen Readers: Test links and buttons with screen readers to ensure proper labeling and focus management.

Related links