Can large headings be exempt from Success Criterion 1.4.4 Resize text?

[simevidas]

A website might use fluid typography with the CSS clamp() function and viewport units. See “Fluid typography with CSS clamp” for code examples and demos.

If the page’s main heading has a font-size of 80 pixels at 100% zoom, and then the user zooms the page to 300% (the max zoom in Firefox), the heading may be only 1.5 times larger (instead of 3 times larger) because of fluid typography.

See this demo: https://codepen.io/piccalilli/project/full/48cfe24e498546cefdcae45bddecff46

If I’m reading the spec correctly, 1.5 times larger is not enough to pass the Resize Text success criterion. However, since the heading is already very large at 100%, it may not be necessary to make it twice as large.

I have received a few comments on Twitter in this discussion, and the general consensus seems to be that the above scenario should not be a fail. However, I could not find anything about large text being exempt in the spec and related guides.

Could you clarify if Resize Text should apply also to text that is very large to begin with?

[JAWS-test]

Even if a heading is sufficiently large, I don't think there is an exception in SC 1.4.4 that it doesn't need to be enlarged to 200%. I think a corresponding exception is reasonable. The only problem I find is the following case: If headings stand out from the text only by their size, but do not scale when zoomed because they are already large, it can happen that at a certain zoom level text and heading are the same size. Then the headings are no longer well recognizable as such

In SC 1.4.10 there is such an exception. 400% zoom is not necessary for large text content.

[alastc]

Could you clarify if Resize Text should apply also to text that is very large to begin with?

It does apply, we can discuss whether it should :-)

Initially (thinking back to WCAG 2.0 in 2008) there was no mechanism to vary text based on screen-size or zoom-level, so this wasn't a question.

I think the Low Vision Task Force considered various criteria as we were coming up to WCAG 2.1, and they were all in the category of increasing the requirements, not capping them. From that I assume that text being too large was not an issue for them.

