Link vs Button: Choosing the Right Element for the Right Job

November 10, 2025Technical

When it comes to building accessible and user-friendly interfaces, one of the most overlooked distinctions in web development is between links and buttons. They may look similar visually and even behave similarly when styled with CSS or enhanced with JavaScript, but their semantics and purposes are fundamentally different, and these differences matter greatly for accessibility.

Understanding the Difference

While the Web Content Accessibility Guidelines (WCAG) do not explicitly prohibit misusing link or button semantics if functionality and accessibility outcomes are preserved, best practice — supported by W3C and Authoring Practices — is to use the correct semantic element for each purpose. Semantics convey meaning — not just to developers, but also to assistive technologies like screen readers.

Here are the main distinguishing factors between the two:

  • Links (<a> elements) take users to different locations — either to another page or a different section of the same page.

    Example: Navigating to a “Contact Us” page or jumping to a specific heading on the current page.

  • Buttons (<button> elements) activate an action or functionality, typically on the same page.

    Example: Expanding a hidden menu, submitting a form, toggling a theme, or opening a modal dialog.

While there are gray areas, such as a control that loads new content dynamically without a full page reload, the distinction usually comes down to navigation vs. action.

Why the Difference Matters for Screen Reader Users

Screen readers inform users whether something is a link or a button. When a screen reader encounters these elements, it announces their role — saying “link” or “button” before the accessible name.

For example:

  • A screen reader might announce “Link, Home.”
  • Or “Button, Submit Form.”

This helps users understand what to expect when they interact with the element. However, when developers blur the lines — such as making a link act like a button with JavaScript — it can lead to serious confusion.

Imagine a user looking for a specific link in the “List of Links” feature available in most screen readers. If that “link” was coded as a <button> instead, it won’t appear in the list at all, leaving the user unable to find it. Likewise, if a button is incorrectly coded as a link, it may appear in the wrong context.

This kind of semantic mismatch can frustrate screen reader users and create unnecessary accessibility barriers.

Designing Accessible Links

A well-designed link is both descriptive and distinctive. Let’s look at what that means in practice.

How to Define a Link

Use the <a> element (or role="link" with other elements) for navigation between different pages or sections. It must include an href attribute. Without the href attribute, an <a> element is not keyboard-focusable or recognized as a link by assistive technologies.”

Example:

<a href="/about">About Us</a>

Make Links Descriptive and Contextually Clear

Clear and descriptive link text is one of the most important aspects of creating an accessible and user-friendly experience. A link should give users enough information to understand where it leads or what action it performs.

Where possible, provide a more descriptive visible link phrase for all users. Alternatively, you can use the following techniques to make them descriptive for screen reader users.

Wrapping the link with the surrounding text

Wrap the link and surrounding contextual information within a same sentence, paragraph, list item, table cell, or associated table headers that gives meaning to the link in context.

Example: Adding Context Using a Paragraph

<p>Our new accessibility testing tool integrates seamlessly with CI/CD pipelines. <a href="/blog/new-accessibility-tool">Read more</a> about the new tool.</p>

In this approach, if a screen reader user navigates by links alone, they will still understand what the “Read more” link refers to.

Using Visually Hidden Text

When the visual design limits space, you can add hidden text to make link text more specific without affecting the visible layout.

Example: “Learn More” Link with Hidden Context

<a href="/services/web-accessibility"> Learn more<span class="visually-hidden"> about our web accessibility services</span></a>.
<----- CSS Starts ------>
.visually-hidden {
clip-path: inset (50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;
}
<----- CSS Ends ------>

In this example, sighted users see “Learn more,” while screen reader users hear “Learn more about our web accessibility services.”

Using aria-label to override native link text

If adding visually hidden text isn’t possible, the aria-label attribute can also be used to add context.

Example:

<a href="/services/web-accessibility" aria-label="Learn more about our web accessibility services">Learn more</a>.

Note: The visible link phrase (in the example above “Learn more”) must be present in the aria-label, otherwise this would fail SC 2.5.3 Label in Name. For more information, please refer to How to meet SC 2.5.3 Label in Name.

Accessible Image Links

When an image is the only content inside a link, the alternative text (such as an alt attribute for an <img> element) becomes the accessible name of that link. It should clearly communicate the link’s purpose or destination.

Example:

<a href="https://www.tpgi.com/"><img src="tpgi-logo.png" alt="TPGi home page"></a>

Here, the alt text “TPGi home page” describes the target of the link.

Note: If the logo itself contains text, such as “TPGi,” the alt text should include it to satisfy SC 2.5.3 Label in Name.

Using aria-describedby for supplementary descriptions

In some cases, you may want to provide additional descriptive context for a link, for example, to clarify the destination or potential actions when multiple links are present with the same accessible name. You can use aria-describedby to associate the link with descriptive text elsewhere on the page.

Example:

<p id="policy-desc">This document explains our approach to protecting your personal data.</p>
<p><a href="/privacy-policy" aria-describedby="policy-desc">View Privacy Policy</a><p>

In this example, screen reader users will hear:

“View Privacy Policy — This document explains our approach to protecting your personal data.”

Using the title attribute (as a last resort)

The title attribute can be used to provide extra information about a link. However, it should be treated as a last resort because:

Example:

<a href="/team" title="Meet the TPGi accessibility team">Our Team</a>

Note: Some screen readers may not consistently announce the title attribute. In addition, many users, especially those using touch devices or voice access tools, cannot access title tooltips, making this method unreliable for conveying essential information.

Indicating New Windows or Tabs

If a link opens in a new tab or window, this must be indicated, both visually and programmatically.

Example:

<a href="https://example.com" target="_blank" rel="noopener">Visit Example.com (opens in a new tab)</a>

Users of assistive technologies must not be surprised by a change in context. Announcing it clearly avoids confusion and maintains a sense of control.

Visual Distinction

Links should be visually distinguishable from surrounding text — typically by color and/or underline. Relying only on color differences can pose challenges for users with color vision deficiencies, so consider underlines or other visual cues.

Designing Accessible Buttons

Buttons are about actions, not destinations. They trigger behavior on the same page, such as submitting data, opening menus, or changing states.

How to Define a Button

Use the <button> element (or role="button" with all the other elements) for any control that performs an action.

Note: ARIA should not be used to repurpose native elements when native semantics suffice. For example, role="button" on a <div> is acceptable only if no suitable HTML element can serve the purpose.

<button type="submit">Submit Form</button>

Note: Avoid using <div> or <span> with click handlers to mimic button behavior, doing so removes the inherent keyboard accessibility and role information that come built into <button>, unless absolutely necessary and fully ARIA-enabled.

Descriptive Button Labels

The button’s accessible name should clearly describe its action. Avoid generic terms like “Go” or “OK” when the context isn’t obvious.

Similar to links, buttons can also use aria-label, aria-describedby, title, or an inner image element with proper alt text to convey descriptive meaning.

Example: Button with aria-label

<button type="button" aria-label="Search the website">
  <svg aria-hidden="true" viewBox="0 0 24 24">
  <path d="..." />
  </svg>
</button>

Here, the icon alone wouldn’t communicate meaning to screen reader users, so the aria-label provides an accessible name (“Search the website”).

Example: Button with aria-describedby

<p id="save-desc">Saves your draft progress without submitting.</p>
  <button type="button" aria-describedby="save-desc">Save Draft</button>

This technique is helpful when additional context is needed, for example, to clarify what the button does.

Example: Button with title (use sparingly)

<button type="button" title="Download report as PDF">Download</button>

Note: The title attribute should be used only as supplementary information. It is not consistently announced by all screen readers and may not be accessible on touch devices.

Example: Button with an inner image element

<button type="button">
  <img src="download-icon.png" alt="Download report">
</button>

If an image represents the button’s purpose, its alt text must clearly describe the action (e.g., “Download report”).

Why It’s a Best Practice, Not a WCAG Failure

Misusing a link or a button is not directly a WCAG failure, but it’s considered a best practice issue that significantly affects usability and consistency.

Here’s why:

  • WCAG focuses on accessibility outcomes, such as ensuring that elements are operable, perceivable, understandable and robustness.
    A link coded as a button might still be technically accessible if it can be operated by keyboard and announced properly by assistive technologies.
  • However, using incorrect semantics can confuse users and break expected navigation patterns. For instance:
    • Screen reader users expect links to appear in the “links list” and buttons to appear in the “buttons list.”
    • Keyboard users expect links to be activated with the Enter key and buttons with the Spacebar or Enter keys.

When these expectations are broken, even if the control remains technically functional, it reduces the predictability and usability of the interface.

Thus, it’s considered an accessibility best practice, not a violation.

Correct semantics improve the user experience, enhance clarity for assistive technologies, and align with the principles of SC 3.2.4 (Consistent Identification) and SC 4.1.2 (Name, Role, Value), which emphasize predictable and consistent interactions.

The built-in keyboard operability of semantic <button> and <a> elements also ensures conformance with SC 2.1.1 Keyboard. By distinguishing links from buttons correctly, you help users navigate confidently and build more inclusive experiences.

Following this best practice makes your content more robust, consistent, and user-centered, which are all foundational pillars of accessibility.

Resources

Categories: Technical

Comments

Add Your Comment