User interfaces usually contain elements that let users do things. Two of the most common are links and buttons. But confusion and error can arise from links pretending to be buttons and buttons pretending to be links. Making the distinction clear is part of digital accessibility.
Nonetheless, one of the most common decisions made by creators of user interfaces is to create a link that looks like a button or create a button that looks like a link.
How they differ
Links and buttons look different
- Standard links are blue underlined text (purple if recently visited).
- Standard buttons are text inside an oval or (usually rounded) rectangle.
Links and buttons behave differently
- A link takes you to another place, but a button performs an action here.
- If you focus a link by pressing the TAB key and then press SPACE, you will scroll the page. If you do the same with a button, you will press the button. That is because the SPACE key activates a button, but does not activate a link, and the usual effect of the SPACE key is to scroll vertically.
What goes wrong
So, transvestite links and buttons mislead users not only by their appearance, but also by their behavior. Users who listen to the page with a screen reader, too, can be misled by code that assigns a role of
button to a link or
link to a button. Then the screen reader will tell them it’s one thing when it’s really the other.
Worst case: A button that takes an irreversible action (
Yes, I confirm that I am waiving my rights.) pretends to be a link, so the user presses SPACE or SHIFT-SPACE when trying to scroll the page but unexpectedly presses the button instead. Web Content Accessibility Guidelines 2.1 Success Criterion 3.3.4 seeks to protect users from such involuntary actions.
For authoritative advice on treating buttons and links distinctly, see WAI-ARIA Authoring Practices 1.1. Others, such as Nils Lauk, Patrick H. Lauke, and qutax, have explained this, too.
Link claiming to be a button
Real link to this blog (in a new tab)
Button claiming to be a link