Accessibility in browsers: zoom level vs. font size

question.md

Scroll to the bottom for the answer

Question

There's two ways to increase the default font size in browsers:

1. set a default zoom level > 100% ("page zooming")
2. set a default font size > 16px ("text scaling")

Option 1 relies on the browser's proportional scaling. This feature was implemented in all major browsers years ago. I believe it works especially well on responsive websites: since it makes "CSS pixels" bigger, the viewport becomes smaller in "CSS pixels" and the appropriate media queries trigger.

Option 2 only works on websites that define font sizes and perhaps other sizes in relative units: historically em and more recently rem. (It turned out that the "cascading" part of CSS was rather hard to control; now it's all about isolating components; rem makes it possible.)

It's been possible since the advent of CSS to create layouts that scale with the user's default font size. All it requires is to express all lengths in relative units, except perhaps media queries: one could argue that they should remain tied to physical dimensions of devices. (This isn't the question here.)

However very few non-trival websites got this right. I assume that's why browsers decided to handle it themselves and implemented proportional scaling.

The UIs of current browsers favor page zooming: it's a discoverable keyboard shortcut, while text scaling is buried in the settings. Considering that page zooming usually works better, that choice makes sense.

A use case I can imagine for text scaling is to increase the font size on websites that predate responsive design and hardcode a width of 960px. Proportional scaling on a small screen would cause horizontal scrolling.

For a modern, responsive website, I'm failing to imagine drawbacks of defining everything in px. (Let's be honest, it's much more convenient.) However I'm still hearing arguments that it's important to support text scaling i.e. keep fonts proportional to the user's default font-size.

My questions, in the context of a modern, responsive website:

1. Does someone who sets their default font size to 32px expect a different result from setting their default zoom level to 200%?

2. If they do, what result do they expect? (If I'm putting effort into this, better make it useful.)

3. If they don't, do they have a reason not to use the zoom level? (Ideally I'd do everything in px, focus my efforts on proper responsive rendering at any scale, and let users zoom with the browser's zoom controls as needed.)

Answer

The requirements for web content text resizing are laid out in the success criterion 1.4.4 Resize text of WCAG 2.0.

There was an debate about whether this criterion required to support text scaling in addition to page zooming. The Working Group clarified that it's mostly about avoiding overflows. They added the following note:

The Working Group has discovered many misunderstandings about how to test this failure. We are planning to revise this failure in a future update. Until then, if the content passes the success criterion using any of the listed sufficient techniques, then it does not meet this failure.

The listed sufficient techniques include page zooming. Since it's widely available in modern browsers, I believe it's sufficient to meet this criterion.

However note that advisory techniques include:

• Avoiding scaling font sizes smaller than the user-agent default (future link)
  • Note: The author won't actually know the font size, but should avoid percentage scaling that results in less than 100%

Enforcing a font-size of 16px will infrige this advice for users that have a default font-size larger than 16px.

To meet this advisory technique, all px dimensions could be converted to rem with 16px => 1rem; this could be automated.

Credits

Thanks @kemar for providing pointers to the answer.

@josh7weaver, I just came across this as well. It seems like supporting zoom is sufficient to meet accessibility criteria, but there are several incorrect pieces of information above:

Media query units should be relative, so that containers are not defined in pixels and text breaks out of them or gets truncated when zoomed in.

And Chrome does, in fact, still have a text size setting under settings. The text size tool has no effect if you set your base font size in pixels.

I have a severe astigmatism as well as neurological issues.

I need to specify my own fonts and font sizes to read text. I can't rely on scaling, because:

• I have trouble reading certain fonts, especially on computer screens, and

• If I make the small text a good readable size, I may end up making large text unreadably large.

• And if this uses page zooming, then sometimes the whole page is unusably large.

Supporting zoom may be sufficient to meet accessibility criterea, but accessibility criterea are not enough for universal accessibility. Many of the tolerate inaccessible and/or actually harmful practices because it'd be too much of a fight to require accessible and non-harmful ones.

Some interesting results from a 2018 survey on how people use assistive tech: https://webaim.org/projects/lowvisionsurvey2/

Have discovered this a bit late, is this still applicable?

Are there some resources which explain how different browsers treat zoom? I have been seeing inconsistencies in zooming between safari and chrome

As far as i know the only issue is with safari, which doesn't scale VW and VH units when zoomed in/out... If all your units are in rem, then you could detect the zoom level using js and set the calculated fontSize to html directly and everything will scale accordingly.

If you know any old people (with poor vision, who know about text scaling setting) using iPhones, all ui text across the whole os becomes larger.

This is the exact behavior we want

Discover.com actually has a little button exposed in their ui to adjust text scaling. I really like this approach, but it’s unclear how that feature should interact with the browser/os text scaling setting.

mobile safari has a readily available page zoom setting though, even though cmd/ctrl + us not available