[TextField] Make filled variant background / hover / focus states lighter

[jgoux]

• This is not a v0.x issue.
• I have searched the issues of this repository and believe that this is not a duplicate.

Hello,

I find the new filled variant TextField's background too dark.

How were the different rgba values picked? (https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/FilledInput/FilledInput.js#L17)

I tried using a tool to calculate contrast ratio between the main background and the filled background on material design example and here are the difference between material-design examples and material-ui for each states :

State	Material Design Spec	Material-UI
Inactive	1.22	1.21
Activated	1.22	1.51
Focused	1.62	1.51
Hover	1.34	1.34
Error	1.22	1.51
Disabled	1.38	1.38

These numbers are based on a light theme.

We can see that according to the specs, there is a difference between the focused state and the activated state in term of background color (the activated one is the same color as the inactive one, which is lighter than the focused one). You can see the different states here, at the "States" section.

I suppose we should at least respect the "activated" state background color, so the contrast is better when typing.

[oliviertassinari]

I find the new filled variant TextField's background too dark.

@jgoux Same feeling.

[mbrookes]

@jgoux What's the distinction between focused and activated in Material-UI?

We chose the one from the spec that distinguished focused from inactive and hover. (Going back to the inactive color when focused didn't seem right, but I could be convinced otherwise). I agree it could be a little lighter, as your testing shows.

Regarding error, at the moment it follows the same background color for inactive / hover / focus whether error or not.

[jgoux]

@mbrookes I don't think it's possible to style a focused input differently based on :focus and :activate so in our case the focused state would be hard to implement (or we would have to capture the focus on a outer element so the "activated state" doesn't trigger, and then on keyboard event starts the real focus on the input so the user can actually type).

In my opinion we should go for the "activated" state with a lighter background. The bottom line being bolder and the colors are enough to denote the state.

[oliviertassinari]

In my opinion we should go for the "activated" state with a lighter background.

@jgoux I agree so is Vuetify doing. I think that we can leave the focused state aside here. I don't really see the use case yet. It's to be noted that MCW doesn't follow the specification for the activated state.
Here is what I have using HSL:

State	Material Design Spec	Material-UI
Inactive	91%	91%
Activated	91%	82%
Focused
Hover	87%	87%
Error	91%	91%
Disabled	88%	86%

So, there are only two value to change, and we are good:

• https://github.com/mui-org/material-ui/blob/a59903abde3925dd239a89a4d02a6c7020236302/packages/material-ui/src/FilledInput/FilledInput.js#L27-L28

-backgroundColor: light ? 'rgba(0, 0, 0, 0.18)' : 'rgba(255, 255, 255, 0.18)', 
+backgroundColor: light ? 'rgba(0, 0, 0, 0.09)' : 'rgba(255, 255, 255, 0.09)',

• https://github.com/mui-org/material-ui/blob/a59903abde3925dd239a89a4d02a6c7020236302/packages/material-ui/src/FilledInput/FilledInput.js#L30-L31

-backgroundColor: light ? 'rgba(0, 0, 0, 0.14)' : 'rgba(255, 255, 255, 0.14)',
+backgroundColor: light ? 'rgba(0, 0, 0, 0.12)' : 'rgba(255, 255, 255, 0.12)',

[mbrookes]

@jgoux Looks like my comment was accidentally marked as off topic, but yes, that was my point - there is no distinction between activated and focused in Material-UI.

In my opinion we should go for the "activated" state with a lighter background. The bottom line being bolder and the colors are enough to denote the state.

👍

[adeelibr]

Can I work on this guys? :)

[oliviertassinari]

@adeelibr Sure :)

[fzaninotto]

Sorry to revive an old topic, but it seems the default background is still too dark as compared to the material design specs.

Spec: #f5f5f5

mui implementation (on white background): #e8e8e8

It's not obvious at first because the FilledInput demos are using a darker background.

[fzaninotto]

Also, it seems that Google has deprecated the default variant, because the spec shows only the filled and outlined variants.

https://material.io/components/text-fields/#

[mbrookes]

it seems the default background is still too dark as compared to the material design specs

That isn't the spec, it's the MCW implementation of it, which differs from the spec. (Which is not to say that we couldn't follow it if it is superior.)

That playground is something I've been meaning to look into though, as the current wall of Textfields is rather unappealing,

it seems that Google has deprecated the default variant

Yes:

https://material-ui.com/components/text-fields/#textfield

Note: This version of the text field is no longer documented in the Material Design guidelines, but Material-UI will continue to support it.

[oliviertassinari]

That playground is something I've been meaning to look into though, as the current wall of Textfields is rather unappealing,

Notice that @joshwooding was working on this very problem recently.

That isn't the spec, it's the MCW implementation of it, which differs from the spec. (Which is not to say that we couldn't follow it if it is superior.)

I have a call with the Material Design team next tuesday, I can ask about the recommended color.

[mbrookes]

@joshwooding was working on this very problem recently.

Ah yes, perfect.

[oliviertassinari]

The Material Design Team recommends going with the MCW version. But waiting for a final answer.

[fzaninotto]

That would be fortunate, because I don't think there is a way to override the MuiFilledInput background color for both the light and dark palettes using a custom theme.

[oliviertassinari]

Bad news, I had a confirmation that we should stick with the spec, not MCW. Oh, I might have an idea for this problem. Are you using the CssBaseline component? What if the component was applying a global class name to the body depending on the light/dark mode value? Alternatively, global theme overrides support style functions (but might be a bit slower until we take the time to speed it up).

[mbrookes]

I had a confirmation that we should stick with the spec

Well that won't work either, since the spec doesn't have a differentiated color for focused / active, which is why we went with what we have now.

[tcx]

it seems the default background is still too dark as compared to the material design specs

That isn't the spec, it's the MCW implementation of it, which differs from the spec. (Which is not to say that we couldn't follow it if it is superior.)

Sorry for asking a dumb question, but does it mean that:

• The filled text fields from the spec don’t pass a11y contrast tests?
• The filled text fields from MCW has a background color lighter than the spec in order to pass a11y contrast tests?

MUI is doing really well regarding a11y compared to other component libraries, and the fact that the default filled text fields don’t pass a11y contrast tests is a pity.

Should it be something to add to the a11y section of the docs, ideally with a recommended way of overriding the background color?

[oliviertassinari]

@tcx What problem are you trying to solve?

[tcx]

@tcx What problem are you trying to solve?

@oliviertassinari I'd like to get an accessibility score of 100 on Lighthouse, but fail to do so due to the fact that the filled textfields don't pass contrast requirements:

Using the outlined version is not an option due to some design reasons.

I'm not sure how to tweak MUI to change the background of the filled text fields, so I think it would be great to warn users about the contrast issue and have a workaround documented.

[tcx]

Actually I was wrong, the background is the same between MUI and the spec.
However, it seems that the text is lighter in MUI than in the spec.
Therefore, I think that the spec is accessible, but MUI is not because of a too light text.

Taking the first image from here: https://material.io/components/text-fields
and pasting next to it a screenshot from: https://next.material-ui.com/components/text-fields/
shows the difference:

[oliviertassinari]

@tcx Ok, I would propose the following (In case you want to work on it, all 🟢):

1. Update the secondary text color to match the update of the spec:

https://material.io/design/color/text-legibility.html#text-backgrounds

Medium-emphasis text and hint text have opacities of 60%

It will also help with @eps1lon's concern around differentiating disabled from secondary:

diff --git a/packages/material-ui/src/styles/createPalette.js b/packages/material-ui/src/styles/createPalette.js
index 1a8e17b707..d827ab21bc 100644
--- a/packages/material-ui/src/styles/createPalette.js
+++ b/packages/material-ui/src/styles/createPalette.js
@@ -16,7 +16,7 @@ export const light = {
     // The most important text.
     primary: 'rgba(0, 0, 0, 0.87)',
     // Secondary text.
-    secondary: 'rgba(0, 0, 0, 0.54)',
+    secondary: 'rgba(0, 0, 0, 0.6)',
     // Disabled text have even lower visual prominence.
     disabled: 'rgba(0, 0, 0, 0.38)',
   },

It also solves our contrast ratio issue.

2. We reduce the opacity of the filled background, it's simply ugly cc @mbrookes. It looks like the field is disabled.

diff --git a/packages/material-ui/src/FilledInput/FilledInput.js b/packages/material-ui/src/FilledInput/FilledInput.js
index 8d52f09140..1796dcc353 100644
--- a/packages/material-ui/src/FilledInput/FilledInput.js
+++ b/packages/material-ui/src/FilledInput/FilledInput.js
@@ -37,7 +37,7 @@ const FilledInputRoot = experimentalStyled(
 )(({ theme, styleProps }) => {
   const light = theme.palette.mode === 'light';
   const bottomLineColor = light ? 'rgba(0, 0, 0, 0.42)' : 'rgba(255, 255, 255, 0.7)';
-  const backgroundColor = light ? 'rgba(0, 0, 0, 0.09)' : 'rgba(255, 255, 255, 0.09)';
+  const backgroundColor = light ? 'rgba(0, 0, 0, 0.06)' : 'rgba(255, 255, 255, 0.09)';
   return {
     /* Styles applied to the root element. */
     position: 'relative',
@@ -49,14 +49,14 @@ const FilledInputRoot = experimentalStyled(
       easing: theme.transitions.easing.easeOut,
     }),
     '&:hover': {
-      backgroundColor: light ? 'rgba(0, 0, 0, 0.13)' : 'rgba(255, 255, 255, 0.13)',
+      backgroundColor: light ? 'rgba(0, 0, 0, 0.09)' : 'rgba(255, 255, 255, 0.13)',
       // Reset on touch devices, it doesn't add specificity
       '@media (hover: none)': {
         backgroundColor,
       },
     },
     '&.Mui-focused': {
-      backgroundColor: light ? 'rgba(0, 0, 0, 0.09)' : 'rgba(255, 255, 255, 0.09)',
+      backgroundColor,
     },
     '&.Mui-disabled': {
       backgroundColor: light ? 'rgba(0, 0, 0, 0.12)' : 'rgba(255, 255, 255, 0.12)',

It still reaches AA:

[eps1lon]

Olivier could you re-open this as a new issue. The original description is just way too outdated and so is the conversation surrounding it.

[eps1lon]

Restored the original issue so that we don't rewrite history. Please open a new issue and fill out the template

[oliviertassinari]

Ok

[oliviertassinari]

@tcx Could you open a new issue that describes the a11y issue we have on the latest version? This one has been closed for more than 2 years.

[tcx]

Sorry for hijacking an old issue, in retrospect it wasn't the right way to ask my question.
I created #24947.

[oliviertassinari]

@tcx Thanks, Sebastian was right, much cleaner now :)