Sv: [EKSTERN] Re: Proposal: Allow or require capping maximum text size in high-zoom scenarios to prevent disproportionate enlargement (related to SC 1.4.4 and 1.4.10)

Hi Alastair,

I'm extreemly glad to hear that the topic is already a concern.
It truly breaks my UX heart to see rules like these causing so much damange.

But to answer your question.
I would say that the heading size differences is less important than heading sizes breaking layout of the site entirely, and  im also surethat this can be solved with some math and css clamp magi.

So the value of heading size diffrences is significantly lower in terms of UX. Where having a heading with 320px would be a very bad experince for everyone and it is a gurantee it will disable all user to read headlines properly.

Anyway. I just had to vent my daily struggles of the manatory WCAG compliance standards that we HAVE to follow.

Im just gonna leave this image here, to speak for itself. - Thanks for listening 🙂

[cid:9ecd5037-6286-4184-818f-d95cc01311fd]
________________________________
Fra: Alastair Campbell <alastair.campbell@thisisgain.com>
Sendt: 11. februar 2026 12:52
Til: Kristian Højlund Bangsø <C588@kk.dk>; public-agwg-comments@w3.org <public-agwg-comments@w3.org>
Emne: [EKSTERN] Re: Proposal: Allow or require capping maximum text size in high-zoom scenarios to prevent disproportionate enlargement (related to SC 1.4.4 and 1.4.10)

Hi Kristian,

We have had similar comments in the past:
https://github.com/w3c/wcag/issues/4730

https://github.com/w3c/wcag/issues/1671


In WCAG 3 we are looking at a requirement that would be 200% of the platform default body-text size, assuming we can define that well enough.

One issue to note is that when headings get capped, you might lose information. E.g. if the H2 - H5 are all the same size, how do you differentiate? There is a new (proposed) requirement about that.

Kind regards,

-Alastair


From: Kristian Højlund Bangsø <C588@kk.dk>
Date: Wednesday, 11 February 2026 at 11:42
To: public-agwg-comments@w3.org <public-agwg-comments@w3.org>
Subject: Proposal: Allow or require capping maximum text size in high-zoom scenarios to prevent disproportionate enlargement (related to SC 1.4.4 and 1.4.10)

You don't often get email from c588@kk.dk. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

Dear WCAG Working Group / W3C Web Accessibility Initiative,



Firstly, thank for all the great work, making the internet more accessible.



I am writing to propose a consideration or potential enhancement to the WCAG guidelines regarding text resizing, particularly in relation to Success Criterion 1.4.4 (Resize Text) and 1.4.10 (Reflow).



Current requirements ensure that text can be enlarged up to at least 200% without loss of content or functionality (and reflow at equivalent 400% zoom to avoid two-dimensional scrolling). This is excellent for users who need minimum enlargement. However, there appears to be no guidance on maximum text sizes, which can create usability issues in practice.



Consider this example (assuming a default browser font size where 1rem = 16px):



Default view (100%):

Body text: 1rem (16px)

Headline: 10rem (160px)



At 200% text resize/zoom:

Body text: “2rem” (32px)

Headline: “20rem” (320px)



At 400% zoom (common for reflow testing and high-magnification needs):

Body text: “4rem” (64px) -> We assume that everyone can read this, since it is 16px base (recommended minimum) x 4 (400%).

Headline:”40rem” (640px) -> If 64px is readable, why can’t is set a cap on 64px or even 100px, if we assume 64px is readable, based on your standards.



The core question:

If WCAG deems 64px body text (4× the base) readable and acceptable at high zoom levels, why not allow us to enforce a maximum cap (e.g., via CSS max() or clamp()) at or around that effective size for body text, while still meeting the minimum 200% enlargement requirement?

Without such a provision, developers and designers are effectively discouraged from setting any upper bounds, which can degrade the experience for low-vision users who zoom heavily but prefer or need more controlled sizing. This seems to contradict the goal of usable, readable content at enlarged scales.



Success at SC 1.4.4 and 1.4.10 should be achievable even if authors apply a maximum text size limit (e.g., no text exceeds ~4× the base/default size, such as 64px for a 16px base), provided the minimum enlargement to 200% is still possible without loss of content/functionality.

This could be an advisory technique, an exception, or a new success criterion to balance minimum enlargement with preventing excessive enlargement.



I believe this would give the creators more flexibility to optimize for real-world readability without risking non-conformance.



Again, thank you for your work on WCAG and for considering this feedback.

I would appreciate any thoughts on whether this has been discussed before or if it aligns with ongoing work (e.g., toward WCAG 3)…



Disclaimer

I am not writing on behalf of the Municipality of Copenhagen; I’m merely sharing my personal struggles and experience as designer and developer.



Best regards,

Kristian Højlund Bangsø
Web udvikler
Udvikling og Teknologi
_________________________________________
KØBENHAVNS KOMMUNE
Økonomiforvaltningen
Koncern IT

Borups Allé 177, 2, A
2400 København NV

Mobil 2113 7729

Telefon 7080 8077

E-mail C588@kk.dk<mailto:C588@kk.dk>

EAN 5798009809056



Læs om, hvordan Økonomiforvaltningen behandler personoplysninger (åbner på kk.dk)<https://www.kk.dk/om-kommunen/databeskyttelse/databeskyttelse-i-forvaltningerne/databeskyttelse-i-oekonomiforvaltningen>