We have another issue (#704) which goes into a lot of details about how you (might) need to get to 200% from whatever starting point you are at. E.g. even if your screen is 600px wide to start with, you should be able to get text to 200%. So for each break-point ("page variation") you should be able to zoom to get 200% text.

I have a lot of sympathy for there being scenarios which are more constrained now, e.g. navigation bars on mobile apps. I've been thinking about something for WCAG2ICT (and/or WCAG 3.0) which requires you can get to 200% of the default body-text, rather than the starting point of the text.

[mraccess77]

Text being too large was not an issue for them.

This was something we discussed in WCAG 2.1 by the low vision task force and is an issue for users - but it wasn't something that had an easy solution.

The focus with SC 1.4.10 in WCAG 2.1 was not directly about making the text larger but about support reflow of text for reading. The provision effectively allows for increase (as that is often necessary up to 400% or even 1000% of text but doesn't specifically require it beyond the 200% from SC 1.4.4. For folks with limited fields too large of text is problematic and having a heading take up much of the page may not be as helpful. What is needed is having proportions of size and other markers to understand the relationship of headings, etc. Ultimately I believe something like @alastc mentioned with a percent of the default body may be of use as long as there are other methods of distinguishing content other than size.

[alastc]

Thanks Jon, I've modified my comment above to be less categorical, that wasn't justified.

[mitchellevan]

I agree with what's been said here about WCAG 2.x. I'll add that today 150% sized heading text could meet the functional performance criteria of US Section 508 as an instance of equivalent facilitation, if it provides "substantially equivalent or greater accessibility and usability by individuals with disabilities than would be provided by conformance". It's a similar concept to functional needs in WCAG 3.0.

[scottkellum]

I just created a very similar issue here: w3c/wcag3#261, thanks @JAWS-test for linking

In my findings, it isn’t just fluid typography that is to blame for non compliance with this, but smaller screen media queries are far more often the culprit.

Additionally, this brings up a bit of a paradox. If 200% zoom makes it so words no longer fit in the viewport, this results in another issue for readers and the failure stated outlined on https://www.w3.org/TR/WCAG20-TECHS/F69

In my opinion the failure state of text overflowing a container or viewport should be avoided and an exception should be provided to 1.4.4 to ensure that doesn’t happen. People already make this affordance with media queries and fluid typography which is why headlines so often fail. They don’t do this to make the text less legible, they do it so text will be more legible and words won’t break off of the page.

[scottkellum]

Additional note. Again this isn’t really compliant but I also scale the body text down on very small screen sizes where words might be truncated. So my website will be legible on watches. This probably goes against the letter of some accessibility rules, but I feel like it follows the spirit. Apple automatically does this to websites on the Apple Watch, but that setting can be overwritten and custom styles can be applied.

When words don’t reliably fit in the viewport, I make an affordance to scale that text down in my work regardless of compliance guidelines as I feel like this follows the spirit, but not the letter of these rules.

[mraccess77]

For content that is already 200% of the body default like headings I'd rather they be kept at size or wrapped rather than enlarged and truncated. For content that is not large enough - I'd rather it be enlarged and wrapped then scaled down. So wrap when you can and when you can't some enlargement is often better than truncation.

[JAWS-test]

@scottkellum

SC 1.4.4 requires that any text can be enlarged to 200%, regardless of its initial size. Of course, it is better not to enlarge large text at 200% browser zoom rather than to display it truncated. But then 1.4.4 is still not fulfilled.

I'm not sure if 1.4.4 requires that at 200% browser zoom, the text must be enlarged to 200%. It may also be sufficient that only at 300% browser zoom the 200% text magnification is achieved.

By the way, 1.4.4 does not require that the same text size is used on every display width. Small text on small displays is ok. The only important thing is: No matter how big the display is - it must always be possible to enlarge the text to 200% on the display (see the third note at https://www.w3.org/TR/WCAG21/#cc2).

The whole thing then becomes even more complicated because SC 1.4.10 also applies, which requires 400% zoom without horizontal scrolling, but excludes large font (this must be enlarged to a maximum of 200% at 400% browser zoom). However, 1.4.10 only applies to the fixed screen width of 1280px and not to all screen widths as 1.4.4 does.

[scottkellum]

Thanks @JAWS-test. I think I understand what SC 1.4.4 is saying. The issue is
that this creates numerous scenarios where compliance is a worse and less
accessible user experience. This seems to be the scenario 1.4.4 is written for.
It’s straightforward and makes sense here.

A pretty standard and relatively styled page at 1024px wide.

That same page scaled up 2x looks pretty much how one might expect it to look and is compliant with 1.4.4.

---

If a designer wants to have a big headline on the page, then 1.4.4 starts to
become an issue. Even though the headline is bigger than the previous example
when not scaling the text up at all, it fails 1.4.4 for not being big enough. If
you do make it big enough to satisfy 1.4.4, then the headline clips off the
page. The result of 1.4.4 seems to be to have designers make headlines smaller
so that they can be scaled up with browser zoom instead of letting designers
work with big headlines, that in a lot of ways are more legible.

Scaling all text 200%	Scale the text, but not the headline
A page at 1024px wide with a big headline.	A page at 1024px wide with a big headline.
All of the text, including the headline, scaled up 200% resulting in clipping.	The headline remains the same while the body text increases to 200%. Note that this is still a much larger headline than the compliant example in the previous table.

---

To recap, let’s compare 200% views of the 1.4.4 compliant and non-complaint
examples.

1.4.4 compliant at 200%.

Not 1.4.4 compliant at 200% because the headline here is too small.

---

Before any rule gets made that non-scaling is ok as long as headlines larger
than 200% the body copy remain larger than 200% the body copy, but are allowed
to scale down to 200%. It should be noted that 1.4.4 still applies to any
and all viewport sizes. This would leave most small screen designs
non-compliant.

A 240px wide viewport with a headline 200% the body size.

Scaled up 200%, the headline does not fit in the viewport anymore and I would recommend it be scaled down beyond 200%.

---

If you look at watch sized screens, these issues with headlines start to become issues with body and paragraph text as well.

---

TL;DR

There are lots of edge case implications in 1.4.4 that result in severe legibility issues and unnecessary design complications when it is complied with.

---

Recommendation

I would recommend specifying that at 1280px, a 200% zoom
results in a 200% increase in body and paragraph font sizes. All text larger
than the body and paragraphs must remain larger at 200% zoom. All text smaller than
body and paragraphs must also increase by at least 200%.

[JAWS-test]

@scottkellum

I completely agree with you.
However, as far as I know, the following applies:

• Unfortunately, SC 1.4.4 of WCAG cannot be changed retroactively (that is until WCAG 3.0 is released).
• Only the Understanding documents can be modified.

It would therefore be worth considering whether a corresponding exception for large type can be formulated in the Understanding for 1.4.4, as is already the case for 1.4.10.

[masi]

My real world experience:
I had sites where the running text is 20px and the headings are as in the examples given here much larger (expressed in em assuming 16px default font size). To accommodate for text zooming I had to add breakpoints that decreased the ratio with increasing zoom factor.

Is my solution in line with 1.4.4?

[patrickhlauke]

@masi no. the whole point is that some users need text to be bigger because they have low vision. what you're doing is explicitly counteracting their attempt at making the text bigger by reducing it again.

1.4.4 does not have any normative exceptions. it doesn't say anything about "text needs to be at least zoomable to X size", or "if it's already at X size, it can remain at that size and not zoom further". as @alastc said early on in this thread, there are certainly separate arguments to be had about whether WCAG should provide these upper bounds or not, but the current situation with 1.4.4 is that there's no exceptions.

[masi]

@patrickhlauke it's IMHO impossible to scale a H1 of 60px (yes, that's what the designer asks for) to 200% without issues with 1.4.10 Reflow when the language tends to have long words like German.

I agree that the current wording allows no other interpretation of the text. Then end result is IMHO only that the site will fail to reach AA either because it will break at either 1.1.4 or 1.4.10.

Sidenote: In the quoted example the H1 is 3 times larger than the running text.

[patrickhlauke]

oh i agree that the interplay between 1.4.4 and 1.4.10 can be problematic in real-world situations. the whole issue of changes at different viewpoints has been raised a few times in the past (last time in #704 which alastair referenced already). sadly, normatively it is what it is for WCAG 2.1 (and most likely 2.2 as it's late in the day to make further fundamental changes there I think). Maybe 2.3, as this would seem a backwards-compatible sort of thing to tackle (i.e. if you passed this in 2.1/2.2, you'd be able to also pass it in 2.3 - but obviously if the requirement is relaxed with exemptions, it won't work the other way around).

[masi]

And not to be misunderstood: I don't argue, because I am a lazy developer. I sincerely wish to create truly inclusive websites. I'm sometime only frustrated if my good intentions clash with rules that have been created with good intentions.

Personally I can live with a good solution even when I know that I had to bend the rules a bit. Things get a bit complicated though if an a11y audit requires me 100% compliance.
I hope that 3.x will be relaxed enough to deal with edge cases without watering down the core values.

[scottkellum]

@masi Issues with 1.4.4 are what we are talking about in this thread. You initially asked if your first post in this thread if your implementation was 1.4.4 compliant. @patrickhlauke answered correctly that no, it is not.

But I think the question for this thread is not if it is compliant with 1.4.4, but if there should be an affordance made for implementations like this and bringing up the dissonance between 1.1.4 and 1.4.10 is extremely helpful!

[detlevhfischer]

Draft proposal for a normative change:
OLD:

Success Criterion 1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

NEW:
Success Criterion 1.4.4 Resize text: Except for captions, images of text and large text that after resizing remains larger than adjacent smaller text resized to 200%, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

[patrickhlauke]

large text that after resizing remains larger than adjacent smaller text

so presumably "large text" would be this? https://www.w3.org/TR/WCAG22/#dfn-large-scale

essentially saying, in a different way, that if it's large text, it's ok even if it doesn't resize at all, as long as its visual hierarchy is preserved/that it's larger than "non-large text"? this assumes that "large text" is always large enough for users who would require text resizing? this seems to correct far too much the opposite way, i'd say.

Draft proposal for a normative change:

incidentally, is this just your idea @detlevhfischer, or is this the proposal coming from AGWG?

[patrickhlauke]

if the intent is indeed to exempt "large scale text", i'd propose something more along these lines

Success Criterion 1.4.4 Resize text: Except for captions, images of text, and large scale text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Note: while large scale text is exempted, the size difference between text elements used to convey visual hierarchy of content must be preserved even after resizing.

or perhaps, more understandably (if this is already doing a normative change, might as well reorganise it a bit more logically to a bullet format. something along the lines of

Success Criterion 1.4.4 Resize text: text can be resized without assistive technology up to 200 percent without loss of content or functionality, except for the following:

• Captions: ...
• Images of text: ...
• Large text: if the text counts as large scale text, it does not need to be resized. However, if the size of text is used to denote a particular visual hierarchy, the size difference between text elements must be preserved even after resizing.

additional note: i'd still like to hear from LVTF or similar if we're all ok with basically saying "large scale text is large enough and can be exempted". seems a bit sweeping as a statement of intent...

[scottkellum]

@patrickhlauke

the size difference between text elements used to convey visual hierarchy of content must be preserved even after resizing.

There are ways to preserve hierarchy without using font size. On many projects I increase the weight as I decrease font size to preserve hierarchy. That said, I almost always still have a slightly larger font size in these instances.

To define what large scale text is, I would suggest allowing text to be scaled down if it is at risk of overflowing its container. Maybe this is still too vague as different language and content parameters puts some implementations at a greater or lesser risk.

[patrickhlauke]

There are ways to preserve hierarchy without using font size. On many projects I increase the weight as I decrease font size to preserve hierarchy. That said, I almost always still have a slightly larger font size in these instances.

fair enough, so perhaps the wording (looking at my own versions there) should be more along the lines of

"if the size of text is used to denote a particular visual hierarchy, the difference in hierarchy is still visually apparent after resizing"

which leaves it open ended on how that's achieved.

To define what large scale text is

that is already defined in WCAG, so to define it again differently probably won't fly https://www.w3.org/TR/WCAG22/#dfn-large-scale

[mraccess77]

I oppose exempting text that is 18pt 14pt bold or larger from having to resize at all. 18pt is not even 200% of the default text size and is not sufficient in size for many users with low vision to read. Creating such an exemption to address specified situations weakens the whole SC - at that point why not just require resize up to 18pts/14pt bold if that's all people need - it's because real people with low vision need more. If we want to address the situation with large heading or other really large text then we'll need to come up with something that's already 200% of the default text size or more.

[masi]

@mraccess77 I agree 18pt/24px is nowadays not large. Has it been calculated as 2x the old 12px standard size? This would make 24pt/32px today.

How about a relative size in terms of the size used for running text?

Large text is considered any text that is twice the size of the running text.

[patrickhlauke]

How about a relative size in terms of the size used for running text?

"running text" is subjective though. depends on the type of page etc.

and again, it would start to be very confusing if WCAG had a definition for large text (used for color contrast SC), and then started using another "large text" definition for 1.4.4

[patrickhlauke]

Creating such an exemption to address specified situations weakens the whole SC

to be clear, i agree with you @mraccess77 ... i was just taking the proposed rewording to its logical conclusion here (unless it had some other intent that i missed)

[masi]

"running text" is subjective though. depends on the type of page etc.

While px are not subjective they are relative and depend on the ppi of the device. Meaning each definition has its drawbacks.

and again, it would start to be very confusing if WCAG had a definition for large text (used for color contrast SC), and then started using another "large text" definition for 1.4.4

A good point. To address the concerns of @mraccess77 that the WCAG's definition of large text isn't valid would have the addresses elsewhere.

Invent the term "very large text" defined as 24pt/32px (36pt/48px I'd call "huge")?

[patrickhlauke]

While px are not subjective they are relative and depend on the ppi of the device.

things are anchored to CSS pixels, which are resolution independent.

[masi]

While px are not subjective they are relative and depend on the ppi of the device.

things are anchored to CSS pixels, which are resolution independent.

I meant the real physical size. At least for my eyes it makes a difference if look at a 15" or 17" screen with the same pixel resolution. IMHO any talk about size is flawed if it does not take account of the physical measures. But that's only me.

[patrickhlauke]

actual physical size is outside of the ability of web authors to control. has been discussed at length in the past (same reason why it's not possible to define things like minimum target size in actual real-world "as measured on the screen" dimensions)

w3c/csswg-drafts#614

[masi]

actual physical size is outside of the ability of web authors to control. has been discussed at length in the past (same reason why it's not possible to define things like minimum target size in actual real-world "as measured on the screen" dimensions)

I had hoped that modern devices and operating systems would allow browsers to determine the physical size reliably. But obviously not, otherwise I would have seen suggestions to to use cm or inch in media queries.
As I understand the CSS thread historically reasons and compatibility issues hold back physical measurements. Perhaps I have to read it more thoroughly why it will never happen.

[detlevhfischer]

@patrickhlauke

incidentally, is this just your idea @detlevhfischer, or is this the proposal coming from AGWG?

The former. I find it vexing that I have to tell clients wanting to be on the safe side to reduce the default text size of key elements so they won't break unseemly at 200%, and wish there was some way to remedy this SC defect - whatever way. I don't mind referring to the large text def (I'll take anything) although I agree with @mraccess77 that it is on the wee side, and would prefer a relative phrasing, possibly qualifying my "remains larger than" by saying something like "120% size of the surrounding text" (so the size difference is noticeable). The problem is that different fonts can appear to be of quite different size at the same CSS px value, and we don't want to drag the issue of different fonts into it - so it remains difficult to find a solid basis to assess whether "the difference in hierarchy is still visually apparent after resizing".

[patrickhlauke]

I still think "surrounding text", "adjacent text", "body text", etc are just too vague as concepts. They work for most regular document-style pages, but can quickly fall apart in different real-world situations.

Am i right in thinking that the issue here is not so much 1.4.4 itself, but the interplay between 1.4.4 and 1.4.10? and that it's really the latter that is causing problems (as it should be fairly non-controversial to say that i should always be able to bump things up 200% - it's the dual "that, but also need to reflow at 320 CSS px" that's making life difficult)? i.e. if zooming any further at small screen sizes caused horizontal and vertical scrolling, that'd be fine/not cause problems for authors - but will fall foul of 1.4.10

[detlevhfischer]

I still think "surrounding text", "adjacent text", "body text", etc are just too vague as concepts.

Agree - I tried to rephrase my 1.4.4 normative text rewording proposal but wasn't happy so I deleted two comments here...

[mraccess77]

I would add that large scale text is build on the concept of default body size of text in WCAG - although I think we should be careful not to assume that large-scale as used to allow for a lesser contrast minimum is even relevant to the size of text in terms of reading efficiency as we may be mixing up two items that are not the same.

From WCAG 2.1
The actual size of the character that a user sees is dependent both on the author-defined size and the user's display or user-agent settings. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the user agent for display. The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.

[patrickhlauke]

we should be careful not to assume that large-scale as used to allow for a lesser contrast minimum is even relevant to the size of text in terms of reading efficiency as we may be mixing up two items that are not the same

and there's the rub...if we were to define a different measure of "large headings" rather than "large scale (text)", we'll end up with two different and confusing definitions. feasible, but not ideal.

[scottkellum]

I created a CSS WG issue around possible solutions to provide more control around page zooming and styles: w3c/csswg-drafts#6869

[trusktr]

actual physical size is outside of the ability of web authors to control. has been discussed at length in the past (same reason why it's not possible to define things like minimum target size in actual real-world "as measured on the screen" dimensions)

This is a white lie: it is true only because web browsers are not spec'd to give users such an API, therefore they do not implement such APIs.

I have been using real physical units for more than a decade in native frameworks like Qt. Native frameworks access display data using standards like EDID. Example code:

QSizeF screenSize = QGuiApplication::primaryScreen()->physicalSize();

The Qt docs say:

This property holds the screen's physical size (in millimeters)

The physical size represents the actual physical dimensions of the screen's display.

Depending on what information the underlying system provides the value might not be entirely accurate.

It is 100% possible in a reasonable way.

[patrickhlauke]

@trusktr it's 100% possible, if it was supported in today's browsers. as it's not, it's 0% possible at the moment.

[trusktr]

Sorry, yeah you're right about that. I was coming from the angle that, in the issue you linked, spec maintainers don't seem keen on adding support.

[trusktr]

There's some sort of friction with web spec authoring that doesn't line up with, for example, a simple API like the one in Qt.

[Myndex]

This is a white lie: it is true only because web browsers are not spec'd to give users such an API, therefore they do not implement such APIs.

Hi @trusktr

The fact that browsers (for the most part) only zoom by percentage is part of the problem the other part is that different browsers handle their zoom of the page or independently zooming text, in different ways and there's really not a standardization there.

And as some in this thread point out and which we've been talking about in the R&D for APCA for WCAG 3.0, zooming all text by a percentage does not serve the needs of users. There is a range of "critical font size" or, and in an ideal world I'll text would remain within that range for that user.

But additionally, 200% is not enough. The difference between 20/20 and 20/40 is 200%.

Low vision is considered somewhere around 20/70 to 20/80 and above, and technically, 20/80 is 400%.

Well, 400% doesn't really work on, say, an iPad in portrait mode or an iPhone in landscape mode. In fact 200% is really the limit for an iPhone in portrait mode, and this is only considering body text. Or talking about large headlines then they can't be anywhere near these percentages for mobile devices.

In this post in discussion 39 on use-cases at the readability forum, about halfway down is the section on spatial frequency (size) and zooming, and a link to some examples.

These show that if we really want to accommodate low vision, we cannot be zooming all text the same percentage, period. At the moment can't really be a guideline because the technology isn't there except for with a polyfill and we can't require a polyfill guideline. What we need is browsers to have get together on zoom.

[detlevhfischer]

Just adding a reference to the non-linear font scaling in Android 14:

• Google video on new Android 14 features: https://io.google/2023/program/dc29f421-2842-4838-bd87-1ac50f1ac00a/
• Android Developer, Android 14 New Features: https://developer.android.com/about/versions/14/features#non-linear-font-scaling

Non-linear font scaling means a scaling where text that is already large is enlarged less than small text. Assuming that SC 1.4.4 applied to apps is met by system zoom, this seems a sensible approach.

[mikemai2awesome]

Wanted to chime in with another use case. I believe something like layout masthead (think of newspaper name as the banner across the top of the page) should also be exempt. In such case, the text is always spanning full width of the viewport (until it hits the page max width), this is more about layout and not about content, the text would not be scaling with the browser font-size or zoom setting. So technically it cannot scale to 200% if actual text is being used here rather than an image or SVG.

[image alt: a side by side comparison of a design in 320px viewport and 1024px viewport. Both designs show a masthead that reads "newspaper". The text is set in a bold serif font.]

[kizu]

To cross-link it here, and to also ask for feedback from anyone who participated in this issue: I wrote a blog post about the “fit-to-width” feature that CSSWG resolved to work on, and Google Chrome sent an Intent to Prototype — https://blog.kizu.dev/fit-to-width-discussions-and-feedback/

It looks into the potential problem of fit-to-width failing SC 1.4.4, and how we can make the potential impact lower by having the range in which the text can grow to be 200% max by default (but overrideable for cases where the SC 1.4.4. won't apply).

In my opinion, I agree that large headings could be exempt by being an instance of “equivalent facilitation” in certain cases, but with the way SC 1.4.4 is currently worded, this is not an issue. So I support any movement and progress on this issue and anything that could unlock similar responsive typography use cases.

Also, to note, regardless of the SC change, I strongly feel that a fit-to-width feature should have a default limit of 200%. It allows evading some other possible issues that are not covered by this SC, but can be equally harmful when done wrong.

[GreggVan]

perhaps a better way to handle it is to add "up to the point where a single work would be split across lines.

I could see a whole sentence coded ("fit to width") but that should enlarge and wrap.

no?

[kizu]

The post explains the problem in details, so I invite to give it a read!

But a gist is that the problem is not just the text grows “too much”, but that if it is bounded by the viewport, a full-page zoom will reduce the available space, and thus reduce the effective font-size of the element, failing the SC 1.4.4.

Re: wrapping, the proposed algorithm for fit-to-width currently relies on it running after the browser decides how the text wraps, and can do it for each line box, which should work much better for any long lines of text, as if we require for them to stay on one line, they could become unreadably small.