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.