Browser zoom unit for accessibility [css-values-and-units] #6869
Comments
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 |
|
@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? |
|
-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. |
Typically when low viz users zoom in, they expect the content to stay the same, not adjust with the zoom ratio.
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? |
|
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. |
|
Thanks @cookiecrook
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 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. |
|
Attaching some visuals from @scottkellum's samples since that's what helped the issue "click" for me:
Now let's compare the desktop design at 100% zoom vs. 500% zoom:
The 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
@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. |
|
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.
|
|
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). |
|
Thanks for your patience in the explanation. I wrote:
@scottkellum replied
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.
Before responding further, does that capture the concern, or am I still off the mark? Thanks. |
|
@cookiecrook Correct this is regarding keyboard hotkey based zoom.
The issue is that people expect text to get bigger when hitting 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. |
Thanks. I see it now. |
|
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 |
|
@cookiecrook yeah I set the scale function like that because I wanted a steeper slope for a more pronounced typographic hierarchy. If you use |
|
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? |
|
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. |
|
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.
|
|
I'm super confused about most of things that have been said in this thread. Here are some questions:
Safari has this feature. Would it be sufficient to advocate to other browsers to implement a similar feature too?
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"?
to which @scottkellum replies:
But just because
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 |
|
I'm sorry I'm not making this clear. Ultimately I'm trying to address the issue Sara Soueidan points out.
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. |
|
@litherum The timeline of events seems accurate up through here:
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?
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.
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 |
|
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. |
|
@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. |
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. |
|
@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. |
|
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 |
|
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!
Previous suggestions for something like a 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?
I'm aware of that thread, but I don't see your proposed solution as solving exactly the same issue. |
|
@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 |
|
Thanks. How would you compute the numeric value of the 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 |
|
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 |
|
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 |
|
@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. |
|
@Lorp wrote:
Presumably the same is true of the proposed @alastc wrote:
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. |
fantasai
added
a11y-tracker
|
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
Enhanced
NOTES: ² 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. |
|
@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:
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! |
|
Hi Scott! @scottkellum
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.
Chrome has a bunch of different zoom options, both text-only and whole-content. 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 legibilityI like your idea over at CSS drafts, I'll comment more over there ....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... |
|
@Myndex Thank you so much! Most desktop browsers have consistent zoom behavior when hitting Yes thanks for your comment on #6709! I replied over there. |
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 ( A F2F meeting in 2019 concluded the resolution was to put something in |
Many members of the CSSWG were opposed, IIRC. @fantasai was one. The idea to incubate |
|
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. |
|
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. 😉 |
|
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. |
@cookiecrook Back in 2019 we had discussed things like That means solutions related to computing based on a CSS variable, as suggested in the first comment's point number 2:
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:
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 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. |
|
I'm not sure if it applies here, but in my JS-based "solution" to this where I set a CSS variable |
|
@tmjoen yes that approach applies here, however it’s really fragile and unreliable as you would need to maintain a database of user agents default device pixel ratio. That is why I created this issue, to provide some tool to give reliable information as to the zoom level so that sizing and layout can be adjusted accordingly. |
|
This is the argument I'd like to put to rest. I used to agree, but I no longer think this argument has merit. @clshortfuse wrote:
I think it's unlikely there will ever be a way to derive a single reasonable font size for every page on the Web. Apple tried this initially with Dynamic Type in native apps which worked for most first-party apps, and with What has worked is allowing the user to set app- and site-specific font sizes. iOS has controls to set a font size either for the system or specific to the native app. Likewise, Safari has a font-size controller that is site-specific. The same could be done for offline web apps on any platform, but the specifics of the user interface control to set the font size is a platform implementation detail. Android could do something similar, allowing the user to opt-in to a comfortable and site-supported font size, rather than requiring authors to support an additional unit, since CSS already has the capability for scalable font sizes. |
|
Hi @cookiecrook ! I'm a bit disappointed to hear you feel that way, but I can understand based on your experiences. Also, thank you for giving it attention. From my personal experience, we work with a lot of people above 40-50 years old. It's not uncommon to see their devices with really large font sizes on their OS. We would very much like to keep that expectation with PWAs. I am willing to jump through hoops as a dev to cater to my users. But asking users to jump through hoops goes against what I feel is the intention of accessibility options. It's not uncommon for us to have users self install our enterprise applications only later to call and complain the font size is too small. Remember, the websites used to Add to Home Screen were displayed with the adjustments the users have in the browser. Those settings do not apply on install. Our best solution has been to remotely troubleshoot over the phone and, by use of Websockets, have the support agent remotely bump up the font size for the user. That's because asking somebody who is already having difficulties reading the screen to hunt for options is illogical. On the basis of how web devs misuse font size, I'm not surprised at all. Devs freely hijack font size because, apparently, multiples of two is too hard (/snark). But irresponsible usage of a feature intended to solve a problem, doesn't mean the problem doesn't exist. Nor does it diminish the importance of finding a solution. Like the adage I'm sure you know, "No ARIA is better than bad ARIA". To straw-man your argument (apologies), we still have ARIA in place for responsible devs. I easily concede for trivial things, but I don't have any good responses for when people ask why their disabilities aren't given importance. The best I can do is shrug and assure I'm doing the best I can. But to tell them we can't because others might misuse it, is almost always interpreted as telling them their needs aren't important. Still, some finality is better than vagueness. To extend the ARIA illustration, browsers do have a very compatible accessibility features (eg: Being fair, I won't try to paint Apple with same brush. For me, now, Again, thanks for dedicating time on the issue. ❤️ As for this specific issue I do believe For example the calendar example, you should be able to calculate if a week ( |
That's fair. Not specific to the solution, I'm in favor of well-designed developer opt-in, FWIW. The problem I was calling to light was that:
I wanted to share how Apple solved those particular problems without requiring a new CSS unit for the font size use case outlined. |
|
|
At the risk of resurrecting a lengthy discussion ... I remember skimming over this issue at the time, but have recently been made aware of it again and I'm trying to just check...is this essentially saying: developers want to distinguish between "the viewport is a certain size because the device/browser window/etc is set to a certain size" and "the viewport is a certain size because the user has zoomed"? because if so, I'm really not sure I'm a fan of this idea, because the whole point to me would be that it doesn't matter why a viewport is reported as being a particular size, as a developer you should design your content so it works well within your given viewport (regardless of what actually caused it to be that way). and yes, I can see how that brings up issues if you base your font sizes on viewport units, but that's then effectively the caveat/danger of using those units? and that those units like |
|
@patrickhlauke yes you have a good understanding of this and yes that is a fair outcome. The specific issue is with WCAG SC 1.4.4 for large text (headings) and expectations around zoom behavior. If SC 1.4.4 were written to be more accommodating of large text scaling, then this feature is not necessary. I do not personally think large headlines need to be scaled up with browser zoom, as they are often already as big as is reasonable. But to work to the letter of the WCAG, not the spirit of it, a feature like the one proposed in this thread would be necessary. |
|
sadly, 1.4.4 Resize Text is now a 25ish year old criterion, from a time before any responsive etc designs were even possible...but even back then, it could likely have been drafted to be a bit more accommodating and providing some upper boundaries. so yes, i feel your pain. tentatively, another possible solution (which obviously would require browsers to be on board) would be to provide an option on desktop to zoom like on mobile/tablet browsers (where the layout viewport remains the same even when you zoom, instead of reflowing) ... but that would potentially cause other issues of course |
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:
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.
The text was updated successfully, but these errors were encountered: