Use a link when the user goes somewhere
<a href="…" >
Use links for navigation to pages, sections, files, email addresses, phone numbers or other resources.
The rule
Use a button when the user does something
<button type="button">
Use buttons for actions that change, submit, open, close, reveal, save, delete or otherwise affect the current interface.
Pop quiz: what should it be?
Answer the question based on what the control actually does, not how it looks in the design.
Button or link examples
-
Product card
Right answer: link
It takes the user to the product page.
-
Add to favourites
It changes state on the current page.
-
Open modal
It opens an interface layer, not a new location.
-
Download PDF
Right answer: link
A file is a resource. Users should be able to copy, open and save the target.
-
Accordion header
It expands or collapses content.
-
Pagination
Right answer: usually link
Each page usually represents a navigable location with its own URL.
-
Sort table
It changes the order of content on the current page.
-
Language switcher
Right answer: usually link
It usually navigates to another language version of the current page.
-
Log out
It performs an account action, often with security consequences.
Code examples
Navigation: use a link
<a href="/pricing">Pricing</a>Action: use a button
<button type="button">Open menu</button>Avoid: link that behaves like a button
<a href="#" onclick="saveSettings()">Save settings</a>Avoid: button that behaves like a link
<button type="button" onclick="location.href='/pricing'">Pricing</button>Accessibility notes
A button and a link are not just visual styles. They expose different roles to assistive technologies and have different expected keyboard behaviour.
- Links are expected to navigate and are activated with Enter.
- Buttons are expected to perform actions and are activated with Enter and Space.
- Using native HTML reduces the need for ARIA and custom keyboard handling.
- WCAG 4.1.2 is relevant because user interface components must expose a correct name and role programmatically.
Important: This page is designed to support WCAG 2.2 AAA and EN 301 549-aligned implementation, but compliance still requires testing in the final production context, including content, design, browser behaviour and assistive technology support.
Release checks
These checks are included as reminders because they are easy to break when the visual design changes.
-
Dark mode
Test with system dark mode enabled. Text, borders, focus indicators and verdicts must remain readable.
-
Text size
Increase browser text size and verify that content grows without clipping or overlapping.
-
Zoom and reflow
Test at 200% and 400% zoom. The page should remain usable without horizontal scrolling, except inside code examples.
-
Mobile
Test narrow widths around 320 CSS pixels. Navigation, forms, cards and buttons must remain easy to operate.
Further reading
Five solid references for the next lesson.
-
MDN: The HTML button element
Good reference for native button behaviour and when buttons perform actions.
-
MDN: The HTML anchor element
Good reference for links, URLs, fragments, downloads, email and phone links.
-
W3C: Understanding WCAG 4.1.2 Name, Role, Value
The WCAG connection: controls need correct programmatic names, roles, states and values.
-
A11Y Collective: A Web Developer’s Guide to Buttons vs Links
Practical explanation of keyboard behaviour, screen reader expectations and common examples.
-
Make Things Accessible: Links vs buttons vs other clicky things
A useful deep dive into what breaks when custom “clicky things” imitate native controls.