Browser zoom unit for accessibility [css-values-and-units]

[scottkellum]

Currently all browsers scale the size of a pixel in order to zoom into a page by default. As a result, a zoomed in viewport is indistinguishable from a narrower viewport. This may result in unintended layout shifts as media queries are triggered as well as problems scaling responsive typography to be compatible with SC 1.4.4.

CSS authors need a way to identify zoom level so that we can create affordances for accessibility issues that may arise as a result of how zoom is currently implemented.

Two possible solutions:

1. A CSS keyword value that is effectively a unitless scale factor and can be used in calc functions.

h1 {
  font-size: calc(6vw * zoom);
}

2. Setting a standard for browsers to zoom the root font size instead of the size of a pixel. This will enable people to have finite control over what scales using relative units. Scale factor can be discovered with calc(1rem / 16px).
   Note: I don’t expect this to be an acceptable solution as the web has tried this and moved away from it to create a more consistent experience as many websites don’t use relative units.

[litherum]

Setting a standard for browsers to zoom the root font size instead of the size of a pixel.

Safari has a way to scale all text, if you hit option command plus.

We also have a way for authors to have the root font size scale in proportion to system accessibility text size, by using -apple-system-body on the root, and then using rems throughout the rest of their content. Also, any element that uses -apple-system-body will have its size adjust based on accessibility preferences.

[scottkellum]

@litherum Firefox has a setting where you can scale the font size as opposed to zooming as well. The issue is that when a user happens to use browser zooming, how might we as designers and CSS authors give that user an experience that is more intuitive and in line with their expectations?

[scottkellum]

-Apple-system-body is a good tip I will try out though! Still, when people zoom in/out on their browser I would love a solve for that.

[cookiecrook]

when people zoom in/out on their browser I would love a solve for that.

Typically when low viz users zoom in, they expect the content to stay the same, not adjust with the zoom ratio.

a zoomed in viewport is indistinguishable from a narrower viewport.

That’s sort of the point I think. I’m a little worried that adding a relative unit associated with zoom would give a misguided developer a way to hijack the zoom behavior. As proof, a lot of sites today break the default pinch-to-zoom with poorly implemented touch events.

Can you provide more detail about the use cases you want to solve for?

[cookiecrook]

Re: -apple-system-body, we don’t recommend this much anymore, since it’s non-standard, and both Mac and iOS Safari now implement their own site-specific font size adjustments… the “Aa” button in the location field.

However, if you want to see a body-element-relative implementation of -apple-system-body, there is one here: https://webkit.org/blog-files/prefers-reduced-motion/prm.htm Change the system font size via the iOS Control Center widget and reload the page.

Note: that file and related blog post were demoing a different feature: Reduced Motion. The fact that the flexible font sizes also work in the demo is just a hidden gem.

[scottkellum]

Thanks @cookiecrook

Typically when low viz users zoom in, they expect the content to stay the same, not adjust with the zoom ratio.

Maybe I’m misunderstanding you here but isn’t this expectation the opposite of what happens currently with browser zooming? This issue is aimed to resolve this disconnect between expectation and reality.

Here is an example that illustrates the issue particularly well. It uses the new qi units for font scaling so you’ll need Chrome Canary with the container query flag to view it.

• Without a zoom unit
• With a zoom unit (roughly implemented with JS and a CSS variable)

The reason why the text is set up to scale this way is to create a dynamic visual hierarchy on the page, but as zoom is changed the visual hierarchy changes also get triggered. This is a common problem with scaling text by any means, particularly responsively with viewport units, and will become more egregious as we deal with the more complex design space that container queries occupy.

[WestonThayer]

Attaching some visuals from @scottkellum's samples since that's what helped the issue "click" for me:

Desktop design	Mobile design
Visual design intent is read the big headline first, content next.	Visual design intent is more content-first.

Now let's compare the desktop design at 100% zoom vs. 500% zoom:

100%	500%

The <h1> is still quite large at 500%, but it was pretty weird watching it slowly shrink as I zoomed in. Given, all the other content on the page was getting larger, but I was focused on the headline (Scott called this an "optical illusion" that undermines your sense that zoom is working).

But if I had my default browser zoom set to 500% and landed on the page for the first time, all the type is still quite large, so as long as I could still read the headline, I probably wouldn't notice anything was off — unless I started to zoom out.

Without a zoom unit, it seems like we have 3 possible actions:

1. Keep the desktop/mobile design hierarchy change and leave the "zooming UX" as-is
   1. Violates WCAG 2.1 SC 1.1.4
   2. But assuming we've used rems, a user can still force the text to scale if they know where the browser setting is. Although there are some edge cases on mobile (imagine a similar hierarchy change between mobile/watch. Not many mobile browsers allow adjusting base font size)
2. Change the visual design so there isn't a hierarchy change and make sure the zooming UX grows the headline
3. Option (1), but revisiting whether SC 1.1.4 is mapping to a real user need. Affordance for oversized text in WCAG Success Criterion 1.4.4: Resize Text wcag3#261 suggests that text only needs to stay above a minimum visual size

@scottkellum do you know any sites in the wild that make a similar hierarchy swap? I just went through a bunch, but none had an extreme enough difference between big type on desktop / small type on mobile to cause this issue. Many have a headline shrink going from say 200% to 250%, but then it starts growing again, which seems way less awkward than the headline never growing.

[scottkellum]

Thanks @WestonThayer

These examples aren’t quite as dramatic as the demo above, but at higher zoom levels and smaller viewport sizes, the typographic hierarchies tend to flatten out. The difference is that in the example I shared this flattening of hierarchy happens fluidly every time the page is scaled. In the below examples, if these were fluid headlines, you would see the same effect with the headlines “Don’t be fooled: The Supreme Court’s Texas abortion decision is a big defeat for Roe v. Wade in Vox and “Chaotic footage captures violent melee at Atlantic City casino” in the NY Post.

Website	100% zoom level	200% zoom level
Vox
NYPost

[WestonThayer]

Thanks @scottkellum! I do think it's a notable difference from https://cdpn.io/scottkellum/debug/jOwmOZE that in both examples, continuing to 300/400/500% zoom does significantly scale the headlines (past their 100% size).

[cookiecrook]

Thanks for your patience in the explanation.

I wrote:

Typically when low viz users zoom in, they expect the content to stay the same, not adjust with the zoom ratio.

@scottkellum replied

Maybe I’m misunderstanding you here but isn’t this expectation the opposite of what happens currently with browser zooming?

There are a bunch of different types of "zoom." In native AT zoom, and web viewport pinch-to-zoom, also iOS's double-tap viewport zoom to text column, the user presumably does not want the layout to change at all. Your example of keyboard-hotkey-based zoom is has a discrete number of levels, so I'll refer to this as "discrete" zoom since I'm not aware of an official name.

As others noted above, Safari also has a "text-only" zoom that also has discrete incremental steps, but I don't believe that type of zoom is necessary to discuss further in this context. There may be 5th or 6th type of zoom I'm not recalling.

In regards to the primary discrete zoom, I read two concerns...

One of them is that the layout breaks in current release at large zoom levels, but I think (?) the linked example could be salvaged by adding an em-based min-width to the main layout container...

The second (probably the primary issue) viewable in Chrome Canary may be that the hierarchy changes as the [discrete] zoom level increases, such the difference between these two screen shots, only one zoom level apart.

Lower Zoom	Next Higher Zoom Level

Before responding further, does that capture the concern, or am I still off the mark? Thanks.

[scottkellum]

@cookiecrook Correct this is regarding keyboard hotkey based zoom.

One of them is that the layout breaks in current release at large zoom levels, but I think (?) the linked example could be salvaged by adding an em-based min-width to the main layout container...

The issue is that people expect text to get bigger when hitting cmd +. Instead, the opposite happens. I would like a way to control for that.

Note: It does not look like the container query flag is on in the screenshots you posted. It’s required to illustrate the issue in this demo. I can rework the demo to use another technology that can illustrate the issue if that is a problem.

[cookiecrook]

Note: It does not look like the container query flag is on

Thanks. I see it now.

[cookiecrook]

Teasing apart the demo, the problematic lines of CSS are these:

html {
  font-size: min( 120%, 5vw ); /* Scale down to avoid reflow errors on small screens */
}
h1, .product-price {  
  font-size: max(1.25rem, 12qi - 1rem);
}

Effectively the use of minus 1rem in a calc is the core problem. The rem increases as the font grows "larger" with Cmd+, so when used as a subtractive value, the rendered font gets smaller for the first several steps, until 1.25rem becomes the larger max(), and the rendered font grows larger again.

[scottkellum]

@cookiecrook yeah I set the scale function like that because I wanted a steeper slope for a more pronounced typographic hierarchy. If you use + 1rem the hierarchy is no where near as pronounced.