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. https://github.com/w3c/silver/issues/506 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.

[cookiecrook]

Understood. I’m not making a value judgement… I dissected it to understand the problem, and posted to save others time too. I will look again after the holiday.

One question I’ll ask in the meantime: do you think this CSS pattern (negative em/rem in a calc to set font size) represents a compelling and common need, or is this effectively just an edge case that happens to hit all the right variables?

[scottkellum]

Yes, I think this is a common need, and one that will become increasingly more common as container queries become popular.

Just focusing on viewport, here are the graphs of various techniques to scale font sizes along with the viewport line in the background. Anything that matches or is steeper than the slope of that line will result in the font size going down as the browser is zoomed in.

Here is the same graph, but highlighting places where the font size either doesn’t scale, or scales counter to the direction of zoom as the slope of the viewport scaling is shallower than the steeper slope of the font size scaling.

This is the issue people are discussing in this issue here regarding WCAG SC 1.4.4.

This problem will get worse with element queries because people will take more advantage of container size to determine visual contrast between items, as I am doing in the demo I posted here. In order to achieve sufficient visual contrast at any particular instance in the demo I posted, I needed to have a slope greater than the viewport scaling. Running some tests, if a website like The Atlantic were to translate their existing typographic hierarchy to a dynamic container derived one they would have the same scaling issue.

[scottkellum]

Here is an example showcasing how sizing can be used to create hierarchy, and why we are seeing/going to see steeper sizing curves as element queries become more of a thing.

[litherum]

I'm super confused about most of things that have been said in this thread. Here are some questions:

1. At the beginning of this thread, @scottkellum said:

Two possible solutions: ... 2. Setting a standard for browsers to zoom the root font size instead of the size of a pixel.

Safari has this feature. Would it be sufficient to advocate to other browsers to implement a similar feature too?

2. The problem shown in https://github.com/w3c/csswg-drafts/issues/6869#issuecomment-991227215 and https://github.com/w3c/csswg-drafts/issues/6869#issuecomment-991288325 seems to be "Sites often have a mobile layout with small text which is different from a desktop layout with big text, and use a min-width media query to switch between them, but when the user zooms in, that media query can be triggered (because the size of the pixels got bigger) thereby giving the user the small text mobile layout on their desktop machine. This leads to text getting smaller when the user zooms in, which is counter-intuitive."

However, the solution being advocated for, a "browser zoom unit", would require website adoption. But if website adoption is required anyway, why not just tell the websites "hey when people zoom your site the text gets smaller, and that's bad"?

3. Then, after talking about media queries, @cookiecrook then says:

Effectively the use of minus 1rem in a calc is the core problem.

to which @scottkellum replies:

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.

But just because + 1rem is bad doesn't mean that - 1rem is the only other solution. Why not use a function that has typographic hierarchy and is an increasing function? What about + 1rem - 32px?

4. Lastly, I don't understand these graphs at all. The X axis is viewport size and the Y axis is font size, and the problem we're dealing with is a situation where, as viewport size decreases (relative to the size of a pixel), font size can decrease. Except all the functions are strictly increasing functions, so I don't understand which part is the part to be concerned about. Can you explain this sentence more:

Anything that matches or is steeper than the slope of that line will result in the font size going down as the browser is zoomed in.

The blue line is "Typetura / interpolated values" which is a continuous function. Are you presenting this to indicate that the blue line is the desired line? Can we solve this issue by just adding a smoothstep() function to calc()?

[scottkellum]

I'm sorry I'm not making this clear. Ultimately I'm trying to address the issue Sara Soueidan points out.

One of my worst pet peeves on the Web: font sizes that increase when you zoom out on a page.

That’s not how zooming is supposed to work!

My graphs and so on are meant to explain why this problem exists in the first place, and subsequently how a zoom unit will solve this issue. I’ll work to address your comment point by point @litherum.

[scottkellum]

