search

angular / components

Component infrastructure and Material Design components for Angular
https://material.angular.io
MIT License
24.36k stars 6.74k forks source link

Fix disabled-text scss styling to meet a11y standards #14013

Open josephperrott opened 5 years ago

josephperrott commented 5 years ago

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

Replace disabled text usage to new shared constant:

jelbourn commented 4 years ago

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

josephperrott commented 4 years ago

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 commented 3 years ago

For inputs now I see

Taking a look...

Splaktar commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

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

jelbourn commented 3 years ago

Yep, that sounds right.

amysorto commented 5 months ago

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