Text resizing should focus on doubling size of body text; but headings are not necessary to double

[mbgower]

We already have established in Contrast (Minimum) that text that exceeds a certain size does not have the same need for contrast.

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

Large Text
Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;

large scale
with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

Similarly, text of a certain size does not have as great a need for resizing to the same extent.
As long as the heading remains visually differentiated from the body text, a lessening of relative size difference between the two seems supportable, especially given space constraints on different form factors.

This argument also seems to be relative as we consider magnifying to 400%. Does it serve anyone's purpose to magnify a 72 point heading to 288 point text, when the 12 point body text is only being increase to 48pt text? The heading could remain at 72 point and still be larger than the body text, and also distinguishable.

[maryjom]

WCAG2ICT has a related Issue 4 on this SC with a lengthy discussion.

[u9000-Nine]

Does it serve anyone's purpose to magnify a 72 point heading to 288 point text, when the 12 point body text is only being increase to 48pt text? The heading could remain at 72 point and still be larger than the body text, and also distinguishable.

No, but a 72 pt heading is already an extreme size. If it were a 22 pt heading (which in my personal opinion is still too large to look good but feels like something I might actually see on the web) with 12 pt body, then it would enlarge to 88 pt heading with 48 pt body, which still feels reasonable.

The reason a 288 pt heading with 48 pt body can be shrunk while remaining distinguishable is because a 72 pt heading is a whopping 6 rem against a 12 pt body! (It's the same for a 288 pt against a 48 pt as well.) At any scale that heading is needlessly large compared to the body text.

I think it's important for text scaling to maintain the original ratios, as it currently does. Yes, 288 against 48 is needlessly large, but so is 72 against 12, which implies that maybe the author intended it to feel that way. Changing the ratios would prevent people from having an equivalent experience.

Besides that, there's also the issue that a scaling algorithm would then need to determine how else the heading is signified. It might then need to change many different attributes in order to still make all the heading levels distinct.

[patrickhlauke]

the distinction of "body text versus heading text" seems very unhelpful to me to start with (and will get us down strange "so does THIS count as body text when it's inside a button? what about the <summary>, does that visually count as heading text?" discussions).

i'd also say that setting an arbitrary measure of "once text is X pt, it doesn't need to scale further" without any further context (size of the actual viewport, for instance) would be extremely arbitrary (particularly if from other parts we're hearing that LVTF originally wanted the ability to zoom to 1000% with reflow, etc). particularly since WCAG also shied away from defining a minimum text size as well, because again this would have been arbitrary.

[dashouse]

I did experience some user research where this behaviour was desired. When the participants zoomed in the 18px(relative equivalent) base size used for body copy / forms the headings were too large to read - forcing them to either zoom out or read headings one character at a time - affecting comprehension and reading time.

I have since experimented with the idea of a type scale that starts to flatten out above 400% zoom. For example as the base size increases the larger sizes reduce. The stumbling block here is not having an accurate way to determine zoom level vs viewport size.