bug(style): Custom palette's text hue not propagated to MDC styles

[benelliott]

Is this a regression?

• [X] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

14.x

Description

[Re-opening #26021 which was incorrectly closed as a duplicate of a similar but different issue]

[This is a regression insofar as the legacy non-MDC implementations do not have this problem]

Hi, after running the MDC schematic on one of my projects I have found that the MDC-based components do not use the $text hue specified in the theme config, which can cause accessibility issues for themes whose default hues do not provide sufficient contrast against a neutral background. In particular I have noticed this causes legibility issues for the floating placeholder on form fields and the label text on default-appearance buttons, but it might apply to other components as well.

My theme is configured as follows:

$my-palette: mat.define-palette($greens, 600, 200, 900, 700); Note that the $text hue is overridden to 700 in the call to define-palette.

Here is a screenshot showing the 700 hue being correctly applied to the aforementioned text elements under the legacy components:

And here is how the new MDC components look:

I had a hard time reading the Angular Material => MDC SCSS theming code but it seems like the $text hue preference isn't being passed to the MDC mixins in any way.

Reproduction

StackBlitz link: Steps to reproduce:

1. https://stackblitz.com/edit/components-issue-9ugktp?file=src%2Fstyles.scss
2. Note that text hue is set to 900 but text button and form field label use 500

Expected Behavior

MDC components should use specified text hue where applicable

Actual Behavior

MDC components used primary hue regardless

Environment

Environment Angular: 15.0.0-18.0.1 CDK/Material: 15.0.0-18.0.1 Browser(s): Chrome Operating System (e.g. Windows, macOS, Ubuntu): Windows 10

[benelliott]

This is not a duplicate of #26056, which was resolved by using palette contrast values where applicable instead of hardcoded #000 / #fff.

[benelliott]

Thanks @crisbeto for tagging - thought it might be worth noting that this affects a range of components including buttons and tabs as well as form fields. Maybe an issue can only be tagged under one area though.