Accessibility regression: The new buttons style prevents from identifying them as interactive user interface controls

[afercia]

Describe the bug
In the WordPress 5.5 block editor, the "Save draft", "Switch to draft", and "Preview" buttons have been restyled and in their normal state they now look like plain text.

For accessibility, and I'd say also for a good UI, they should be styled in a way that they can be identified as user interface controls at first glance.

In WordPress 5.4, they weren't perfect either but at least:

• the "Save draft" button, although it missed a shape or an underline, had blue text: blue is a well established convention in WordPress for interactive controls
• same for the "Switch to draft" button
• the "Preview" button looked like a button, which was OK

Screenshots:

Instead, now in WordPress 5.5 they look like plain text:

• in their normal state, there's no shape or underline to identify them as buttons
• the buttons text color is a dark grey #1e1e1e which makes them look as plain text

Screenshots:

Recommended:

• either restore the blue color and add an underline
• or, preferably, make them look like buttons, because that's what they are

[afercia]

As far as I can tell, these buttons style was changed in #21192.

[MichaelArestad]

Have you heard any reports of confusion around this change?

These buttons are consistent with the rest of the actions in the toolbar. The buttons have very visible focus/hover states that clearly show them as a button. Almost every item in the toolbar is a button or action. Anything that is disabled is greyed out. The "Saved" text is also greyed out.

[afercia]

I do realize now this is an issue with all the new buttons styling.

The buttons have very visible focus/hover states that clearly show them as a button

The point is in the normal state, these new buttons don't look like buttons. They look like text. And they're all over the interface now.

[MichaelArestad]

The point is in the normal state, these new buttons don't look like buttons. They look like text. And they're all over the interface now.

I understand what you're saying. I have not seen any evidence that it is a point of confusion in the toolbars. In both Mac and Windows operating systems, there is a window toolbar where "File," "Edit," and "Help" items live that don't have any distinguishing button characteristics yet function as buttons. You can see similar patterns in many Google applications (Docs, etc). This works because there isn't a mix of text and buttons. They are all buttons/actions. Both the block toolbar and the top toolbar only have actions. There is no text mixed in.

If there are specific cases where buttons are next to text, we should visually differentiate them and we can do so using the other button styles (secondary, etc). For the toolbars, my recommendation is for them to remain as they are currently.

[enriquesanchez]

I agree that this is not an issue because by being in the editor's toolbar, these actions are visually evident as such from page design and context.

[afercia]

Thanks @MichaelArestad I do understand your point. In a way, someone may consider this issue similar to the recommendation for underlined links where, when links can be identified as such by the context, they don't necessarily need to be underlined.

However, I think this is a bit different. For low vision color impairment, etc, this really looks just as text.

This works because there isn't a mix of text and buttons.

Not entirely correct: in the toolbar, the "Saved" text is just text and vor users with vision problems, it looks exactly like "Preview".

More importantly, I see this is now the styling for all the default buttons all across the admin. For example in the block placeholders:

To me, this is an issue. I'd bring it to the attention of the accessibility team in the next weekly meeting to see what others think.

[afercia]

Noting that also controls like "Move to trash" look now just as red text:

While in the Classic editor, "Move to trash" is underlined and for good reasons, even though it's close to other interactive controls:

[MichaelArestad]

Not entirely correct: in the toolbar, the "Saved" text is just text and vor users with vision problems, it looks exactly like "Preview".

Right. I mentioned that above: "Anything that is disabled is greyed out. The "Saved" text is also greyed out." The copy, styling and context distinguishes it from the rest of the actions in the toolbar.

We could change the top toolbar buttons "Preview" and "Save draft" to use the blue text styling. It will bring the styling in line with the buttons in the block placeholders.

[shaunandrews]

Its worth noting that we have plenty of other examples where buttons with only text are used in similar manners to indicate an action:

This is just in the block editor. There's lot of examples throughout the rest of WordPress, too.

[enriquesanchez]

I come back to my previous comment about these being identified as interactive elements based on context and page design. They exist in the context of a toolbar, as such they inherit meaning.

A few examples where this meaning by context situation also occurs:

Google Docs

File, Edit, View, Insert, etc. They're all interactive elements and are understood as such based on context and page design.

macOS

File, Edit, View, History, etc. Same as above, they don't need to look like buttons or links because by context they're inheriting the interactive meaning.

W3C

The items in the table of contents don't have an underline or different color. They are understood as links by way of the context they're in.

---

The above is also happening with Gutenberg's toolbar. It is a toolbar and as such, it is understood that the items inside it are interactive elements.

Now, all of the examples above are not doing that because they want a "minimalist" or "clean" user interface. This is done on purpose for balance and hierarchy of information. It aids with cognitive load and helps users understand and find they way around the interface.

[afercia]

@MichaelArestad

The "Saved" text is also greyed out." The copy, styling and context distinguishes it from the rest of the actions in the toolbar.

Then I'm afraid we agree we disagree 🙂 To me, this (see screenshot below) is not sufficiently distinguishable:

@shaunandrews

Its worth noting that we have plenty of other examples where buttons with only text are used in similar manners to indicate an action:

The examples in your screenshots are from menus. In a menu, I'd expect all the items are interactive buttons. This is a case where I'd agree context clarifies what these text are.

@enriquesanchez

Your first two examples are from operating systems UIs. That's a very different case. The last example is a navigation menu made of links. As you may know, the WordPress accessibility coding standards themselves state that in that case links don't necessarily need to be underlined: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/accessibility/#links-underline-or-no-underline

I'd also like to know if this change to the buttons has ever been user tested and whether there are data that show it benefits everyone. I do realize that would broaden the discussion a bit too much, though.

Whatever the design arguments are, one thing is pretty clear to me. In WordPress 5.4 the controls highlighted in the screenshot above were clearly identifiable as interactive controls (with the exception of "Save draft"):

In WordPress 5.5, they aren't:

To any web accessibility specialist, this looks like an obvious regression in the accessibility level compared to the previous version.

Latest conversation on Slack during the accessibility bug scrub special edition last Tuesday: https://wordpress.slack.com/archives/C02RP4X03/p1596554991310600

Most relevant points:

• Some first (admittedly anecdotal) feedback from users, pretty confused by this change.
• The only fact there’s a large disagreement on this change it’s a good reason to revert and better consider in the next cycle.
• We (accessibility team) all realize this change is part of an overall design shift and handling this more holistically would be important; but that can't happen in 5.5.
• However, what can be done now for 5.5? Not sure a revert, per se, is the best option but restoring a design that makes it clear that these are controls would help.
• from @joedolson: If we make a request, I think it needs to be very specific; preferable would be restoring the design characteristics previously in place, and address this more systematically for 5.6.
• from @afercia: I’d second @joedolson as it seems the safest option to me, for now.

In absence of a solution, if WordPress 5.5 is released with the current buttons design, I'm afraid the accessibility team won't have any option other than considering this an obvious regression in the accessibility level compared to WordPress 5.4.

[afercia]

Since the new buttons design applies to many other buttons in the UI and #24420 only changed the text color of some of these buttons, I don't think the accessibility and usability issue is fully solved and this should be further discussed and better addressed.

This is even more important considering that, sooner or later, the new Gutenberg design should be synced with the other admin pages. Extending the new buttons design to the rest of the admin would be a huge accessibility regression.

Reopening.

[MichaelArestad]

I don't think the accessibility and usability issue is fully solved and this should be further discussed and better addressed.

@afercia Can you please rename/rewrite this issue or create a new issue to discuss the broader topic as the specific topic of this issue was resolved: "Accessibility regression: "Save draft", "Switch to draft", and "Preview" buttons can't be visually identified as user interface controls"

I lean toward the creation of a new issue that clearly states the problem, goes over individual examples, and references this issue.

[afercia]

@afercia Can you please rename/rewrite this issue or create a new issue to discuss the broader topic as the specific topic of this issue was resolved: "Accessibility regression: "Save draft", "Switch to draft", and "Preview" buttons can't be visually identified as user interface controls"

@MichaelArestad Id' like to point out that the specific issue initially reported is not solved. The only change to the "Save draft", "Switch to draft", and "Preview" buttons is that their color was changed from dark grey to blue.

Color alone is not sufficient 🙂

I'll gladly rename this issue. As for the issue description, I think it has been explained sufficiently and it's clear that it applies to all the buttons with the new style, see for example #23890 (comment)

[ZebulanStanphill]

@afercia What do you think of this mockup?

[afercia]

@ZebulanStanphill I think the look like beautiful buttons 🙂

[ZebulanStanphill]

More beautiful buttons: #25632.

[ZebulanStanphill]

Alright, we ran into some issues with the button design in #25632:

• The current design looks just like a text input. We need to come up with distinct visual differences (in shape, not merely color) to distinguish between all of the following:
  • plain text
  • links
  • text input
  • secondary button
  • primary button
• Concerns over removing button hierarchy. Do we actually need both an isSecondary and isTertiary style? The distinction seems rather arbitrary to me. And don't forget, isSmall and isLink (ugh) also exist.

My thinking is that all buttons should have a visible border unless they are in a toolbar. Of course, text inputs should also have borders, so how do we distinguish the two? Perhaps we can alter the borders of one or the other. I've seen some UIs use round borders for buttons and square borders for text inputs. How does that sound?

Simply underlining buttons is a bad idea since underlines are traditionally reserved for links. And remember, links have to use underlines (or something similar) because color alone is not enough to distinguish them from other text, due to colorblind users. So links are pretty locked in to their current style, as far as I can tell.

Also keep in mind that changing border thickness to indicate button vs. text input is also probably off the table due to that already being used to indicate unfocused versus focused... unless you want to redo focus styles.

And finally, remember that we need sufficient color contrast for whatever border/background colors we use.

So... any thoughts/ideas?

[afercia]

I do understand the concern raised by @enriquesanchez in #25632

At first glance, these buttons look like input fields to me. You can see how there's little to no visual difference between the proposed style for buttons and the 'Add tags' field:

We need a balance that makes it clear these are buttons but that also not overwhelm a whole other set of users.

Re-posting here the screenshot used as example on #25632:

I'd like to note that in WordPress 5.4, before the buttons redesign, the shape of the buttons and the input fields was very similar: they were both "rectangles with rounded corners". What actually helped in clearly distinguish the buttons from the input fields was:

• the buttons had a default blue border
• the buttons had a default light grey background

Screenshot from WP 5.4:

To me, this is just one more reason to revert the buttons style change 🙂

Regarding the "tertiary" style: I never really understood why it was necessary. Historically, in WordPress there have been only two button styles: default and primary, where the latter should be exclusively used for the main action in a page.

[carolinan]

Since there is no progress reported on a new design for these buttons, can the change be reverted and the old style implemented while a new design is being worked on?

There doesn't seem to be any disagreement on this being a regression.

[cbirdsong]

Can this be revisited? I've had to explain that buttons look like inputs and vice versa to several clients in training sessions.

[afercia]

As of December 2024, this issue is still valid. The default and, more importantly, tertiary variants aren't accessible. These two variants need a new design.

In the screenshot below: default, primary, secondary, tertiary, link: