Insufficient color contrast on Editor Top Bar

[karlgroves]

Insufficient color contrast on Editor Top Bar

• Severity: Medium
• Affected Populations:
  • Low-Vision
  • Cognitively Impaired
• Platform(s):
  • All / Universal
• Components affected:
  • Editor Top Bar

Issue description

Some controls within the Editor Top Bar have contrast ratios below the
4.5:1 minimum:

• "Saved" text and its icon: #a2aab2 (light grey) on #fff (white):
  2.35:1

The "Publish" button remains focusable and clickable but with low
contrast:

• When unfocussed: #4daacf (light blue) on #005d82 (darker blue):
  2.75:1
• When focussed: #fff (white) on #b2d8e7 (this is dark blue #007eb1
  but with .3 of the normal opacity): 1.51:1
• After being made visibly enabled: #fff (white) on #0085ba (blue):
  4.15:1

Sufficient color contrast is important for users who have low-vision or
are color-blind, because text with a low contrast ratio may be difficult
or impossible for such users to see.

Issue Code

    /* "saved" text and icon on a #fff background */


    .editor-post-saved-state {


        ...


        color: #a2aab2;


    }





    /* "Publish" unfocussed: */


    .components-button.is-primary:disabled,


    .components-button.is-primary[aria-disabled=true] {


        ...


        color: #4daacf;


        background: #005d82;


        text-shadow: 0 -1px 0 rgba(0,0,0,.1);


    }


    /* "Publish" focussed: */


    .components-button.is-primary:focus:enabled,


    .components-button.is-primary:hover {


        background: #007eb1;


        ...


        color: #fff;


    }


    .components-button:disabled,


    .components-button[aria-disabled=true] {


        ...


        opacity: .3;


    }

Remediation Guidance

Darken the "Saved" text until it meets the 4.5:1 minimum ratio.

Do not allow focus to reach the "Publish" button when it's attempting
to display a disabled state. Either increase the contrast at all times
or make the button truly disabled until the "Publish" button can
be activated.

Other disabled controls use disabled colors and are focusable, however
their visible tooltips have sufficient contrast, allowing a user with
low-vision to read what the disabled control's name and keyboard
shortcut is.

Recommended Code

    /* "saved" text and icon */


    .editor-post-saved-state {


        ...


        color: #767676;


    }





    /* Publish button */


    .components-button.is-primary {


        background: #006a95;


        ...


        color: #fff;


    }

Relevant standards

• 1.4.3 Contrast (Minimum) (Level
  AA)

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-1 in Tenon's report

[afercia]

Agreed on the general issues and some of the elements certainly need better contrast. Worth reminding disabled controls (text that is part of inactive user interface components) have no contrast requirement.

[melchoyce]

Full report screenshot:

[StommePoes]

As a note: if "Publish..." is meant to be disabled, the better recommendation is to prevent it from receiving focus and give it a disabled attribute.

[afercia]

Re: this part:

Do not allow focus to reach the "Publish" button when it's attempting to display a disabled state. Either increase the contrast at all times or make the button truly disabled until the "Publish" button can be activated.

This is intentional and meant to avoid a focus loss, which is a terrible experience for keyboard users and assistive technology users.

Basically, when using a keyboard or assistive technologies that mimic the functionality of a keyboard, pressing "Publish" and disabling the button with a disabled HTML attribute would produce a focus loss. We'd like to avoid focus losses 🙂This is the reason why in a few places Gutenberg "noop"s the buttons and uses aria-disabled instead of making the buttons disabled and no longer focusable.

Worth also reminding that disabling the setting "Enable Pre-publish Checks" makes the Publish button publish directly with just one click: in this scenario the focus loss is clearly evident.

Focusability of disabled controls is specifically addressed in the ARIA Authoring Practices. While the recommendations there are primarily meant for ARIA composite widgets, the basic principle still applies: there are cases where keeping controls focusable makes sense. More importantly, "a consistent set of conventions for the focusability of disabled elements" should be adopted across the whole application.

[StommePoes]

We saw the noops and have seen similar setups on other clients (disabled controls which wanted to show tooltips explaining WHY the controls were disabled, ie because the application page was in a readonly state... which required they also appear on focus, so they couldn't be disabled, etc). It opens a can of worms especially when designers and developers are making "disabled" styles, as we see every time a developer re-invents "disabled links" where they do

a[aria-disabled="true"] {
  cursor: default;
  unreadable-super-such-wow-low-contrast styles;
}

Myself, in the past I've made containers around getting-disabled-after-clicking controls which temporarily gain focus (tabindex=-1) if there are no visually-nearby focusables (my other preferred method, similar to clicking "Bestel" on this page https://www.vanbeekdesign.nl/facilitair-inrichting-warme-en-koude-dranken-koffie/7704/ ).

Having JavaScript set temporary focus on the button (set focus on button with tabindex=-1 + aria-disabled until at least one Tab event is heard, then convert to disabled state) would solve the hocus-focus but is rather weird and convoluted.

Ultimately if the decision remains to do these half-way disabled controls for all the reasons you list above, then I think the bug as written is pretty good-- it's focussing on the contrast issue and that's what likely should be changed.

Figuring out another way to visually convey the disabled-ness then may be a separate issue.

[afercia]

Thanks @StommePoes

Having JavaScript set temporary focus on the button (set focus on button with tabindex=-1 + aria-disabled until at least one Tab event is heard, then convert to disabled state) would solve the hocus-focus but is rather weird and convoluted.

Yep, I'd like there was an easier (native?) way to use native semantics and avoid focus losses at the same time. Setting disabled on the fly is probably a scenario that hasn't been considered in the various recommendations, as it typically applies to patterns used in "single page" web applications or for preventing forms multiple submissions via JavaScript (a classical case of focus loss).

Figuring out another way to visually convey the disabled-ness then may be a separate issue.

Yup, any proposal for a better method would be very welcome.

[melchoyce]

👋 We discussed this ticket in #design triage today.

The design team & co have started updating focus styles per #15325 and https://core.trac.wordpress.org/ticket/34904, but it sounds like we should take more of a holistic look at button styles. We'll be look at that across both Gutenberg and core soon.

Per this particular issue, we'd like to reverse the disabled text so it's still visible. I know there's no guidelines, but do you think 3:1 contrast is sufficient, or should we still try to ensure 4.5:1?

[StommePoes]

If it's an icon button you can get away with 3:1 but for buttons like Publish, because it's about text readability, 4.5:1.

So might be more like "give the button a whole different style" (such as, pale grey background/border but dark-grey text like w3c/wcag#555 on #ccc and hope consistency of style for all disabled-thingies helps people figure out why clicking it does nothing) but I'm unsure if it's possible for folks/plugins to theme the editor itself.

If by "reverse" you meant something like taking the white-on-blue "enabled" buttons and switching foreground and background for "disabled", that'll meet 4.5:1 since they do now.

[afercia]

I'm not fully sure I agree :) Gutenberg communicates some buttons are disabled via aria-disabled and "noop"ing them, for the reasons explained above. This is equivalent to real "disabled" buttons. In this case, it makes sense to me to communicate their (pseudo) disabled state also visually.

Unless I'm missing something, I'm not sure I understand why a button that doesn't do anything and has an aria-disabled="true" attribute should look like an enabled button? @StommePoes what am I missing here? 😄

[StommePoes]

If I can focus on it, I need to be able to read it. That's my view. If it's disabled and taking advantage of the usual WCAG contrast exception (it's disabled and I cannot interact with it) then while I'm still on the fence about whether I can read that (its existence can be argued as "there to convey information" otherwise it would be removed... on the other hand, removing/adding controls to an interface can suck coga-wise), if I can focus it, then it's moved a step further into "it's conveying some information."

One argument against my argument is that here, we're in an interface where users, even with short-term memory issues and whatnot, are not on J Random Website but somewhere where they're getting repeated exposure to the input. :P

Anyway, if you still disagree with that argument, cool :P But that's where I'm coming from.

[afercia]

Adding some general considerations and possible options:

"Saved" text

Suggested action:

Darken the "Saved" text until it meets the 4.5:1 minimum ratio.

Of course yes, any text should have a sufficient color contrast.

Other considerations:

As previously noted a few times, when activating the "Save Draft" button, the button gets removed from the DOM and replaced with a <span> element containing the "Saved" text. This produces a focus loss. Though some browsers (webkit and Firefox) implement a so called sequential focus navigation starting point, that's not guaranteed to work when assistive technologies are used and doesn't work with other browsers. For example, with IE11 keyboard users have to start again navigation from the document root. Regardless, of the browser used, technically this is a focus loss and needs to be avoided. Will split in a specific issue. There's already #15529 which covers this point.

Publish button and other buttons

It's interesting to note the Toolbar example in the ARIA Authoring Practices includes some buttons that use aria-disabled. If I'm not wrong the Toolbar example was recently updated to include more types of elements and better showcase best practices.

The Copy, Paste, and Cut buttons use aria-disabled and have a low color contrast: 3.48.

They switch to "enabled" state only when there's a selection and something copied/cut ready to be pasted. At that point the color contrast is higher.

This seems to me the same pattern used in Gutenberg and I'd tend to think it's acceptable.

However:

I'd suggest to consider some improvements. The initial state of the Preview and Publish button uses a too low color contrast that makes the buttons text almost unreadable:

This is also inconsistent with the WordPress styles for disabled buttons:

Primary button disabled:

Secondary button disabled:

Not saying the WordPress disabled styles are perfect 🙂they can certainly be improved. It would be great to start improving the Gutenberg ones.

Of course, this applies also when the Publish button says "Update":

Worth also noting when the Publish/Update aria-disabled button receives focus, the colors change as reported in the audit:

Not sure a UI control that is communicated as "disabled" should change colors on focus. Regardless, the text should be a bit more readable in all states.

Suggested actions:

• Improve the contrast of disabled/aria-disabled buttons: they don't necessarily need to meet the contrast requirement but at least their text should be better readable. Consider also consistency with WordPress patterns.
• Don't use opacity to reduce contrast: it makes checking color contrast very difficult. Also, automated accessibility checkers will hardly be able to calculate the contrast. If there's consensus on this point, I guess it should be addressed in a separate issue.

[StommePoes]

Some thoughts:

Regardless, of the browser used, technically this is a focus loss and needs to be avoided.

Agreed. A browser here or there doing it "right" doesn't mean much. Developers are choosing this pattern of removing or disabling a button; they get to deal with the aftermath of focus responsibility (I feel like a mom now).

It's interesting to note the Toolbar example in the ARIA Authoring Practices includes some buttons that use aria-disabled. If I'm not wrong the Toolbar example was recently updated to include more types of elements and better showcase best practices.

The Copy, Paste, and Cut buttons use aria-disabled and have a low color contrast: 3.48.

Looking at the Gutenberg role=toolbar element, one thing that happens to stand out is that while the buttons themselves are low contrast, they have custom tooltips with their names which are pretty high contrast. prevew/publish/update buttons are a different style and don't have that, but that's a technique that kinda conveys both ideas: that the control is meant to be currently unusable, and that its name is still clearly available.
Though with the current design it would look pretty weird. I never figured out why some buttons were icons while others had full text. Seemed very random to me.

With clients we've had in the past which needed fake-disabled controls in order to show tooltips on focus, these tooltips were meeting contrast requirements and it was okay that the controls themselves didn't. Similarly, I notice the Toolbar example has good, high focus styles on the borders exceeding 3:1.

Re WP disabled styles: personally, I cannot read the primary example but I can read the secondary one (just a note I wanted to say). Maybe related: current discussion over by the WCAG-ers about potentially moving to a less-sucky algorithm for colour contrast someday far, far in the future (w3c/wcag3#192).

[Myndex]

Maybe related: current discussion over by the WCAG-ers about potentially moving to a less-sucky algorithm for colour contrast someday far, far in the future (w3c/wcag3#192).

Hi @StommePoes Hopefully not "too" far in the future, the research is moving along fairly well. But one thing I am discovering in research and perception experiments is there is a lot more to human contrast perception than just a ratio between two colors, and much of these other issues are not well studied much less defined or listed in standards for monitor display/web content.

I'm in the process of moving portions of the study to my ResearchGate account here if you want to follow along: https://www.researchgate.net/project/An-Accurate-Programatic-Perceptual-Contrast-Assessment-for-Website-Color-Schemes

I intend to make it more active my current experimental findings. At the moment some of the current experiments are here: https://www.myndex.com/WEB/Perception

The plan is to have a live web test to gather experimental results from the public in subject's normal environments, and my aim is to hopefully have things defined for WCAG 3.0.

• Andy

[melchoyce]

We talked about this issue during today's design triage.

We'd like to improve this by swapping the disabled buttons in Gutenberg to using core styles in the short-term, and exploring better disabled styles for all of WordPress in the longer term.

Mockup:

[tellthemachines]

The Saved button has been changed to #555d66 grey on white background so now passes AA contrast requirements. Can this issue be closed or is there any further action to take on disabled button states?