Claro: Form labels that are disabled have too low color contrast

The label is this color because of the .is-disabled CSS class on it. Updating the issue summary.

I somewhat recall having a discussion in the Olivero issue queue where it is okay to have disabled text not meet contrast criteria... but I'm not 100% sure.

I'm going to cross post this in the Drupal Slack #accessibility channel for feedback

https://drupal.slack.com/archives/C2ANFUGGG/p1649851821588239

I commented this on the duplicated issue #3266760: Greyed out authenticated user role in user profile has a too low color contrast:
The element .form-item__label.is-disabled is using the variable --input--disabled-fg-color. It is defined in the variables.pcss.css file on line 104 as --input--disabled-fg-color: var(--color-gray-600). Instead of --color-gray-600 it should be using --color-gray-700, with a contrast ratio of 4.53. It'll solve this existing problem in all disabled labels.

That issue can be addressed here, changing the color for all elements involved.

Bringing some comments from Slack:

@Mike Mai:

general question. why have disabled form elements at all? if certain feature is locked down, isn’t it pure information at that point?

@mherchel:

IMHO, its still valuable because it does convey information. The info that it conveys are "You are in the correct area of the admin interface (you don't have to look around futher). But... something's still not right and we can't make a change"

@Mike Mai:

fair point, i do believe there’s a different way of design to convey that without making the element completely illegible for some people.

@ckrina:

Should just the label change, or all the elements should respect the4.5:1 ratio? Like the select value in the issue image example “Image”, or the description. From your comments I assume all or them, but not sure

@Mike Mai:

this is me speaking out of context of your design guidelines and design system, so forgive me: for the <label> it really has no reason to visually make it disabled, it is not disabled itself. for the <select>, i do understand using the disabled attribute for the points above, however, visually it can be done differently. for example, use a lock icon (or another appropriate icon) along with the select element, then use the same icon in front of the helper text right below the select element to make the connection. i don’t believe dimming the entire select element to fall below 4.5:1 is a good approach.

We discussed this during the weekly Claro meeting. Here is the thread: https://drupal.slack.com/archives/C2ANFUGGG/p1649851821588239

@andrewmacpherson added this feedback:

In terms of must-have vs should-have, I'd like to treat the separately from the labels and descriptions.
For the disabled inputs, they have an explicit WCAG exemption, so it's a could-have.
I'm leaning towards must-have for the labels and descriptions contrast. These are rather crucial to read and understand. IMO these don't explicitly fall under the "incidental" WCAG exemption.

So I would suggest next steps are, based on @andrewmacpherson and @mikemai2awesome feedback:

1. Change grays for disabled labels and descriptions here to --color-gray-700, that complies with the 4.5:1 contrast requirement.
2. Open follow-up to find a design solution that gets a contrast of 3:1 for inputs.
3. Open follow-up to find a design solution that communicates when a field is disabled. Maybe using a visual clue or rethink if the info needs to look like a disabled input or another way that gives enough info on why it can't be changed.

Pushed change to disabled colour

Fixed CI error.

I tried to test this in SimplyTest.me but couldn't seem to get the patch to apply there. Not sure if its just too long since I did this, or if there is another bug in SimplyTest.me.

Wanted to raise this related issue:

Title: WCAG 1.4.3: Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds (em)
Tags: Accessibility, WCAG 1.4.3, color-contrast

Issue: Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds (color-contrast - https://accessibilityinsights.io/info-examples/web/color-contrast)

Target application: Edit Image | Drush Site-Install - https://master-5cugo26zvm3mikgfxjfznly18jm9g8jb.tugboatqa.com/admin/stru...

Element path: #edit-source--description > em

Snippet: The media source cannot be changed after the media type is created.

How to fix:
Fix any of the following:
Element has insufficient color contrast of 3.78 (foreground color: #828388, background color: #ffffff, font size: 9.5pt (12.64px), font weight: normal). Expected contrast ratio of 4.5:1

Environment: Microsoft Edge version 105.0.1343.50

====

This accessibility issue was found using Accessibility Insights for Web 2.34.1 (axe-core 4.4.1), a tool that helps find and fix accessibility issues. Get more information & download this tool at http://aka.ms/AccessibilityInsights.

So this is how I tested

Drupal 9.5 standard install
Making claro my default theme
Using https://www.drupal.org/project/examples
Ajax submodule specifically
Went to examples/ajax-example/dependent-dropdown
Using color contrast analyzer verified the failure.
Applied MR
Verified color contrast now passes.

Tagging for WCAG 1.4.3

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

This actually appears to have already been fixed. If anyone can confirm we can close this out.

Color contrast is changed and updated after applying MR on 9.5x but it not getting applied to the D10.0.x it still shows old color contrast as color: #828388. i think it needs to be updated..

Patch #13, no longer applies to 10.1.x. I have provided updated patch for same. please review

#22 applied successfully, attaching the screenshot of what I see on 10.1.0-dev

Using a contrast tool the label passes but not the field.

After patch

Here is the results from contrast tool.

Believe this is good

Committed and pushed e8298e81ba to 11.x and 22b06e0042 to 11.0.x and 8e344072b3 to 10.4.x and 271a556170 to 10.3.x. Thanks!