Skip to content

Instantly share code, notes, and snippets.

Last active January 4, 2023 05:04
Show Gist options
  • Save aaugustin/d6351f12f4604d3343ee5ecf691b3918 to your computer and use it in GitHub Desktop.
Save aaugustin/d6351f12f4604d3343ee5ecf691b3918 to your computer and use it in GitHub Desktop.
Accessibility in browsers: zoom level vs. font size

Scroll to the bottom for the answer


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.)


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.


Thanks @kemar for providing pointers to the answer.

Copy link

mlorant commented Oct 10, 2016

I would expect the same result between 16 -> 32px and 200 %. I don't see the utility of the px settings except that it allows you to set a mininal size for all pages while the percentage seems to be set for a specific tab during the session (I did not find the appropriate setting in Firefox, except using an add-on...).
So I do think some visually impaired people may use for simplicity's sake. I guess it should be test against it too, but that's my two cents :-)

I'm wondering if we can get stats somewhere (from Firefox anonymous reports for example) about how many people uses the "minimum pixel size" setting...

Copy link

Minimum pixel size is a slightly different issue. It just sets a lower bound on the text size that the browser will try to render, at the cost of messing up the layout in some cases. It works regardless of how the CSS is written.

Copy link

Changing the default zoom level in Firefox seems to require an addon at this time. Whoa.

Copy link

kemar commented Oct 10, 2016

I'm afraid there is no easy answer. If you have some time, you could dig into the WAI Resources.

In the meantime, you might like this: Text resizing: Why page zoom is not good enough - or is it? (lots of good links, talking about responsive, mobile browsing experience, reader mode etc.)

Personally I made my choice, I just use pixels. And I've been doing it for more than 10 years now.

Also note that text-only zoom has been removed from Chrome and that the feature is less and less easy to find in Safari.

Copy link

I'm finding this gist 3 years later... Has the authors opinions changed? Any new things to consider?

Copy link

@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.

Copy link

MarjaE2 commented Apr 9, 2019

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.

Copy link

Some interesting results from a 2018 survey on how people use assistive tech:

Copy link

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

Copy link

hjujah commented Dec 8, 2021

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.

Copy link

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 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment