Links vs. Buttons: The Good, the Bad and the Ugly

Links and buttons are fundamental elements that make the internet work, providing users with the ability to navigate between pages and interact with content dynamically. Links connect web pages across the internet, forming the vast web of information that makes the internet useful. Buttons, on the other hand, enable interaction within a page, allowing users to submit forms, toggle content, and engage with web applications without leaving the current page. Proper use of these elements ensures a seamless, functional, and accessible experience for all users.

Understanding the difference between links and buttons on a website is crucial for both usability and accessibility. While they may sometimes look similar, their functions, coding, and best practices differ significantly. Using the correct element improves user experience, accessibility, and search engine optimisation (SEO).

Links: Navigation Between Pages

When to Use Links

A link is designed for navigation, meaning it should be used when directing users to another page, section, or resource. Examples include:

• Navigating to another page within the site
• Linking to an external website
• Moving users to a different section within the same page (anchor links)
• Initiating a file download (though caution is required for accessibility)

How Links Are Displayed

By default, links are underlined and typically appear blue. However, CSS can style them differently while still maintaining clear affordance as clickable elements.

• Default Styles: Blue text with an underline
• Hover State: Changes colour or adds an underline
• Visited State: Slightly different colour to indicate prior interaction
• Focus State: Should have a visible outline for accessibility

Coding Differences

A basic link is structured as:

<a href="https://example.com">Visit Example</a>

• The href attribute is required to define the destination.
• Links should be keyboard accessible and navigable via the Tab key.

Accessibility

• Keyboard activation: Triggered by pressing the return key.
• Descriptive Link Text: Avoid vague text like "Click here" and instead use meaningful phrases such as "Read our accessibility guide."
• Keyboard & Screen Reader Navigation: Ensure links can be focused and announce their destination clearly.
• Avoid Using Links for Actions: If a link is used for an interactive feature (e.g., opening a modal), it can confuse assistive technologies.

Buttons: Triggering Actions on the Same Page

When to Use Buttons

Buttons are designed for actions that occur on the same page without navigation. Examples include:

• Submitting a form
• Opening a modal or dialog box
• Toggling content visibility (e.g., show/hide panels)
• Triggering JavaScript functionality without a page reload

How Buttons Are Displayed

Buttons are designed to look like actionable elements, and their default styles vary across browsers:

• Default Styles: Raised, with padding and a background colour
• Hover State: Often darkens or changes colour to indicate interactivity
• Active State: Provides feedback when pressed
• Disabled State: Greyed out to indicate it is non-functional (while technically possible, using disabled buttons is really bad practice for many experience and accessibility reasons)

Coding Differences

A basic button is structured as:

<button type="button">Click Me</button>

• The type attribute should be specified to avoid unintended form submissions (type="button" for general actions, type="submit" for forms).
• Buttons are naturally keyboard accessible.
• JavaScript can be attached using event listeners.

Accessibility

• Keyboard activation: Triggered by pressing the return or the space key.
• Use <button> Instead of <div> or <span>: Avoid using non-semantic elements with onclick, as they are not natively accessible.
• Ensure Focus Indicators: Buttons should have clear focus outlines for keyboard users.
• Provide ARIA Attributes When Needed: If a button’s function is unclear, use ARIA labels (aria-label) to provide extra context.
• Avoid Using Buttons for Navigation: If a button triggers navigation, it should be a link instead.

How Assistive Technologies Interact with Links and Buttons

Assistive technologies such as screen readers, voice commands, and keyboard navigation tools handle links and buttons differently based on their semantics.

• Links: Screen readers announce links as "link" followed by the link text, allowing users to understand that clicking the element will navigate them elsewhere. Some screen readers also provide a list of all links on a page, making it easier to navigate between them.
• Buttons: Screen readers announce buttons as "button" along with their label, indicating that the button will trigger an action on the page. Unlike links, buttons are not included in screen reader navigation lists for browsing page destinations.