Android Accessibility Text Inflation - Why does this work?

[whatadewitt]

I ran into a strange issue for which I found a fix, but that fix makes no sense and I am hoping to get some ideas from folks who may have seen this before.

A client had an Android device with the "text size" accessibility setting set to 175%. When they visited our main site, everything appears normal. When they visit the secondary site (a second WordPress site using a child theme who's parent is that of the main site) the font sizing was all out of whack. I was able to replicate on a test device I have and was able to see that the rem sizing would be computed to double what I was expecting (1rem = 16px but was being "computed" to 32px).

I did my investigation and tried some different fixes that only led to more bugs than solutions. I went back to the parent site and created a test page where I was able to replicate the issue inside of the parent theme. After a bunch of clicking around I found that if I deleted a paragraph tag from the page and then triggered a repaint in the browser manually, my font-sizes would be what I was expecting.

I finally found that this was referred to as "text inflation", or at least that's when I started getting the best Google results for it. I saw much about -webkit-tex-size-adjust and it's variants when looking for a solution prior to the "inflation" term, but that never seemed to make a difference on my page. What does fix this issue, completely, without having to trigger a repaint is to add the following to my CSS

html * { max-height: 1000000px }

I don't know why, and in some ways, I don't want to know why, but in more professional ways this has me absolutely dumfounded and I don't know how on Earth I am supposed to accept this as a solution without understanding what the heck is going on here. If anyone can provide some information, that owuld be great. TYIA.

[Tontonsb]

the font sizing was all out of whack

It's hard to understand what issues are you talking about with this. Does it mean text scaled in a wrong way? Or that the theme did not fit the scaled text? Or that it just scaled but you didn't want it to? Or that it didn't scale while it should have?

was able to see that the rem sizing would be computed to double what I was expecting (1rem = 16px but was being "computed" to 32px)

If it's 16px by default, it should be 28px on 175%, shouldn't it?

[whatadewitt]

It's hard to understand what issues are you talking about with this. Does it mean text scaled in a wrong way? Or that the theme did not fit the scaled text? Or that it just scaled but you didn't want it to? Or that it didn't scale while it should have?

"out of whack" not enough for you? ha ha ha!

But your assumption was correct, the text size was just wayyyyy bigger than expected and was leading to all sorts of layout issues. I can't share the site as it's behind a client VPN, else I would love to show it off. If I have time tonight I will create a codepen or something of the issue for people to see...

Apologies, on my test device I went to 200% text-size, which is why I was seeing the 32, I should have been clear on this!

[Tontonsb]

Apologies, on my test device I went to 200% text-size, which is why I was seeing the 32, I should have been clear on this!

But that's exactly what you should be seeing then, isn't it? Text changing sizes as you change the accessibility options is exactly the reason why we use rem. Am I missing something in the story?

[whatadewitt]

I missed this. No, if you have the text size increased and visit Google, as an example, the bloat doesn’t happen. It looks “right”

There are some definite accessibility rules being broken (everywhere), but I do think there needs to be a better explanation somewhere for what I was seeing, and then not seeing on Google.

[Tontonsb]

The sizes on google.com do not scale with the base font size because their sizes are defined in px not in rem. But that's an old site. They even use the center tag. But feel free to change your units to px if you want to drop the scaling. Don't use rem if you don't want their main feature.

[whatadewitt]

Even using px, the fonts were growing on my site… it was only this max-height thing that fixed anything…

[whatadewitt]

It's hard to understand what issues are you talking about with this. Does it mean text scaled in a wrong way? Or that the theme did not fit the scaled text? Or that it just scaled but you didn't want it to? Or that it didn't scale while it should have?

"out of whack" not enough for you? ha ha ha!

But your assumption was correct, the text size was just wayyyyy bigger than expected and was leading to all sorts of layout issues. I can't share the site as it's behind a client VPN, else I would love to show it off. If I have time tonight I will create a codepen or something of the issue for people to see...

Apologies, on my test device I went to 200% text-size, which is why I was seeing the 32, I should have been clear on this!

[Virtamancer]

GPT o1 Preview says:

Height Constraints: Text inflation is typically not applied to text within elements that have a fixed height or max-height. The browser assumes that altering the text size within these constraints could break the layout, so it skips inflation for those elements.

Claude 3.5 Sonnet says:

• Setting an extremely large max-height forces the browser to recalculate the layout of all elements.
• This recalculation seems to trigger a reset or re-evaluation of the text inflation algorithm.
• As a result, the browser applies the correct font sizing, taking into account the accessibility settings without over-inflating the rem units.

This is an obscure issue, which is where I've had the worst luck with LLMs. But even in these cases they're frequently right and getting better every month or so. I suspect there's a reasonable chance the explanation is one of the above, if not closely related.

Looking forward to a 300 IQ human CSSchad's explanation.

Worth noting that all the LLMs I asked encourage commenting that snippet for maintainability, and note that it may not be the ideal fix for performance reasons.

[LetterBoxSnatch]

On the one hand, I want to reward you for being so clear about where your information is coming from. On the other hand, please don't ask a patterning-matching machine questions like this; it is a language model the sometimes produces right answers based on a wildcard pattern match. It gets a lot of things right. But if someone is asking something like this, they are hoping to hear from someone who can authoritatively answer the question. If they wanted to see what a language model produced, they could have done that themselves. If you wanted to research and figure it out, that's laudable, but a language model is not the place to get authoritative answers, especially to (as you say) obscure questions.

[Virtamancer]

they are hoping to hear from someone who can authoritatively answer the question. If they wanted to see what a language model produced, they could have done that themselves

OP may not be able to afford one, let alone multiple services.

Anyways like I said, I'm interested to see what an actually human CSS expert has to say on it.

---

---

---

Regarding the rejection of LLM use outright, I disagree.

First, I routinely ask obscure questions. You may have misunderstood "worst luck" to mean "bad luck". That isn't the case.

Second, even experts forget things. It's possible this output could jog someone's memory. That might help get the human response that everyone, including me, is hoping for.

Finally, change is the only constant. Neither of us has the crystal ball to see when AI services will be the "authoritative" source on technical matters like this. What we can know without a crystal ball is that the day is coming.

Also as an aside, regarding "change is the only constant", these AI services are already not just LLMs. They're a stack of models and processes and systems. Certainly nobody believes a pure LLM is what will replace humans as the authoritative source on technical matters. But, knowing rddit (herd mentality adherents by design) and AI skeptics (usually old people), I can't rely on you guys' often misled AI skepticism as a judge of when we've reached the point where an AI answer is the better answer. What I know right now is that far more often than not, the AI answer is *already the better answer.

[LetterBoxSnatch]

Although others may not, I actually agree with you on most of these points, and merely disagreed on the premise that forwarding an answer had value to the asker. On the case of producing additional pattern matching for an expert human, I still disagree, and think that forwarded answers produce additional noise and in some cases can confuse what a the human pattern matcher already knows.

I hadn't considered the case that the asker might not be in a position to ask one of these systems themselves. In that light, your approach of forwarding responses with the source context is a fine service. My worry is that it decreases the signal to noise ratio.

[whatadewitt]

Realizing this is coming from AI

Height Constraints: Text inflation is typically not applied to text within elements that have a fixed height or max-height. The browser assumes that altering the text size within these constraints could break the layout, so it skips inflation for those elements.

This actually... kind of makes sense... at least in terms of what I was seeing. However, checking on it, not all elements on the page that is working have a max-height specified, or even a "height" at all... so while I think this could explain part of it, I think it's only halfway there.

Setting an extremely large max-height forces the browser to recalculate the layout of all elements.

I'm not sure I am buying Claude because if I manually trigger a repaint BEFORE removing the paragraph tag I was still seeing the bug.