Discussion: links that look like buttons (and vice versa)

[drw158]

This issue has been moved from GitHub to Trac to increase visibility. Original GitHub discussion: ​https://github.com/WordPress/gutenberg/issues/7534#issuecomment-549980093

Summary

Sometimes, <a> elements are made to look like visual buttons to users, even though they are not actually using the <button> element. This can be problematic for some users. The reverse can also cause problems — <button> elements that look like links. This is less of a problem, because <button> elements should not use underlined text styling. There needs to be some resolution or decision on this matter.

To clarify, this is a visual/interaction issue. It's less about whether the element technically works and more about the users' expectations around what will happen when they interact with an element.

Specific issues

Here is a non-exhaustive list of potential problems:

<button> elements that look like links

Again, I think the following issues could be solved easily because of what I stated above in the summary.

• Users who right-click on the link would expect to see options in the context menu relating to links, such as Open in a new tab – which they would not see if that link was actually a button.
• Users of dictation software who see the link on the page would expect to be able to trigger it by saying ‘click link save and return to overview’, which may not work if the link is actually a button.
• Users of assistive technology would not see the link in their rotor / list of links, despite being able to see it on the page.

<a> elements that look like buttons

• Pressing the Space key or Enter triggers a button, whereas pressing the Enter key only triggers a link.
• Users of assistive technology may have problems interacting with the visual buttons if they are actually <a> elements (would love clarification from an expert on this).

<a> elements should always look like links (plain, underlined text)

This is problematic because:

• The interface calls for a primary action to look prominent. Links are inherently less prominent than buttons.
• When related actions are grouped together, it's ideal to style them the same to show relation. Sometimes it's a mix of <a> and <button> elements.

Simple links don’t always catch a user’s attention when they’re scanning a website. So a link is sometimes
styled to look like a button where you want to give it greater prominence.

Source: ​gov.uk

Current solution

I believe attempts have been made in the past to make links more visually more prominent without looking like a button:

This is a commendable attempt, but in my opinion it still looks like a button, therefore the problem it attempts to solve still persists. Additionally, it creates a problem by introducing another type of visual "button" that is inconsistent with standard WordPress buttons.

As we make <a> elements bigger and visually more prominent, I think they'll inevitably look close to a visual button. I understand they don't have to look like a button, but as you add more padding, and a background/outline to indicate click area, it immediately starts to look like a button. Any differences with a button will be subtle, and we'll probably still have some confusion with interactions.

Proposal

Considering a11y and design concerns, and understanding there is no "correct" answer, I believe this is the optimal compromise:

• Visual buttons should be able to use either the <a> or <button> element. This flexibility is provided so developers can make the most semantic markup possible. This also allows designers to ensure a consistent and usable visual experience.
• button elements should not look like links (plain, underlined text).

Additionally, we could provide a bit more affordance for <a> elements that look like visual buttons, by adding an icon to the right (similar to how we add an "external" icon to external links.

---

Related discussions and prior work done on button/link semantics:

• Enhancement: improve tertiary button styles: #48501
• https://core.trac.wordpress.org/ticket/40470#comment:11
• ​https://github.com/WordPress/gutenberg/issues/7534#issuecomment-510534529
• Semantic elements for non-link links: #26504
• https://core.trac.wordpress.org/query?keywords=~semantic-buttons

[drw158]

Another scenario to consider is when interactions change based on the availability of JS. For example, when no JS is available, some actions may become links. In this case, I think the element should still look visually the same whether or not JS is available.

[afercia]

Thanks for taking action and opening this ticket!

As a quick example of the potential confusion between links and buttons in the admin UI, the screenshot attached below may help to illustrate where things stand. Would users be able to distinguish at first glance which of them is a link or a button and consequently adapt to the expected interaction (e,g, press Enter or Spacebar, expect navigation or an action, etc.)?

[afercia]

WordPress 5.2 buttons, links, button-links, link-buttons

[karmatosed]

Noting after the design team discussed this we are putting to a future milestone, we will get to this but right now it's not going to happen in 5.4.

[paaljoachim]

Based on @youknowriad 's comment here: ​https://github.com/WordPress/gutenberg/issues/7534#issuecomment-568749065
It sounds like Gutenberg has these components in a good place.

Perhaps core still have a few things to fix here?
@melchoyce @ryelle

Associated ticket:
https://core.trac.wordpress.org/ticket/48452

[ryelle]

I think this ticket needs a champion to advocate for it. Right now, we do still have both cases (in core and in gutenberg) where links look like buttons, and buttons look like links.

An updated overview of problem elements would help - afercia's screenshot is good, check how many of those are still valid - and identify which components need to change, if any.