You just can't scale text size independently of layout and interface. The size of the text is fundamentally related to the structural layout of the page. The number of columns, the size of images, the relative placement of buttons and UI elements -- it's all inextricably tied to the size of the text.
Good news is that we already have a solution for this: responsive design, aka page zoom. Every serious site already gracefully handles a wide range of viewport widths. When you zoom in, you are simply simulating a narrower viewport width. This type of constraint and flexibility is already well tested. Zooming in makes the text bigger. And, zooming in makes the layout adapt to a single column when that's all that will fit. It all works harmoniously together, because we test and accommodate for all viewport sizes, which is the same as all zoom levels.
The proposal at hand to scale text alone is bad for everyone. Developers now have a geometric set of permutations to test. What about an ultra-wide viewport with large text? What about a small viewport with large text? What about a wide viewport with small text? It's so much that it won't make business sense to invest in all of the testing, and all of the design and implementation work to accommodate all of the cases. And so, it will be bad for end users who will set their text size to their preference, and then find that actually usability and readability are now worse.
In the end the answer is simple: when users set their text size to be larger in the OS, browser vendors should increase the default zoom in browsers. This is already how it works on Windows, and it is definitely the best path to happiness for all.
It's not that tough, but there can be tricky cases.
And so I have it set to have smaller buttons but still a normal-size font.
Don't know about mobile, probably works there too.
Here's NYT with that firefox "zoom text only" enabled: https://i.imgur.com/zp7pDW3.png
See the chopped "rld" on the left? That's the link to the "World" section. To the left of that off the screen should be the "U.S." section. But there's no horizontal scroll bar or any way to get to it, or any way to even know it exists. Categories spill off the right too, and you can't get to those either. This anti-feature, in the name of accessibility has actually just made things worse.
For reference, here's the totally sensible result if you just don't enable "zoom text only": https://i.imgur.com/Kkd5aOu.png
Browsers originally had text zoom -- only text zoom -- until page zoom was invented, I can't remember by which browser. And then page zoom quickly became the "main" zoom mechanism across all browsers because it was obviously so much better -- icons, layout, everything adjusted together. (And for those who remember, when there was only text zoom, it was a common practice/workaround to define everything in em rather than px, precisely to "fake" page zoom with text zoom.)
I'm baffled by the idea of trying to bring text zoom back. Just no, a million times. We tried it. It was bad.
Stuff like "page overlays become so large that they overflow the bounds of the screen, but are fixed position so you can't even scroll them to make the X button visible."
Or in the slightly better case, "most of the screen is obscured by the enlarged floating header, the layout of which is totally broken by the relatively narrow viewport relative to content size, and with your large page zoom setting the remaining half of the screen can fit about five words on it at a time."
Either way websites need to do accessibility testing and clearly most of them don't.
Safari has a setting for "Never use font sizes smaller than __" which used in combination with a not as high page zoom setting is a little less likely to make pages completely fucked, because it's only acting on text that was small to begin with.
And with page overlays, text zoom isn't necessarily going to fix anything. Sometimes the button to dismiss is at the bottom, and the larger text will just push that off-screen downwards. (I do agree that pop-ups/overlays designed for a screen larger than yours are a problem, but that's often less about zoom than just assuming small/short phone screens no longer exist.)
The unfortunate reality of accessibility is that there was no expectation of wheelchair ramps until the ADA forced everyone to quit saying "but ramps cost money and I don't personally need that" and do the right thing, web accessibility may end up requiring the same treatment.
If you have vision problems such that sites don't work at the zoom level you need, then you simply need to purchase or use a device with a larger screen. Then the larger zoom level will work, because there's more space for it.
The world adopted responsive design a long time ago to be mobile-friendly. That inherently made page zoom highly effective even at larger levels. If you need to push it to extreme levels, you need to get a larger screen.
And there's always pinch-to-zoom on top if you really need it. Plus screen magnification utilities.
Here's what chatgpt.com looks like on an iPhone 17 Pro Max with the page zoom turned up: https://imgur.com/XXweCSj
It's such an absolutely pathetic use of the viewport space. And this is exactly that kind of thing that giving pages separate text scaling awareness instead of only page zoom will be able to improve. Most of the stuff using up the limited relative viewport size did not need to be enlarged.
Insisting that blind people should accept wasting left and right thirds of their screen space (seriously, look at the size of the chat bubble where you can see a tiny slice of it peeking through) on zooming in the white space and just buy bigger devices that don't even exist to accommodate this, all because uniformly blowing up all page elements is easier for developers is… I'll be polite and say it's not something I agree with.
At some point you just have to accept that your vision accommodations need to be met with a combination of hardware and software, not just software alone.
In the ChatGPT example, the entire interface boils down to a scrolling chat history, a text input box, and a send button. It's hard to imagine an interface that would be easier to fit in a small viewport than this. But the current reliance on full page zoom and poor responsiveness to viewport space (maintaining huge side margins in a narrow window) means it sucks.
Their mobile app works fine with large accessibility text sizes (iOS goes up to 310%). There's no fundamental reason the web shouldn't be able to handle an accessible interface with enlarged text equally well. The current state of web accessibility is just bad.
It can be better, but only if people do the work to make that happen. Curb cuts and wheelchair ramps didn't exist until we built them, and they gave a lot of people with mobility limitations the ability to get around independently. Unfortunately it took heavy handed regulation to force the issue, because so much of the population is content to say "I'm not the one in a wheelchair, why should I care about that?"
My hope would be that enough people in tech do care about accessibility and it won't require that level of regulation. And I'm thankful that Chrome is looking at ways to improve the current situation.
It's a website. We already have responsive design between desktop and mobile. You're essentially asking for a third modality that is essentially purely text and buttons without margins or padding, something that would work for closer to Apple Watch screens. You're showing a case where you need everything 3x larger in each dimension, which gives you nine times less usable space on your screen. Asking interfaces to work in one-ninth the usual space of an already space-constrained phone screen seems unreasonable to me.
If you need 3x magnification in each dimension and want to browse the web, you really just need a larger device. That's an accomodation that exists. Tablets exist. This isn't the equivalent of needing curb cuts and wheelchair ramps, because larger screens are already available for this level of visual disability.
Actually Windows has a newish independent text scale accessibility setting that is different than display scale.
Yea, sometimes you have to update your UI to account for that, but it’s not a big deal most of the time.
https://learn.microsoft.com/en-us/windows/apps/develop/input...
... he writes, on a site that forces horizontal scrolling on mobile.
If I make HN font readable size on portrait phone using just zoom, the page is 4 screens wide.
Old timers remember that this was the old way of doing things, until at some point they changed to do full-page zooms, to the joy of developers.
Now they're adding support for this again, but `:root{font-size: 16px}` breaks it, so you're guaranteed to see that in CSS resets everywhere because there's nothing that managers hate more than inconsistencies
"QA user X mentioned that the text overflows when text zoom is at 300%. Fix it."
We've adopted a stance that functionality trumps design at larger text scaling. Second, overflowing is preferable to truncating (also as per the WCAG, which says you shouldn't truncate / no information should be lost on larger text scales)
For example, NYT with 200% text-only scaling: https://i.imgur.com/zp7pDW3.png
Android 14 has this in non-linear text scaling -
> To prevent large text elements on screen from scaling too large, the system applies a nonlinear scaling curve.
https://developer.android.com/about/versions/14/features#non...
(Also "light mode" apps are painful for him to view, and most of the major apps have skipped out on offering dark mode)
So, for margin and padding, one should use px? Or is there a better unit?
I tried using a bunch of zoom on my most frequented sites and they mostly worked just fine. At my day job everything is tested to work at 200% zoom as a baseline.
I really don't think we should bend over backwards to cater to accessibility offenders such as LinkedIn.
Express the header text size with CSS calc function with a sum of em (relative) and px (absolute) values. Depending on their ratio, element will be more or less scalable. 100% em -> scales like body text, 100% px -> no scaling.
"The new CSS env(preferred-text-scale) variable provides a mechanism for authors to respect the user’s text scale setting that they’ve set either in their operating system or web browser settings. Authors can use it to scale the font-size and alter the layout accordingly.
Note: See the env(preferred-text-scale) Explainer [2] for a comparison of the various ways users can scale content and examples of how to use the environment variable.
However, if authors have already used font-relative units like rem and em to conform to the Resize Text guideline, the browser could automatically incorporate the OS-level text scale setting into those font-relative units. This would allow authors to avoid having to determine the precise elements to apply the env() variable to.
We propose a new HTML meta tag that tells the user agent to apply the scaling factor from env(preferred-text-scale) to the entire page. We expect it will become best practice for authors to use this meta tag, just as they would use the viewport meta tag. The environment variable would be reserved for atypical use cases."
There's no need for a text-scale CSS property because font-size already exists. The latter explainer [2] suggests that developers use font-size: calc(100% * env(preferred-text-scale)) to get the desired effect, if they are doing this in CSS rather than with just the meta tag.
[1] https://github.com/w3c/csswg-drafts/blob/main/css-env-1/expl... [2] https://github.com/w3c/csswg-drafts/blob/main/css-env-1/expl...
And now just like with the viewport meta tag, we need a meta tag to say, 'Stop doing that please. Make the default font size in my CSS work the way it always should have'.
The other reason why the flag can't be in CSS is because it needs to make em and rem units in media queries get affected by the user's text scale. See the explainer for more info on that.
In other words this is going to make things worse for exactly the group of people it purports to help.
Just one more reason I think the web is a dumpster fire, I guess.