@litherum The timeline of events seems accurate up through here:

But just because + 1rem is bad doesn't mean that - 1rem is the only other solution. Why not use a function that has typographic hierarchy and is an increasing function? What about + 1rem - 32px?

I’m not sure how this function you propose solves the type hierarchy problem that is resulting in zoom issues. So maybe there is a disconnect here?

Lastly, I don't understand these graphs at all. The X axis is viewport size and the Y axis is font size, and the problem we're dealing with is a situation where, as viewport size decreases (relative to the size of a pixel), font size can decrease. Except all the functions are strictly increasing functions, so I don't understand which part is the part to be concerned about. Can you explain this sentence more:

Anything that matches or is steeper than the slope of that line will result in the font size going down as the browser is zoomed in.

Yes, what you are stating is correct. Maybe the disconnect here is that browser zoom is indistinguishable from resizing the viewport. That is why I put viewport size on the graph and why when the slope is steeper than the grey line you end up with the zoom issue Sara points out in her tweet.

The blue line is "Typetura / interpolated values" which is a continuous function. Are you presenting this to indicate that the blue line is the desired line? Can we solve this issue by just adding a smoothstep() function to calc()?

No, that is a different issue. I am trying to showcase the various CSS approaches that are all effected by this issue. The blue line is not the desired line on this graph. What I was trying to showcase is that all three of these CSS font sizing approaches (all equally valid for purposes of this zoom issue) have moments where browser zoom will not map to font size zooming, getting to the heart of Sara’s issue outlined in the previous comment.

Hopefully that makes things more clear 😅

Browser zoom and viewport size are indistinguishable. For typographic hierarchy reasons, one may scale text up dramatically on larger screens. However because zoom effectively scales the viewport down, it can cause confusion for people expecting text to get larger. I am proposing a zoom unit to compensate for these zoom issues.

[cvrebert]

I don't believe there is currently any specification for how non-pinch zooming works in browsers? So it seems perhaps premature to request a new feature related to customizing zooming behavior, when the base behavior isn't even well-defined.

[scottkellum]

@cvrebert That is a good point. Maybe it’s safe to ignore these issues instead of finding solutions to them until there are more consistent standards around zooming?

I am curious how WCAG can make recommendations on non-pinch zooming if that behavior itself is not well defined.

[cookiecrook]

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.

Tangentially, if the steeper slope is really what you're after, that might be solvable with a different solution. I don't want to brainstorm here and muddy an already complex thread, but consider filing that separately if it's the core of your need.

[scottkellum]

@cookiecrook The steeper slope is not itself what I am after in this issue. That is achievable with numerous techniques. I apologies for not making this more clear.

This issue is focused on solving the accessibility implications of scaling text with these various techniques.

The reason why I have been graphing out these various techniques is to illustrate both why people use them as well as where they conflict with expected browser zoom behavior.

[cookiecrook]

I'm confused again then. As far as I understand the issue so far, increasing font size or zoom ratio via Cmd+ or Ctrl+ works as expected except in the scenario where you've used a negative rem in a calc. When other solutions were suggested to avoid the negative rem (including +1rem-32px), you implied the negative value was required because you needed the steeper slope.

[scottkellum]

• For design reasons, I want the slope of my font size to be greater than or equal to y=1x
  • Note I am using generic algebra to take it out of a specific implementation, you could also say font-size: 8vw and to emphasize the issue I added the -1rem. Using +1rem-32px does not solve the zoom issue in the example provided as the slope is still modified by a net negative value. With +1rem-32px the text still scales inversely to the zoom rate.
  • Negative rem in calc() is not the root of this problem. It exists any time text is scaled more than the proportionate increase in the viewport or container.
• There are various methods to do this outside of having negative rem in calc. A series of media queries, clamp(), or a non-standard method like Typetura / the interpolated values proposal.
• This issue is not an uncommon issue, and it has an active thread with WCAG. I opened this issue as a proposal to solve this.
• This issue is common enough to where people have referenced it as an accessibility pet peeve on Twitter.

[cookiecrook]

[the problem] exists any time text is scaled more than the proportionate increase in the viewport or container.

Okay. That I understand, but it may be difficult to achieve consensus.

One example why is that Safari for Mac has a text-only variant of this feature... (Open the View Menu and hold the Option key to see this.) By definition, changing the text size only will be disproportionate to other layout metrics. How would you propose reconciling your example layouts while still preserving a user's ability to adjust the font to a size that works best for them using a "text-only" increase?

It sort of sounds like you're asking for the ability to cap a font size based on some proportional range, similar to how some iOS apps support Dynamic Type, but limit some views within the constraints of the layout. For example, the iOS Calendar app can shift between showing 1, 2, or 3 month grids horizontally, but beyond that, increasing the font size would cause overlap, so a top range is reached. A calendar grid isn't a calendar if the weeks wrap, or the numbers are unreadable!

3 Months Across	2 Months Across	1 Month Across

Previous suggestions for something like a max-font-size in em/rem would allow this, but if I recall correctly, the various W3C WGs rejected the proposals because max-font-size would be too easy for authors to abuse at the expense of user need.

That said, if your need is to constrain some reasonable font size within some critical structural layout (including but not limited to tables), I support finding a good solution. In the screen shots above, a calendar grid isn't a calendar if the weeks wrap. I didn't think any of the layouts you posted were critical for conveying the information, though I acknowledge an inability to have fine control over visual hierarchy is frustrating.

Am I getting closer to the core need of your issue? Or are we still out-of-sync?

This issue is not an uncommon issue, and it has an active thread with WCAG. I opened this issue as a proposal to solve this.

I'm aware of that thread, but I don't see your proposed solution as solving exactly the same issue.

[scottkellum]

@cookiecrook Unfortunately I think we are still misaligned on this. No, I am not proposing a constraint or cap on font size, and I don’t think such a proposal would be a good idea.

I think I see where some confusion exists. Originally, I proposed two separate possible solutions to this problem: 1 The first proposal is a zoom keyword in CSS. 2: The second proposal is that text scaling be made the default instead of page zooming being the default. Proposing two separate solutions may have caused this conversation to become more lengthy than it needs to be, and, like you've pointed out, I don't think this second solution has much merit.

Acknowledging that, let's focus on the first proosal: a zoom keyword in CSS —

This one, I think, is more realistic. It addresses the WCAG thread more head-on by surfacing the zoom level as a CSS keyword. Adding this unit to any of the examples in this thread or the WCAG issue thread would allow text that normally wouldn’t scale with default browser zooming to scale as expected.

For example, with the code font-size: 4vw, text would scale as expected with browser resizes, but inconsistent with expectations with cmd+/cmd- zoom. However, if we add a zoom unit to this,font-size: calc(4vw * zoom), that would make the text scale as expected with both browser resizes and cmd+/cmd- zooms. Does that make sense?

[cookiecrook]

Thanks. How would you compute the numeric value of the zoom keyword? Is it a unit, too? Is zoom proposed to be the current scale factor where 1.0 represents the default unzoomed web engine view, and 1.2 would be a 20% zoom?

As @litherum pointed out, "zoom" means different things to different people. I recall there are at least 4 or 5 types of "zoom." So would you expect this to work for pinch-to-zoom, double-tap-to-zoom, native zoom or screen magnification, and the built-in font size increase forms of "zoom" too? Or is this limited to the cmd+/cmd- form of zoom?

[scottkellum]

As @litherum pointed out, "zoom" means different things to different people. I recall there are at least 4 or 5 types of "zoom." So would you expect this to work for pinch-to-zoom, double-tap-to-zoom, native zoom or screen magnification, and the built-in font size increase forms of "zoom" too? Or is this limited to the cmd+/cmd- form of zoom?

I would expect this to work only for cmd+/cmd- page magnification only as opposed to font size scaling or pinch to zoom. These accessibility issues are only present with cmd+/cmd- desktop page magnification.

Thanks. How would you compute the numeric value of the zoom keyword? Is it a unit, too? Is zoom proposed to be the current scale factor where 1.0 represents the default unzoomed web engine view, and 1.2 would be a 20% zoom?

I was thinking of zoom as a keyword similar to currentColor where it would represent a value of 1.0 at a normal zoom of 100% and when cmd+/cmd- is pressed, 120% zoom would result in a value of 1.2, and 80% zoom would result in a value of 0.8.

[WestonThayer]

Note that window.devicePixelRatio comes super close to the proposed zoom. You could hack all this together today if we had a window.intrinsicDevicePixelRatio property that reflected devicePixelRatio at 100% cmd +/- zoom.

[cookiecrook]

Existing 1rem/16 also comes close to proposed zoom...

font-size: calc(6vw * (1rem/16));

If above works, and it's effectively already available, exposing as a new shorthand keyword is less troublesome, though "zoom" as a name is too ambiguous IMO.

[Lorp]

@WestonThayer That’s a good point. There are multiple use cases where it would be desirable for a change in zoom (specifically the length of 1px) to trigger a <canvas> redraw. (That element is the main reason to use window.devicePixelRatio.) However I believe the W3C regards it as unhealthy for the web if authors know this value, opening the Pandora’s box of pixel popping.

[alastc]

I'd like to +1 @cookiecrook's comment above:

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.

The expectation is that zooming in makes things bigger, and with responsive design things can shift around as you zoom. (Although in practice if you need >200% zoom, your default is probably over 200% so you may not zoom in/out much on a site).

The issue with text shrinking at smaller viewport sizes is a problem, but I would say that is what is hijacking the expected behaviour. (In the WCAG 2.1 timeframe the AGWG created a failure technique for that.) I think that's the source of Sara's frustration.

Also, I acknowledge that 1.4.4 Resize text can cause a false-positive when you have a massive headline that doesn't expand to 200%. (More in the WCAG thread you referenced.) My company tests a lot of sites (for accessibility) from a range of organisations and this type of issue has been rare so far.

I'm not sure if using font-size: calc(4vw * zoom) would have the desired effect. I see what you're going for, it is like an escape clause for viewport units when zooming. However, I'm not sure that having a different behaviour between zoom and smaller screens is overall a good thing. I can see a lot of unintentional layout issues occurring with that as text expands out of containers because developer 2 didn't realise that developer 1 had added this escape clause.

Existing 1rem/16 also comes close to proposed zoom

I'm confused about that, under zoom wouldn't that always be 1 unless the user also adjusts the default text size?

[cookiecrook]

under zoom wouldn't [1rem/16] always be 1 unless the user also adjusts the default text size?

Under the other types of zoom, yes. Hence my comment about ambiguity of the term.

But for cmd+, you've long been able to adjust a layout based on the current font size, for example: width: 100%; min-width: 20em;

FWIW, I don't know whether 1rem/16 works as expected currently. Waiting on an update at the moment and commenting from mobile. [Update: It doesn't.]

[cookiecrook]

An intrinsic device pixel ratio would also seem like it should reflect the pinch or tap types of zoom, which Scott said he does not want to be included.

[Lorp]

An intrinsic device pixel ratio would also seem like it should reflect the pinch or tap types of zoom, which Scott said he does not want to be included.

@cookiecrook but Cmd+ and Cmd- zoom in modern browsers does in fact change the length of 1px, affecting images, canvases and almost all layout.

[cookiecrook]

No argument there... I think?

I was trying to point out that 1px is also changed/rerendered with the other types of zoom that Scott did not want included in the zoom keyword use case.

[cookiecrook]

@Lorp Or maybe you're saying the division does not work (currently) because the value of "16" is relative in that context? Sure. No argument there either.

[cookiecrook]

@Lorp wrote:

I believe the W3C regards it as unhealthy for the web if authors know this [rendered pixel ratio] value, opening the Pandora’s box of pixel popping.

Presumably the same is true of the proposed zoom.

@alastc wrote:

The issue with text shrinking at smaller viewport sizes is a problem, but I would say that is what is hijacking the expected behaviour. (In the WCAG 2.1 timeframe the AGWG created a failure technique for that.) I think that's the source of Sara's frustration.

If I understand correctly @alastc, you're saying that the demo cases here fail specific success criteria in WCAG 2.1? Could you link to the one you're thinking of? Thanks.

[Myndex]

Since the zoom problem, not to mention at the x-height problem, is a big part of the work we've been doing, I'm putting this post here to update this thread with recent information.

The fact that browsers for the most part only zoom by a single percentage is part of the problem. The other part, is that different browsers handle their zoom of the page, or independently, zooming the text, in different ways and there's really not a standardization there.

And as some point out, and which we've been talking working on APCA / WCAG 3.0, zooming all text by a single percentage does not serve the needs of users. There is a range of "critical font size" and in an ideal world all text would remain within that range for that user.

But additionally, the current 200% in WCAG 2 is really not enough. The difference between 20/20 and 20/40 is 200%¹ (!!) Low vision needs much more. For desktop work, 500% for body text is reasonable and useful, accommodating somebody at 20/100.²

Low vision is considered somewhere around 20/70 ~ 20/80 and worse. Technically, 20/80 could need 400% (all things being equal, of course there are a number of wiggle factors here).

Unfortunately, 400% doesn't work on mobile devices. An iPad in portrait mode or an iPhone in landscape mode is limited at about 350% (20/70). And for a phone in portrait mode, 200% is really the limit for 16px body text—and this is only considering body text. When talking about large headlines, they can't be anywhere near 200% for mobile devices. Again all things being equal depending on Display, scale, distance from the face, etc.

In this post in discussion 39 on use-cases at the readability forum, about halfway down is the section on spatial frequency (size) and zooming, and a link to some examples.

These show that if we really want to accommodate low vision, we cannot be zooming all text the same percentage, period. At the moment this can't be a guideline because the technology isn't there, except with a polyfill, and we can't require a polyfill guideline.

What we need is browsers aligning uncommon standards for how to handle:

At a minimum 1) asymmetrical text zoom with content text reflow, as described in the examples were text larger than the body text does not get zoomed as much. 2) full page zoom (text & elements on page maintain relative relationships)

Enhanced 1) Element text only zoom (a.k.a. paragraph zoom) zooms only the text of the selected text container, such as a column, leaving all other text as is, including headers. 2) Element adjust zoom style sheet that adjusts specific elements (CSS is not really here for this yet). 3) Force reader mode for selection

---

NOTES: ¹ Regarding 20/40 & 200%. With a standard font such as Arial or Helvetica, at 16px 400 body text, at 100% and on a standard monitor at the standard distance away, where 1px = 1.278 arc minutes of visual angle, and the luminance contrast is adequate (Lc 75+), then we're at the critical size for best fluent readability for 20/20, for 20/40 we need to zoom to 200%, for 20/70 we need to zoom to 350% for that body text. Critical size means that increasing the size further does not result in an improvement in fluent reading speed or comprehension. (Lovie-Kitchin et alia)

² Regarding 20/100 vision. Per the current rules with the Social Security administration in the United States: uncorrected vision in both eyes, worse than 20/100, where no letters on the 20/100 line are recognizable, constitutes legally blind. The common statement of "20/200 is legally blind" stems from older eye charts that jumped straight from 20/100 to 20/200, but nothing in between. Modern LogMAR charts have intermediary lines, typically 20/125 & 20/160. For SSA disability, if somebody can see letters on 20/125, but none on 20/100, they are considered legally blind. (US SSA)

[scottkellum]

@Myndex First off I am in total agreement with you on the issues you have outlined. I am also especially in agreement regarding x-height being the key issue of legibility, at least for languages that have an x-height.

One point in your reply that gets at the root of the original issue I posted:

the technology isn't there, except with a polyfill

Unless I am missing something, the technology isn’t there even with a polyfill. I opened this issue because in most browsers, changing zoom is indistinguishable from resizing the viewport. I created this issue so that there could hopefully be a tool at our disposal to create a polyfill. If we can identify page zoom level then we can make sure the text is scaled appropriately for optimum legibility.

If there is a way to detect zoom then that would resolve this issue, so I would be very happy to be wrong about this!

[Myndex]

Hi Scott! @scottkellum

Unless I am missing something, the technology isn’t there even with a polyfill.

Well, how about a polylandfill....

I think I was talking more about x-height, there's things you can do to kinda get x-height sort of working with a polyfill.

The thing that I find most troubling is the WCAG guidelines are (technically) only about what the author must do irrespective of technology—but some of the SCs are really not an author issue, often more a technology issue. Things like text reflow and zoom is a prime example. There is much missing from the technology still today. The subgroups here that were at one time developing accessible standards for technology end of things are essentially abandoned.

The deeper I get into this stuff the more it's clear that some of the most pressing accessibility problems are with the current state of the technology.

I opened this issue because in most browsers, changing zoom is indistinguishable from resizing the viewport.

Chrome has a bunch of different zoom options, both text-only and whole-content. Safari and Firefox both have a font only version as well as the whole screen

Nevertheless, as far as I'm concerned none of them work very well. Browsers aren't QuarkExpress or InDesign, and the problems today with typography and type rendering on the web in 2023 is kind of shocking

And I'm not even bringing up the subject of 15 years ago pretty much all websites were using black text until some standards organization said that 4.5:1 is somehow OK for body text, and over a period of a few years all those sites with black text slowly migrated to unreadable light gray, I suppose because it's trendy and goes well with banal Bootstrap frameworks.

Then google came out with Google fonts and "hey everybody let's try 200 or 300 weight because hooray for gray" or something. An apple decided that they just had to have blended font smoothing and of course people use that with a tiny 300 weight font so the whole font is subsumed into the background, even on the retina screen that I'm looking at right now.

I mean can the people running sites even read them? I would think that if people are putting Time money and effort into a site that they'd actually want people to, I don't know, read the stuff,,,

End of rant

x-height and legibility

I like your idea over at CSS drafts, I'll comment more over there https://github.com/w3c/csswg-drafts/issues/6709#issuecomment-1397682218

....Other than to say I should probably take lessons from you on how to be brief, clear, and succinct, because apparently I missed that day...

[scottkellum]

@Myndex Thank you so much!

Most desktop browsers have consistent zoom behavior when hitting cmd + or cmd - and this issue addresses that behavior. But yes, there are alternate zoom modes in other browsers and building better and consistent tooling around this would be awesome.

Yes thanks for your comment on #6709! I replied over there.

[clshortfuse]

Note that window.devicePixelRatio comes super close to the proposed zoom. You could hack all this together today if we had a window.intrinsicDevicePixelRatio property that reflected devicePixelRatio at 100% cmd +/- zoom.

I've tried it, trying to get a 10mm touch target to stay consistent with page zoom. You can see it works here: https://codepen.io/shortfuse/pen/JjmPyJd

But that's because desktop browsers are (likely), 96dpi. That goes out the window with mobile devices. Also iPad says 2 always, despite it being closer to 1.7 IIRC. It's a proof-of-concept (don't use it in production).

---

I tried to work on these issues back in 2019, most specifically an font accessibility issue present on all Android devices and heavily impacting PWAs. Working on Apple has a suitable workaround (-apple-system-body). I'm primarily interested in the accessibility aspect personally. Layout is secondary for me, but I recognize its importance.

A F2F meeting in 2019 concluded the resolution was to put something in <meta viewport>. IMO, It should start from there and we can build on after. Problem is, that aspect has stalled. I was hoping somebody can help get this back on track.

https://github.com/whatwg/html/issues/3494

[cookiecrook]

A F2F meeting in 2019 concluded the resolution was to put something in <meta viewport>.

Many members of the CSSWG were opposed, IIRC. @fantasai was one. The idea to incubate <meta viewport> was a consolation, but shortly after starting to incubate that idea, it was abandoned because we could ship a better interface in mobile Safari with the site-specific font size control. Since then we haven't have much need for -apple-system-body for accessibility needs or otherwise.

[cookiecrook]

Acknowledging (from @clshortfuse's comment in another thread) that the Safari font size control doesn't solve the issue in the case of Home Screen web apps.

[cookiecrook]

And I'm not sure whether we're crossing two unrelated threads, or whether these font size solutions are related to the "zoom unit" proposal in a way I just don't fully understand, because the thread is… dense. 😉

[tmjoen]

Apologies, but I am a little unclear on what the pushback for a "zoom" keyword in CSS actually is? It is mentioned that it can be "abused" and misunderstood if there are multiple developers working on the same project.

If the concern of abuse stems from being able to negate the zoom level, I would say the current state is worse than what might be abused, since right now there are a ton of websites scaling text with only "vw" which defeats the cmd+/cmd- zooming completely. Scaling type with the viewport is a nice tool for the user to finely increase/decrease the font size by increasing or decreasing the width of the browser window, and will become even nicer with the great new container sizing units. If the user could also use cmd+/cmd- to zoom in/out on top of this it would be a great solution.

I would say that a clear zoom keyword we can use with calc would be a great win for accessibility. env(browser-zoom-factor) for instance?

[clshortfuse]

And I'm not sure whether we're crossing two unrelated threads, or whether these font size solutions are related to the "zoom unit" proposal in a way I just don't fully understand, because the thread is… dense. 😉

@cookiecrook Back in 2019 we had discussed things like env(system-font-size) and a bunch of other CSS concepts. I understood it that we had punted that work to the HTML spec. But I understand now, concepts related to scaling font was decided to be left in the hands of the browser.

https://github.com/w3c/csswg-drafts/issues/3708#issuecomment-532113043

That means solutions related to computing based on a CSS variable, as suggested in the first comment's point number 2:

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

Was resolved to not being something that will land in CSS.

To this day, Android users are affected by accessibility concerns. A bug since 2016 (!) still remains open titled: Switch accessibility font scale factor to use page zoom instead of text autosizing. The other bug filed regarding PWAs specifically has been stalled since 2019 for lack of a clear spec.

My understanding was we were getting something over viewport and that would relate to this, but apologies, I was mistaken. That means there isn't anything planned for viewport that we can read or set that will get use to font-based scaling. In other words, there is nothing we can set to change the mechanics to how pages zoom, pixel or font-based.

The issue here is best summed up with:

One of my worst pet peeves on the Web: font sizes that increase when you zoom out on a page. That’s not how zooming is supposed to work!

Chrome Android struggle with it most. That's kind of where we stand in terms of what we've discussed and what we can do. /exhale

---

Specifically with layout, I feel like if container queries can take computed sizes like calc(40ch + 32px) we can work towards cleaner scaling layouts. I could size different layouts based on how much text can fit, not just zoom (pixel) based. Form fields that can shift around based on font size are tricky, though I've found moderate success with using intrinsic sizes (eg: <input size=50>) and flex:auto.

The other avenue could be trying to get devicePixelRatio standardized across browsers and getting their values injectable into CSS line my codepen shows. I haven't explored much there personally, there might be something there.