Default Colors and WCAG

[c0debabe]

Using the default colors in the v6 alpha, I am finding that not all the color ratios pass WCAG AA.

Would it be helpful if I opened issues and/or pull requests for the items that do not pass with default colors?

[julien-deramond]

Thanks for checking the v6 alpha colors against WCAG AA, and yes, issues are welcome.

To keep them easy to act on, please open one issue per failing combination (or per component if several share the same cause) and include:

• the foreground and background colors involved (token or CSS variable name and value), and whether it is light or dark mode;
• where it shows up (component, state such as hover or disabled, docs page);
• the measured ratio, the tool you used and which AA threshold applies (4.5:1 for text, 3:1 for large text and UI components).

Please hold off on pull requests until we have agreed on the fix in the issue: the default palette is a design choice, and the right change can be a different token value, a different pairing or a change to the color-contrast() logic, depending on the case. Issues that were already filed, such as #38480 for border contrast, are worth linking rather than duplicating.

[ItsBexy]

I would say the core issue is the way all of the raw theme palettes are generated in the first place; the base color is assigned as --{color}-500 (regardless of how light or dark that color actually is), and the rest of the scale is created by mixing with black or white in oklch. This makes the actual luminance of a given color impossible to predict, which in turn means you end up with unreliable contrast ratios in generated theme palettes.

In order to control for dependable contrast, the color palette stops would need to be set to fixed luminance values, so that you always know what luminance you're getting whenever you select --blue-500, --red-700, etc. Without that being the case, all bets are off when it comes to generating themes that dependably pass contrast checks.