w3c
[css-fonts-5] Text Fitting: Default scaling limit
In the original issue we received valuable feedback that a native fit-to-width solution can potentially introduce a simple way for authors to violate Success Criterion 1.4.4 Resize Text, in the same way many existing fit-to-text and other responsive typography approaches already do.
My proposed solution involves introducing a default limit equal to 200% of the original font-size. This, with all major browsers being able to provide at least 400% full-page zoom, will allow to scale any text that uses fit-to-width without overriding this limit.
This limit is just a default, allowing authors to control it, and increase/decrease based on their design goals: there are cases where the absence of the limit won't cause the SC 1.4.4 violations, and we shouldn't limit authors there. And, realistically, we can't — but we should do what we can and introduce basic safeguards to the spec, so it won't be easy to violate WCAG with the new property.
In Google Chrome team's feedback they mention this about this proposal:
- Accessibility: If the width of a container with
text-growortext-shrinkdepends on the viewport width, changing the page zoom level might not alter the physical text size in that container because its physical width remains unchanged.
We currently do not have a solution for this issue, and are not sure if the "200% size limit" solution discussed in this issue will work well.
I would be interested to know reasons why Chrome's team thinks why this limit won't work well.
But without any alternative proposals to safeguard against violating SC 1.4.4, I believe the built-in default limit is the way to go.
So far, I did not read any other proposals that would cover this issue, but if there are any — please, post them in this issue.
First, I'm wondering what exactly is meant by the "original font size". If a user is constantly browsing any pages at a 200% page zoom level, does the "<CSS font size> * 200%" constitute the "original font size"?
If that is the case, changing the page zoom level while viewing a page would cause the "original font size" to be scaled as well, which means the 200% limit idea would not resolves the accessibility issue.
If it's defined differently, and the "original font size" is the size before the page zoom level is applied, then this particular user would not see any effect from the fit-width text feature.
By “original font size”, I meant the font size on an element where the text fitting would be applied, but without it.
I understand that this proposal could be easier to grasp with some examples — I’ll add some this week using my hacky workaround which supports it.
I have an idea to address this accessibility issue:
-
Browsers can distinguish between the page zoom factor at the initial load and changes to the page zoom factor while viewing the page.
-
When the layout is performed with the initial page zoom factor, we record the physical width of the container where this feature is enabled.
-
When the page zoom factor changes and triggers a re-layout, if the new physical width of the container remains the same as the recorded value, we apply text scaling by treating the container's physical width as if it were scaled by
<current page zoom factor> / <initial page zoom factor>. -
A downside is that reloading the page after changing the page zoom factor will result in a different rendering outcome. This is because the current zoom factor becomes the new "initial" zoom factor, and the previously recorded container width is lost.
I plan to experiment with this approach to see if it is feasible.
This sounds interesting, but aside from the non-stable rendering depending on the initial zoom value, there could be concerns over the ability to detect if the user uses zoom.
BTW, I am currently using my prototype implementation with the 200% limit on my blog, and, so far, it seems to work pretty well. The default font-size that I have in most cases is enough to scale the headers to fit the full width, occasionally I have to bump up the default font-size if the words are too short, and very rare there is a need to define different values per line, but usually it is not more than 1 line needed, and with a native implementation ::first-line will help.
What I mean: I still think the default limit is the most simple way to address it, so I will repeat my question:
I would be interested to know reasons why Chrome's team thinks why this limit won't work well.
That said, if your experiments succeed, and won't be blocked by some concerns, it could potentially augment the limit: by default there could be a limit, thus eliminating the issue and not requiring the zoom detection. If an author overrides the limit to more than 200% (or maybe even 250% — or could be dependent on the UA's max page zoom level?), then this additional algorithm could kick in, maybe?
Can I try your prototype implementation?
I think the default limit approach doesn't work well because a zoom-in operation will decrease the scaling factor in general. In the following example, changing 100% page zoom to 125% page zoom will decrease the scaling factor from 1.333 to 1.066, so the upper limit of the scaling factor won' affect.
So - I somewhat disagree with the premise of the issue wrt. WCAG Resize Text (and that section of WCAG lacks nuance FWIW).
Firstly - the most important thing wrt. WCAG Resize Text is that the body/paragraph text gets bigger (e.g. the smallest text on the page). Its less important that heading text for example grows at the same rate (or grows at all).
I suspect the thing we really only need to do here is ensure that the minimum font-size increases, not the final.
(Note developers already opt into this style of behaviour today with heading text using something like clamp(15px, 2rem, 10vw) or similar which is quite a common pattern).
Ian
I think the default limit approach doesn't work well because a zoom-in operation will decrease the scaling factor in general. In the following example, changing 100% page zoom to 125% page zoom will decrease the scaling factor from 1.333 to 1.066, so the upper limit of the scaling factor won' affect.
The important part is that browsers allow zooming up to 500%. That means that with 200% limit, a 400% increase will guarantee at least 200% increase in the font-size. For small zoom values there won't be a change, but that's ok and expected. The important part is the possibility to get the increased text at all via available browser tools.
Firstly - the most important thing wrt. WCAG Resize Text is that the body/paragraph text gets bigger (e.g. the smallest text on the page). Its less important that heading text for example grows at the same rate (or grows at all).
This was already argued in the original issue in a pretty long discussion, and there was a very strong pushback from a11y folks about this. For anything related to WCAG, it doesn't matter if the specific SC lacks nuance, if the heading text will not grow, it could lead to a violation.
This responsive text pattern is also criticized in the same way.
Firstly - the most important thing wrt. WCAG Resize Text is that the body/paragraph text gets bigger (e.g. the smallest text on the page). Its less important that heading text for example grows at the same rate (or grows at all).
As noted, headings also need to scale to 200%. There is no exception for headings; they are the same importance as body text.
Linking the WCAG 2.2 1.4.4 Resize Text SC Understanding doc so folks are looking at the current one with normative language and the additional context it provides.
Users have multiple non-AT methods to resize text with the last one being most common in my experience:
- text size in the browser;
- magnification;
- browser zoom.
Users who have to resize the page to 500% to get the text to 200% may not understand why 500% only gets them to 200% (and some may genuinely need 500%). This can result in bug reports and complaints (users will raise issues, because they already do and I have fielded them).
I encourage you not to put an artificial cap on this at 200% and instead allow all browser-supported zoom levels.
I recommend this issue also addresses SC 1.4.12: Text Spacing, since authors sometimes use values relative to the text (such as unitless values for line-height) or hard-code values (like px for line-height). Not accounting for those can cause text overlap, violating 1.4.12.
@aardrian I encourage you not to put an artificial cap on this at 200% and instead allow all browser-supported zoom levels.
How do you suggest the SC 1.4.4 could be achieved for the case of browser zoom reducing the effective viewport size if we won't introduce a default cap to 200%?
Do you consider Chrome team's proposal to detect the browser zoom at initial page load and then scale text while considering the difference between the size on load and the following zoom factor worth the potential font-size change after a refresh? If that's acceptable, I would be happy to go with that option, as it should make the fonts to resize with the page zoom.
Although, a follow-up question to @tkent-google then about what would happen with the text reflow? Do we trigger word wrap or horizontal overflow for those containers? Would be great if you could prototype your proposal, as it would be interesting to test it out against real use cases.
How do you suggest the SC 1.4.4 could be achieved for the case of browser zoom reducing the effective viewport size if we won't introduce a default cap to 200%?
I don't understand how introducing a text scale limit of 200% meets 1.4.4. You need to meet 200%, but that doesn't mean you stop at 200%. Let users zoom as much as the browser allows.
Do you consider https://github.com/w3c/csswg-drafts/issues/12886#issuecomment-3556253205 to detect the browser zoom at initial page load and then scale text while considering the difference between the size on load and the following zoom factor worth the potential font-size change after a refresh?
Not at first glance, no. A user may scale the page up and down repeatedly without navigating to get the size they can read and may need different scale factors on different pages (home page versus a product page versus a press release). Which means when they come back to any page and they get a "different rendering outcome," they may assume something has broken, disappeared, or otherwise changed.
It also adds a not-insignificant burden to people who test WCAG (human and tools) as it suggests they need to test a page first by resizing on the page and then by reloading the resized page. That would impact 1.4.4, 1.4.10, 1.4.12, and potentially 2.4.11 & 2.5.8.
I should note that I am also not a browser engineer, so I may be misunderstanding the terminology used.
I don't understand how introducing a text scale limit of 200% meets 1.4.4. You need to meet 200%, but that doesn't mean you stop at 200%. Let users zoom as much as the browser allows.
Isn't it exactly the same as the example from the second note on the “understanding” SC 1.4.4 page?
As with most other Success Criteria, this criterion applies to each variation of the page that is automatically presented for various screen sizes (e.g. media query variations in a responsive site). In an implementation where text does not consistently increase its size as people zoom in (such as when it is transformed based on a media query to adapt to small-screen usage), it must still be possible to get to 200% enlargement in order to satisfy the criterion.
For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280 CSS pixels wide, at 200% zoom it will visually appear at twice the size. After zooming by 400% the page reflows to fit within the 320 CSS pixel viewport, the author may decide to set the page's text size to 10px. The text is now half the original size in CSS pixels, but as it has been enlarged to 400%, it is still displayed at twice the size compared to the default browser setting at 100% zoom. It is not required to achieve 200% text enlargement while remaining inside a specific breakpoint (as zooming may result in the variation for a new breakpoint becoming active), but it should still be possible to get 200% text enlargement in some way compared to the default 100% zoom.
The proposed limit is only for the text-grow algorithm in relation to the original size. When page zoom happens, it is fully analogous in behavior when the font-size is reduced for a narrower screen, and the “Understanding SC 1.4.4” says that this is enough to satisfy SC 1.4.4.
I don't understand how introducing a text scale limit of 200% meets 1.4.4. You need to meet 200%, but that doesn't mean you stop at 200%. Let users zoom as much as the browser allows.
Isn't it exactly the same as the example from the second note on the “understanding” SC 1.4.4 page?
No. See the final clause: "it should still be possible to get 200% text enlargement in some way compared to the default 100% zoom." It doesn't say to stop at 200%. You satisfy the SC by getting to 200%, but you support users by allowing larger. Otherwise the 500% setting is just a lie.
Also, remember not all sites use media queries. Older sites do not and more and more modern sites ditch media queries in favor of more robust grid or flex layouts. Many sites that use media queries also don't resize the text at different breakpoints. Heck, I've argued for years to not set text size.
The proposed limit is only for the text-grow algorithm in relation to the original size. When page zoom happens, it is fully analogous in behavior when the font-size is reduced for a narrower screen, and the “Understanding SC 1.4.4” says that this is enough to satisfy SC 1.4.4.
See my point above that font size is not always reduced for a narrower screen. Assuming MQs are in use, or treating the solution as if MQs are ubiquitous, risks unexpected scaling.
And again, 1.4.4 does not cap text size at 200%. It sets 200% as the conformance target.
I discussed offline with @tkent-google and @bfgeek, and reviewed the WCAG doc @aardrian linked to. I think it can be resolved with the following spec text:
User agents should ensure that regardless of browser zoom level, the resulting computed font size in CSS pixels for fit-width text should be sized to max(sizing computed at 100% browser zoom, sizing to fit the new container size at the desired zoom)
User agents can compute this as part of layout.
Following this text would mean that if the text sizing computed by text-grow etc at a 100% zoom value ended up being N CSS pixels, then at (say) 400% zoom, the computed style would still be at least N CSS pixels and therefore the size drawn for the user would be at least 4 * N device pixels, thus satisfying WCAG requirements.
