[a11y] EUI does not respect user/browser default font sizes

[cee-chen]

This issue was discovered while implementing #7124, and when several EUI team members brought up recommending against px units as less accessible than rem and em.

Problem

By default, EUI sets a global pixel value font-size on html:

eui/src/global_styling/reset/global_styles.tsx

Line 42 in 3ab325b

font-size: ${`${font.scale[font.body.scale] * base}px`};

(Note: This value is unaffected by / does not respect the new defaultUnits token implemented in #7133).

What this means is that EUI does not respect user-set browser settings for default font sizes. Most browsers default this to 16px, but if a user wants a default font size of 32px (e.g. for vision issues), EUI will completely ignore that setting:

The above screenshot is of Firefox on MacOS, but this has also been reproduced and confirmed on Chrome as well.

Reproduction

• In your browser settings, change your browser default font size from 16px to any other value
• Go to https://eui.elastic.co and confirm that EUI does not adjust dynamically

For comparison, other websites that do respect custom user/browser font size:

• https://polaris.shopify.com/
• https://www.nytimes.com/

And other websites that also do not respect user/browser font size:

• https://fluent2.microsoft.design/
• https://github.com/
• https://www.google.com/

Proposed solution

To be clear, EUI has not respected the browser default font size since its inception (i.e., well before the Emotion conversion). To "fix"/change this now would potentially be a major breaking change for consumers or an unexpected surprise for users. If we want to change the default font size we set on html to be more accessible going forward, we need to make this choice very deliberately, and communicate that clearly to our consumers as well.

It might also be worth discussing the approach we want to take:

• Have the html font size respect the new defaultUnits token, which means potentially allowing consumers to deliberately choose to make their applications less accessible (does this have valid use-cases?)
• Have the html font size always be relative (e.g. using % instead) and ignore defaultUnits

WCAG or Vendor Guidance (optional)

• https://css-tricks.com/accessible-font-sizing-explained/

[cee-chen]

CCing in the folks who had opinions on this during our sync today: @1Copenut @kyrspl @mdefazio

I'll bring this up at our next week's meetings as well for more discussion if we'd rather wait until then, but wanted to start this thread now for async thoughts in the meanwhile.

One thing that I strongly think is worth discussing: big name tech companies like Google, GitHub, and Microsoft (see links in PR description) follow this same pattern of ignoring browser default font sizes. Is this an oversight or a deliberate decision? What do they know that we don't? Does a more consistent visual experience trump user customization in this case, especially since browser zooming already exists?

To be clear, I don't necessarily agree with the above questions, but I want them to at least be discussed.

[mdefazio]

I think I like this approach if i'm understanding the implications correctly.

Have the html font size respect the new defaultUnits token...

We would still have a default for this token and a font-size would still be assigned to the html tag, right? So EUI behaves the same out-of-the-box with this change? It's just a matter of possible (poor) customization?

...which means potentially allowing consumers to deliberately choose to make their applications less accessible (does this have valid use-cases?)

My gut reaction:

• If consumers want to purposely build in-accessible apps, I don't think we are able to concern ourselves with this.
• Would we do anything different if we were building EUI today? Would we follow the big tech companies?
• To what degree do we want EUI to be customizable? Are there other parts that we have 'locked down' that could justify not changing this?
• Are we concerned for future issues like "X component doesn't look right when browser font-size is set to 18px"
• And lastly, rather than assuming consumers will deliberately make less accessible apps, do we assume instead that there is good reason for them in doing so? Could this benefit some users?

[1Copenut]

I prefer the second option

Have the html font size always be relative (e.g. using % instead) and ignore defaultUnits
with a few qualifiers and caveats.

The new defaultUnits prop is incredible. It puts consumers squarely in control of their applications and how they're represented. It also means consumers are free to build less accessible applications. I am okay with this as a fact for a few reasons:

1. We lead by example. We've identified an issue and are making our design system and docs as good as they can be.
2. If users decide to use px as their preferred CSS unit, users can still use browser zoom to make text and layouts larger
3. As identified in the original issue, there are use cases for pixels that we couldn't anticipate, but have validity

Making our default html { font-size: 87.5%; } normalizes to 14px, but honors users' preferred font sizes across all browser tabs, not just a tab-specific zoom rate.

Now, with all that said, there's a very non-zero risk to making this change. It'll be a manual QA effort and should have a long public comment period so there's no surprises when we make the cutover.

[cee-chen]

We would still have a default for this token and a font-size would still be assigned to the html tag, right? So EUI behaves the same out-of-the-box with this change? It's just a matter of possible (poor) customization?

Yes, that's correct. With our current rem default unit, our html CSS would change from font-size: 14px to font-size: 0.875rem.

Making our default html { font-size: 87.5%; } normalizes to 14px, but honors users' preferred font sizes across all browser tabs, not just a tab-specific zoom rate.

Just to clarify, rem and em is responsive to default browser font size changes (the same way that % is), it's just a question of whether we want consumers to be able to specify px as well and make their app purposefully less accessible. Our new defaultUnits token essentially allows them to do that anyway, so it's just a question of making the html {} global CSS the same way.

[cee-chen]

Just realized I missed a couple of (really excellent) questions from Defazio:

Are we concerned for future issues like "X component doesn't look right when browser font-size is set to 18px"

I think the answer is broadly yes, but I also think the accessibility benefit of allowing users to tweak their default font size outweighs this concern.

To what degree do we want EUI to be customizable? Are there other parts that we have 'locked down' that could justify not changing this?

At this point we've already made px a specifiable unit (it's been in our types ever since the Emotion conversion, even though we don't use it internally), and it would be a breaking change to remove it. To be honest I don't think it would be worth it to do so. Consumers could go in and manually override every single one of our CSS selectors with their own font sizes and !importants anyway - at some point there is only so much control we have and we have to realize most of our value comes from sensible defaults and recommendations/warnings, but after that being overly restrictive does not benefit either us or the consumer.

And lastly, rather than assuming consumers will deliberately make less accessible apps, do we assume instead that there is good reason for them in doing so?

Yes - @y1j2x34 had a perfectly valid one in #7124. Their use-case is that they're using EUI for a browser extension, not a webpage. Their app renders on any website on the internet, which could be setting any font-size on the root html {}. They don't want their extension to inherit from random font sizes, and would prefer to use px for that reason.

For that use case, there literally isn't an accessible solution that respects browser default font sizes (because if the random website on the internet isn't using relative font sizes, neither does the extension). The only workaround the extension would have to make their font sizing more accessible would be to allow users to customize the app's base font size - which again, we can add a note and recommendation in our docs, but we can't do more than that.