WordPress.org

Make WordPress Core

Opened 3 weeks ago

Last modified 25 hours ago

#48641 new enhancement

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

Reported by: drw158 Owned by:
Milestone: 5.4 Priority: normal
Severity: normal Version:
Component: Administration Keywords: dev-feedback needs-design-feedback
Focuses: ui, accessibility, coding-standards Cc:
PR Number:

Description

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:

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:

http://cldup.com/PUWq1ghJb7.png

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.

http://cldup.com/0fa8NiUWOZ.png


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

Attachments (1)

buttons vs links.png (197.6 KB) - added by afercia 3 weeks ago.
WordPress 5.2 buttons, links, button-links, link-buttons

Download all attachments as: .zip

Change History (6)

#1 @drw158
3 weeks ago

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.

#2 @SergeyBiryukov
3 weeks ago

  • Component changed from General to Administration

#3 @afercia
3 weeks ago

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
3 weeks ago

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

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 weeks ago

#5 @melchoyce
25 hours ago

  • Milestone changed from Awaiting Review to 5.4
Note: See TracTickets for help on using tickets.