Fix disabled-text scss styling to meet a11y standards

[josephperrott]

disabled-text usage should be replaced to meet accessibility contrast requirements

Replace disabled text usage to new shared constant:

• [ ] badge
• [ ] datepicker
• [ ] form field
• [ ] input
• [ ] select
• [ ] stepper
• [ ] tabs

[jelbourn]

@josephperrott do you remember at all what prompted this issue? Did we get a report about the contrast being poor?

[josephperrott]

I discovered the issue while performing aXe tests across the codebase. The disabled-text check failed in its usages here.

If I remember correctly, we determined that for many of these we would need to consult with the Material team to determine if it was a spec issue or something in our implementation.

[Splaktar]

For inputs now I see

• a 4.57:1 contrast ratio on disabled text in dark mode. This is okay.
• a 2.66:1 contrast ratio on disabled text in light mode. This is failing.

Taking a look...

[Splaktar]

What are the latest thoughts on disabled-text styles (light and dark) not meeting a11y contrast guidelines? https://github.com/angular/components/blob/40ceda28fd4c8477a368e4631e3eaf945cb99106/src/material/core/theming/_palette.scss#L29-L36

This issue doesn’t have much detail, but seems to hint at there being a need to change the opacity value for these disabled-text styles. It seems like the short term workaround, was to change most things to just use secondary-text instead. But this has been in this state for about 3 years. Did we determine that this was too breaking, did we never get design feedback, or did we just not follow up on it until now?

We could

1. Update the disabled-text opacities to be the same as those for secondary-text
2. We could change a lot of usages of disabled-text to secondary-text like in this PR.
3. Or we should change both secondary-text and disabled-text to new opacity values.

It seems like the spec doesn’t constrain us to a specific set of opacity values anymore? It only gives examples via some of their custom themes.

[Splaktar]

disabled-text is referenced 47 times in about 19 files (some of them _palette.scss) in src/material/, but src/material-experimental only refers to $dark-disabled-text once directly for use with the FormField w/ native select when using a dark theme. As mentioned in https://github.com/angular/components/pull/19232#discussion_r654753190 (with a screenshot), on macOS with the OS configured for dark mode (and Material using a dark mode), these styles are completely ignored for the native select dropdowns. So that style should have no impact on a11y in many (maybe all) cases.

Thus I think that this one is safe to mark as Fixed in MDC.

[jelbourn]

Also, WCAG states the following:

Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

So TL;DR disabled controls don't actually have a text contrast requirement. Personally I think this is not the best, but that's the standard today. If we can confirm that all of these cases are genuinely for inactive controls, that lowers the priority in my estimation (to P4).

@Splaktar I don't think this can be fully fixed in MDC, though, since we don't have (or plan to have) MDC versions of badge, datepicker, or stepper.

[Splaktar]

Okay, then we need to fix this in @angular/material for

• [ ] matBadge
• [ ] mat-datepicker
• [ ] mat-stepper

And verify that the following MDC-based components in @angular/material-experimental pass a11y contrast standards

• [ ] mdc-input
• [ ] mdc-select
• [ ] mdc-tabs

[jelbourn]

Yep, that sounds right.

[amysorto]

Looked quickly at a M3 select that uses the Azure and Blue light theme on the docs site. The disabled text has a contrast of 2.33:1. So removing the 'Fixed in MDC' label