Color Contrast raises errors in automated tests for WordPress Dashboard

[bobbingwide]

On the WordPress Dashboard ( wp-admin.php ) the WAVE evaluation tool reported 32 Color Contrast failures when using the Default Administration Color Scheme in my local development environment.

In my opinion, WordPress should be setting an example with regards to accessibility, addressing both the front-end and administration areas of WordPress core.
I believe that WordPress core should be updated such that WAVE will not produce Contrast Errors on the dashboard.

In my local development I was able to eliminate these errors with some custom CSS that addressed several different problems.

• problems with hidden screen reader text for Move up, Move down and Toggle panel buttons on postboxes
• problems with hidden screen reader text for Community events
• problems with low contrast on vertical bar separators in

Community events and Recent comments

I developed the following CSS which reduced the Color Contrast errors to 0.

button.handlediv span.screen-reader-text,
button.handle-order-lower span.screen-reader-text,
button.handle-order-higher span.screen-reader-text,
.community-events-footer .screen-reader-text {
    color: #000000;
    background-color: #ffffff;
}

.community-events-footer {
    color: #74747b;
}
.row-actions {
    color: #6e7177;
}

.activity-block .subsubsub li {
    color: #74747b;
}

This custom CSS implements the recommendation from a member of the WebAIM team who, in response to my question "Should I attempt to deal with Color Contrast messages related to screen-reader-text by, for example, setting foreground and background colors? OR will that hide a problem waiting in the wings." replied...

"Our approach is to test hidden content because most often hidden content might later be presented to users. The best solution to these contrast errors is to define foreground and background colors that meet the WCAG requirements. At a technical level WCAG requires this even for elements that are not made visible."

Details of the problems, incl. screen captures, and the solutions I chose to implement can be found in GitHub comments from ​https://github.com/bobbingwide/oik/issues/79#issuecomment-3568176108 to ​https://github.com/bobbingwide/oik/issues/79#issuecomment-3582610716

Note: In my initial investigation I was using the default Adminstration Color Scheme.
I have since switched to the Light color scheme, for which I received 10 further Contrast errors
I have not yet tried the 6 other core admin color schemes.
I suspect these additional problems would be better addressed in follow up TRACs.

[bobbingwide]

WAVE Color Contrast Errors on wp-admin

[bobbingwide]

Low color contrast for vertical bar separators

[bobbingwide]

Low color contrast for vertical bar separators in Recent Comments

[joedolson]

Note - I'm changing the ticket summary, as none of these errors are in fact WCAG errors. They are tool reports, but not actually errors.

The events widget part of this has been discussed extensively in #63447.

[bobbingwide]

Low color contrast for vertical bar separators in view more comments

[bobbingwide]

10 Color Contrast errors with Light Administration Color Scheme on wp-admin

[joedolson]

@bobbingwide FYI, it is not core policy to maintain color contrast accessibility outside of the default theme. All other themes are optional, and we do not attempt to keep them compatible with WCAG guidelines.

[bobbingwide]

Note - I'm changing the ticket summary, as none of these errors are in fact WCAG errors. They are tool reports, but not actually errors.

@joedolson

Can you explain to me, and any other reader who is not well versed in WCAG, why these errors, as reported by WAVE, are not actually WCAG errors?

Can you explain why the WordPress accessibility team would not want to "fix" these problems anyway?

thanks in advance

[joedolson]

@bobbingwide All of the items you've cited are graphics. The 4.5:1 color contrast guideline is for text, not for graphics. That rule is defined under WCAG 1.4.3.

Non-text contrast is defined under WCAG 1.4.11, and requires a contrast of 3.0:1, which these do not fail.

It's always important to recognize that most tools are designed to flag possible WCAG failures, and an error from a tool is not necessarily an actual WCAG failure.

There's nothing about this that means that the accessibility team wouldn't want to fix these issues; higher contrast is *usually* beneficial (although not always.) Updating the ticket summary is about accuracy: these are not WCAG failures, so for prioritization, there are other concerns.

I'll not that WordPress 7.0 is intended to ship with a design refresh: all colors will be shifting to use the design language of the block editor, so this is likely to be irrelevant, anyway. See #64308.

[bobbingwide]

@joedolson Thanks for that. having read the following documents

​https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
​https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html

I now have a better understanding of your argument

In the generated HTML, WAVE was generating a false positive for the purely decorative separator character "|", which had a foreground color of #a7aaad and background #f6f7f7.
Contrast ratio: 2.17:1

It was treating the "|" as text, not graphics.

But I still have a problem that I'd like to see resolved.

• I'm trying to test the accessibility of my plugins in the WordPress admin.
• I'd rather not see a load of Contrast Errors which I have to wade through to determine if they're false positives each time I run a WAVE test.
• I see 3 ways to deal with this

1. Improve the automated tools to better deal with the Incidental exceptions.
2. Change WordPress core to prevent the tools from reporting false positive.
3. Implement local workaround for known false positives.

3. Is under my control, 2. Yours, 1. WebAIM's

IMO, I feel it would be better addressed in WordPress Core as this will be of direct benefit to all WordPress developers using WAVE. Looks like #64308's already making progress in this area.

[joedolson]

I'm milestoning this for 7.0, but for now, I suggest that nobody create a patch for it. As the changes develop for #64308, it makes the most sense to resolve this within the scope of the major admin redesign. If that doesn't develop fast enough and it becomes evident it won't make 7.0, then we can do this specifically for this ticket.

It doesn't hurt to address these issues, and there are a number of possible approaches.

I want to note that the goal isn't necessarily to change the contrast, it's to eliminate the false positives. That can be resolved by increasing contrast, but can also be resolved by implementing these in a way that isn't flagged as textual by automation.

While these colors don't technically violate WCAG, because the contexts they are in don't contain text, they do raise chronic errors in automated testing. The darker colors are more consistent with the new admin scheme, and resolve errors, making testing easier.

Trac ticket: https://core.trac.wordpress.org/ticket/64313

## Use of AI Tools

[joedolson]

I'm going to commit this. Even if it gets reverted, honestly it will save me a ton of time during testing of the admin reskin, since checking for color contrast reversions won't have all the false positives.

Will add screenshots first.

[joedolson]

Events & News footer - before

[joedolson]

Post row actions before

[joedolson]

Pinning this to version 3.8, when mp6 was merged. There may have been comparable problems previously, but if so they were on a significantly different UI.

[joedolson]

Events & News footer - after

[joedolson]

Post row actions after

[joedolson]

In 61763:

Admin: A11y: Update separator colors.

Update the base color for text in row actions, dashboard widget footers, and similar contexts to meet WCAG color standards.

Props bobbingwide, joedolson.
Fixes #64313.