Re: [csswg-drafts] [css-fonts-5] <meta text-scale> limits (#13557)

Sorry, I wasn't aware of this issue until after it came up at the F2F.

At the BBC, we disagree with the resolution to clamp the text scaling to a value specified by the author. My understanding of the resolution is that: if the `meta` tag is set to 32px (200%), for example, then the UA will not set the default font size (i.e. the value of `medium`) higher than 32px, even if the user has scaled up to 300%.

## Concerns

While we agree that getting the author to think about a maximum supported text scale might be an effective forcing function, we have the following concerns:

### Limiting an accessibility setting

At the BBC, because of [our accessibility principles](https://www.bbc.co.uk/accessibility/forproducts/guides/mobile/principles/), we fundamentally believe that authors should not limit users accessibility preferences. So in the case of text scaling, we believe if users with major visual impairments need to set an extreme text scale like 400% in order to be able to read the content, it is better for them to receive that with a broken page layout than for them to not be able to read it. We know from our own research that there are users who do this.

Therefore, we consider the [WCAG2.2 guideline 1.4.4](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html) to support 200% resized text a _minimum_. I'd be very concerned that authors copy and paste `<meta name="text-scale" content="200%">` onto their website and assume their work is done. That means we could have a proliferation of websites only supporting the bare minimum of 200% text scale.

Or what would happen if authors just set `<meta name="text-scale" content="100%">` to prevent text scaling entirely, like how the `<meta viewport>` tag is sometimes set to disable pinch-to-zoom? (I realise authors can effectively do that anyway by setting `:root { font-size: 16px; }`.) Do we want authors to be able to do that?

### A backwards step for desktop users

Also, how would this resolution affect text scaling on desktop? Right now, even without the `<meta text-scale>` tag, users can increase the default font size on desktop browsers to whatever they want. So right now in Firefox, if I enable 'text only zoom', I can scale the text up to 500%. If the author limits text scaling to 200%, what happens on desktop? That would be a more limited experience than what desktop users can do _now_.

### How will websites break?

I'm curious to know what are the website issues that we are concerned about for extreme text scales. In my experience, a website that is designed to work with text scaling will generally not break at extreme scales (except when there's no room in the viewport for long words), provided that authors are following best practices. For example:

* avoid setting fixed heights on boxes containing text
* define media queries for responsive layouts in font-relative units rather than `px` so that they adapt to the text scale
* use a single column layout for all content on very small viewports with high text scales

_Hopefully_ authors are going to be taught to follow these best practices if they choose to add the `meta` tag to their site.

## Counter-proposals

I suggest we could either:

* Revert the resolution and accept the risk of broken layouts
* Instead of clamping the text scale, have the UA display a warning if the text scale is above the author-defined limit (suggested by @davidsgrogan)

@fantasai I saw in the minutes of the call, you mentioned '...and the engine can use other methods to zoom past [the meta tag px value] if necessary'. What did you have in mind for this. I didn't see it discussed since you mentioned it in your introduction. 🙂 

I'll add this to the agenda.

-- 
GitHub Notification of comment by JoshTumath
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13557#issuecomment-4214540289 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 9 April 2026 13:22:14 UTC