should buttons that look like links have the exact same keyboard accessibility?

Question

We have a few use cases where we need to show something that looks like a link, but is actually a button.

For example, consider this error message:

• Sorry we couldn't place your order. Please click here to get help

Now this click here looks like a link, but on click it just opens up another chat widget on the same screen. It does not navigate anywhere. Semantically, it should be a button (correct me if I am wrong).

But then we also have links on our platform that also appear inline and look the same.

And there seems to be no reason to visually differentiate between the two.

What I would like to understand is whether the button that looks like a link should also have keyboard accessibility similar to a link. Would it be unexpected for a user if it works using the Space key as well?

OR, does it make sense to visually differentiate between an inline button vs. a link?

Answer 1

There are a lot of individual points to make here so excuse if I just give the "broad strokes" of an answer.

Click here

Firstly "click here" - please never do that. Screen reader users may navigate your website via links and so the text within them needs to be descriptive.

Either change the phrasing or change it to "click here to get help with placing your order".

I know this wasn't your question but is still a really useful thing to know!

Buttons that look like links (and vice versa)

You should differentiate between a link and a button but that is not a massive accessibility concern anymore as inline text has become "expected behaviour". I would recommend adding a dotted underline on buttons to differentiate them / make stand out but the bold text is OK as a bear minimum.

Do make sure that focus indicators and hover states are implemented correctly as this often gets overlooked on inline text links.

Inline text as a button is fine, provided that your tap target size is greater than 44 css pixels to help people who have coordination / accuracy impairments a better experience (i.e. Parkinson's Disease or Cerebral Palsy). You can achieve this with padding on inline buttons and still maintain the same visual style. I would also recommend doing this on hyperlinks where possible.

Button vs Link

Semantics are very important. Hyperlinks should be used when there is a change in page (or the URL updates in a SPA application as that is the same thing.)

Buttons should be used for content on the same page.

This is important for screen reader users who can then ascertain what to expect (behaviour wise) after pressing a link or button.

Does it make sense to differentiate between a link and a button?

Yes.

As I said earlier it is more acceptable to use inline text as a button but that doesn't mean there aren't benefits in differentiating between them.

Some people may want to open pages in a new tab with a middle click (or right click and open as new tab). By knowing which are links and which are buttons it saves frustration.

People with anxiety disorders will also find your site more pleasant to use if they know that clicking text that looks one way will open a new page and clicking text that looks another way will perform an action on the same page.

Anxiety disorders are often overlooked when talking about accessibility.

There is loads more I could add here but in summary (and in order of importance):

1. Get rid of "click here" links
2. Use semantically correct elements, this will cover 80% of accessibility concerns.
3. Make sure you have focus indicators and hover states set up correctly.
4. Differentiate your links and buttons in some way.

Answer 2

Links and buttons are not activated in the same way. The ENTER key activates a link. Either the ENTER key or the SPACE key activates a button. The SPACE key normally scrolls the page. So, if you make a button look like a link, the user who puts that button into focus and then presses the SPACE key should expect the page to scroll. Instead, the user will, unexpectedly, have activated the button. This violates a fundamental accessibility principle: The UI should make it known to the user what action the user will take before the user does something.