Is this an Accessibility thing? Copilot says yes, but is it?

Learn
1

Hi,

I have an issue in an app when viewing it on a phone in landscape. The issue is that some of the text on the page is increased in size by the browser when an animation is activated on the page. I have discussed it with Copilot, and we came to the conclusion that the text gets it’s visible size increased when the DOM is being redrawn, and according to Copilot the DOM redraw is activating the Browsers’ accessibility features, which automatically increases the font size of some of the text on my page.

According to Copilot, this accessibility feature is only active in Landscape mode on Phones, and is more pronounced on IOS than Android phones.

So my question to the Accessibility buffs out there, is; Is copilot correct, if so, how would you recommend I handle this? I’ve not even seen this ‘feature’ before when browsing on my phone, this is the first time I’ve encountered this, so I’m guessing there is a way to handle this so that it doesn’t break my UI, or maybe I need to re-think my UI layout?

Extra Info

I am using ElmUI, and the affected text is inside an Element.paragraph, there is also a lot of unaffected text instances that are inside an Element.el only. I have tried Element.paragraph [ ] [ Element.el [ ] <| Element.text “..”] but it still gets increased in size by the browser.

Copilot suggests that the way an Element.paragraph is rendered by ElmUI is tripping up this Accessibility feature, which is why Element.el’s are left alone.

There are two types of animations on the page. Some are simple animations on buttons, checkboxes etc, and are created with @andrewMacmurray ‘s wonderful SimpleAnimation package, and some are more complicated animations that run with onAnimationFrameDelta.

If I remove the simple animations, so that clicking a button or checkbox simply changes it’s state without animating from one state to the next, then the whole issue goes away - until the onAnimationFrameDelta animation is activated by the user

Edit: There’s a video showing the issue here: https://youtu.be/wofzuZ2e8Uo

2

It’s hard to tell what is happening without having some code example.

But in general, yes, different paragraphs may render in different sizes on phones. That’s not something special to elm, that’s just how the phone computes the font-size. The easiest fix is to specify the font size (setting it to 1rem on the outermost element should be enough).

Elm.paragraph might have something like that set by default, whereas Element.el will most likely not have set anything. So I’m assuming that that might cause the issue.

Regarding accessibility, it’s somewhat related. Generally you want your font to be set in rem not in px, because rem is in relation to the native font-size of your phone (older people might have a bigger font size). If nothing is set it usually defaults to 1rem= ~16px, but then again, I’ve seen the exact behavior happen to me as well. I assume that some phone browsers change the default font-size to fit the paragraphs on the screen, but that’s just guess work.

1 Like
3

I’ve uploaded a video displaying the problem here: https://youtu.be/wofzuZ2e8Uo

You’ll see that in Landscape mode, clicking a checkbox causes the text to increase in size, while doing the same in Portrait does not.

The text in question is rendered with:

El.paragraph
    [ El.width El.fill
    , El.paddingXY 10 0
    , Font.size 12
    ]
    [ El.el [ Font.size 12 ] <|
        El.text "..."
    , El.text "..."
    ]

(I know 12 is small for mobile devices, I’m using it to highlight the problem. I’ve tested on font sizes up to 20 and the same thing happens for all)

Setting Font.size 12 is not being respected by the browser after the checkbox is clicked, and as I’m setting it directly on the paragraph and the elit can’t be overridden by any Elm code that I write.

If I remove the css animations (created with Elm-Simple-Animation) from the checkbox, then the problem goes away and the text does not increase in size when clicking the checkbox. So it appears that activating the css animations is causing this :man_shrugging:

Edit: I’ve also tested on a real device, and the same issue occurs

4

I haven’t heard of andrewMacmurray/elm-simple-animation before. I just took a quick look over the documentation, but I can’t tell for sure how it works. It might as well change something in the DOM structure, that breaks your styling.

5

Wild guess, but is it possible that both are generating a class with the same name and those classes clash?

6

I’ll check the DOM to make sure, but if so, then the issue would also show up in Portrait as well wouldn’t it?

This is the weird thing, it only happens in Landscape on a Phone. All other devices and orientations are fine, and I’m not doing anything special for Phone/Landscape, in fact it’s layout is rendered the same as Tablet, and Tablets render correctly.

7

Elm-Simple-Animation creates css animations inline in the DOM as so:

Screenshot 2025-09-03 at 19.07.31
Screenshot 2025-09-03 at 19.07.31716×344 33.2 KB

8

Additional Info

Here’s the last summary from Copilot:

Summary:
This is a browser/platform quirk, not a bug in your code. Any redraw after user interaction can trigger iOS font scaling, but device rotation resets it. Use larger font sizes and avoid small text in interactive/redrawn elements to minimize the issue.

The problem is, this issue affects font sizes upto 20px, increasing them to about a 22px default, so to avoid the issue I’d have to use a font size greater than 20px which is too large. Ideally, I don’t want to go above 18px for paragraphs of text as this feels large enough for small hand held devices.

And as I haven’t seen this browser/platform quirk in the wild, (if Copilot is correct), I’m assuming there’s a way to work with it rather than against it, I’m just struggling to understand how at the moment. I’ve done loads of animations in previous projects with ElmUI, and never seen this before…

9

So I have seen something similar-ish before but wouldn’t think it’s related (maybe it is?) with select inputs not redrawing until they’re interacted with. Like what you’re describing, it was a browser thing and not a framework thing. Mine was for something that went no where so I didn’t do too much research.

My “thinking out loud” thoughts

  • is this super important to fix? I feel like people aren’t rotating their devices that often
  • is it possible to fake an interaction to trigger the scaling?
10

It’s not about rotating the device, it’s an issue when a phone is in landscape only, and this particular page is displaying a feature table which users may well choose to use landscape in order to view all the columns.

Why do this? The last thing I want to do is trigger the scaling(?).

I think I’ll spend some time on it tomorrow and re-think the design. I’m guessing Copilot is right and its a browser/platform quirk, so that’s looking like my only option unless anyone has any more thoughts.

Thanks @wolfadex & @Lucas_Payr for trying to help.

11

Thanks for showing that, it is very interesting and seems really odd that ios would implement something like that - what result were they intending to achieve by doing this, I wonder?

The difference between your animations seems to be: CSS animations do not cause the problem, animations implemented by code do cause the problem, since they trigger a DOM redraw.

I think if you are targetting phones, sticking with CSS animations is a good idea, since they are also more likely to be well optimized by the browser, and therefore run smoothly/consume less power.

My only suggestion is, have you tried putting a !important on the font size? Just maybe that will be enough to enforce it.

12

Thanks Rupert,

How would I add !important with ElmUI? (Is it even possible? :man_shrugging: ) I’ve tried the following:

El.htmlAttribute <|
    Attr.style "font-size" "12px !important" -- Font size is ignored

El.htmlAttribute <|
    Attr.style "font-size" "12px" -- Font size is respected

Just to clarify, I’m using elm-simple-animation 2.3.2 which creates inline css animations, these are causing the problem, along with coded animations with onAnimationFrameDelta.

My understanding, which may be wrong, is that this is because they cause part of the DOM to be redrawn, and it’s this redraw that appears to trigger this particular quirk.

I’ll try defining the css animations and font sizes (with !important) in vanilla CSS later and see how that plays out.

13

I saw a similar thread popup under this post created by yourself a few years back and wondered if the solution posted there fixes the issue? I.e. adding this to the page:

html {
    text-size-adjust: 100%;
    -webkit-text-size-adjust: 100%;
    -moz-text-size-adjust: 100%;
}
3 Likes
14

Oh wow, nice catch, that’s exactly what was needed, thanks :+1: