[material-ui][Text Field] Label transformation issue with font size change

[vednro]

Steps to reproduce

Link to live example: Disclosure not possible due to data protection guidelines

Steps:

1. Setup only the minimum required packages (react, mui, emotion, I use vite)
2. Implement the TextField component, specify a value and a label
3. Change the font-size in the browser settings to, for example, 72

Current behavior

When the font size in the browser is changed, the TextField's Label does not transform correctly. It appears to be using pixels for sizes, leading to issues with responsiveness see attached image.

Expected behavior

The TextField's Label should transform appropriately when the font size in the browser is changed. It should be responsive and adapt to different font sizes.

Context

I am trying to create a responsive user interface, and the issue with TextField's Label transformation is affecting the overall layout and user experience. This component is used in many places for maintain the personal and business related profile.

Your environment

npx @mui/envinfo

``` Using Google Chrome Version 121.0.6167.85 (Offizieller Build) (64-Bit) System: OS: Windows 10 10.0.19045 Binaries: Node: 20.10.0 - C:\Program Files\nodejs\node.EXE npm: 10.2.3 - C:\Program Files\nodejs\npm.CMD pnpm: Not Found Browsers: Chrome: Not Found Edge: Chromium (120.0.2210.144) npmPackages: @emotion/react: ^11.11.3 => 11.11.3 @emotion/styled: ^11.11.0 => 11.11.0 @mui/base: 5.0.0-beta.33 @mui/core-downloads-tracker: 5.15.6 @mui/material: ^5.15.6 => 5.15.6 @mui/private-theming: 5.15.6 @mui/styled-engine: 5.15.6 @mui/system: 5.15.6 @mui/types: 7.2.13 @mui/utils: 5.15.6 @types/react: ^18.2.43 => 18.2.48 react: ^18.2.0 => 18.2.0 react-dom: ^18.2.0 => 18.2.0 typescript: ^5.2.2 => 5.3.3 ```

Search keywords: textfield, label, fontsize, transform, pixel, chrome

[DiegoAndai]

Hey @NiklasVeda, thanks for the report.

I can confirm the behavior. It behaves good enough up until the font size is ~30:

After that, we get collisions, and at 72, it looks bad

The questions would be:

• What should be the behavior
• Up to what size do we need to support? Is 72 too much? Up to 72? More than 72?

What do you think @zanivan @danilo-leal?

[mohamedsaiedd]

@NiklasVeda , is it a valid case to change the browser font-size to a large value like 72? I think even in large monitors the 72px font size will break the whole design not only the input fields.

[vednro]

Hello @mohamedsaiedd, thanks for reaching out so quickly. Changing the browser font size to 72 is valid for accessibility reasons, particularly benefiting visually impaired users, adhering to accessibility guidelines, accommodating an aging population, and addressing user preferences. The browser, such as Firefox and Chrome, specify 72 as the maximum value and we would like to support this because of the things mentioned above.

[zanivan]

Hi there!

Thanks for the report @NiklasVeda, good to see people worried about a11y 🙌

However, I believe 72 might be too big for this purpose. Chrome's 'very large' font size is 24px, and it's the same max size that's offered in safari. Also, for WCAG a large text size is considered 18 points, what can typically be translated to 24px.
WCAG also tells us that we should optimize for the 200% zoom in the page, meaning that up to 48px it must be working perfectly.

So, I would set the supported max size as 24px (set by browser) + 200% zoom—unless we find some specific a11y guideline stating something else.

[DiegoAndai]

Here's a quick audit:

1. font-size: 24px

2. font-size: 48px

3. font-size: 24px + 200% zoom

I would say font-size 48px is the only one that looks bad. It's important to note that font-size 24px + 200% zoom didn't turn out the same as 48px, as the former scales everything and the latter only the font.

So, we're covered if the goal is to optimize for 24px + 200% zoom. If the goal is to optimize for 48px, we must fix it.

@zanivan

[zanivan]

Having it optimized for 24px + 200% zoom should be enough—and then we keep monitoring the a11y guidelines just in case.

[vednro]

Hey everyone,

Thanks for the lively discussion. Understanding SC 1.4.4: Resize Text (Level AA) As I understand it, with a base of 16px and a scaling of 200%, we have a final value of 32px. I think that the value 200 does not only refer to the zoom but also to the scaling of the font size itself.

[zanivan]

Hey @NiklasVeda, I think I've expressed myself poorly previously with the 48px example, so apologies for that. text scaling and page zooming are two different things. The text scaling is when you change the default font size, like changing it from the default 16px to “very large” 24px. This will mainly affect rem declarations, since it's a relative unit. The zoom will affect everything except the viewport units. This article is very good to explain the best use case for each unit 😄

[vednro]

Thanks @zanivan Exactly. The linked WCAG Success Criterion 1.4.4 refers to text scaling. To meet this success criterion, it's mandatory to support text scaling of up to 200%. (Above 200%, the working group recommends page zoom instead of text resizing.)

[DiegoAndai]

I'm closing this as we're optimizing for 24px + 200% zoom, which currently works. Thanks for the discussion 🙌🏼.