[wp-trac] [WordPress Trac] #48641: Discussion: links that look like buttons (and vice versa)

[WordPress Trac]

#48641: Discussion: links that look like buttons (and vice versa)
-------------------------------------+-------------------------------------
 Reporter:  drw158                   |      Owner:  (none)
     Type:  enhancement              |     Status:  new
 Priority:  normal                   |  Milestone:  Awaiting Review
Component:  General                  |    Version:
 Severity:  normal                   |   Keywords:  dev-feedback needs-
  Focuses:  ui, accessibility,       |  design-feedback
  coding-standards                   |
-------------------------------------+-------------------------------------
 ''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: [https://href.li/?https://designsystem.gov.au/components/buttons
 /#links-as-buttons 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:

 [[Image(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.

 [[Image(http://cldup.com/0fa8NiUWOZ.png)]]

 ----

 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

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48641>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform