Links vs Buttons
“Should this be a link or a button?” is one of those devious architectural and semantic questions that looks like it should have a simple answer but does not.
It did once, when people were using the web strictly for hypertext and the occasional form. Then Web 2.0 came along and made everything app-like and the whole decision-making process fell off a cliff.
Links go places. Buttons do things.
This is essentially the first rule of deciding between the two, and stems on whether the interaction you want to create will take the user out of their current context or keep them in the current context but somehow transform the information.
If you’re moving the user to a new context, use a link.
If you’re transforming the information in the current context (adding, removing, reordering, editing, submitting, clearing), then use a button.
Links look like links. Buttons look like buttons.
Once again harkening back to ye olden days, at the beginning of the web it was impossible to mistake a link for a button because all links were blue text and all buttons were grey boxes with rounded corners and a gradient or bevel. Users knew what to expect of links, and they knew what to expect of buttons. Designers couldn’t restyle one to look like the other because CSS didn’t exist yet.
Fast-forward to 2020 and the current state, where we can make a link look and behave like a button, and a button look and behave like a link, and a stack of divs with a pile of Javascript look like either a button or a link and behave any way we want, and we have a semantic mess on our hands.
Jakob’s Law tells us that our users want our site to behave like all the other sites they use, and that means if it looks like a link they want it to behave like a link, and if it looks like a button they want it to behave like a button.
Where does the difference between a button and a link start and end? I’m not sure anyone can say for sure, but there’s definitely a problem when our buttons are so unstyled (or our links so decorated) that users can’t predict what they’re going to do. Usability testing is key here.
What about links or buttons in larger components?
The biggest challenge occurs at the information architecture stage when we ask ourselves, “Does this change the context?” and the answer is “eeeh, sort of?” This is where things get dicey, and it’s in part because HTML by and large doesn’t have native elements for controls that aren’t links or buttons. Tabset? Nope. Accordion? Nuh-uh. The standards writers can’t even pass the Dialog component and they’ve been working on that for ages.
Dialogs, tabs, accordions… we’ve spent a lot of hours already researching the role vs. button and there’s a ton of conflicting opinions.
In fact, the problem goes deeper: to the specifications themselves. A user who’s about to click on a tab in a tabset doesn’t expect the item to be either a link or a button. They expect it to be a tab. “Tab” isn’t a native HTML element, though, so when we’re trying to build semantic HTML, we don’t have that tool in the toolbox.
Enter ARIA
ARIA, or Accessible Rich Internet Applications, is a set of attributes that help people with disabilities or using assistive technology better identify what a website is displaying. It gives us the opportunity to label a tab as a tab, and the container that it’s in as a tabset. It can identify whether an accordion is opened or closed, and whether the item that currently has focus is a dialog.
The First Rule of ARIA Use is “If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible then do so.”
That means we don’t create divs (or worse, links) and then put an ARIA role of button on them, for example. We use ARIA to extend, not recreate, what HTML already provides.
Now that ARIA is available, however, the angst of “what is a link vs what is a button” is (somewhat) lessened. Extending our tab example, it doesn’t much matter whether we use a link or a button, so long as whatever we use identifies itself as a tab and whether or not it’s selected. We will still research the consensus on the most accessible and usable implementations, choose a standard, and apply it, but without tearing our hair out about every single detail.
We’re probably not going to get it right all the time and that’s ok, as long as we test the heck out of it, have people with disabilities test the heck out of it, and respond to feedback.