The definition of 'large scale' needs substitutions or notes

[mitchellevan]

Currently

WCAG's definition of 'large scale' is web-centric, but WCG2ICT lists it under "do not need further interpretation for non-web ICT." This is the case in the 2013 version and the 2024 draft.

In my experience this has presented problems in WCAG evaluations of non-web documents and software, because it's unclear how to measure text for purposes of SC 1.4.3 Contrast (Minimum).

Proposed

At a minimum, WCAG2ICT should provide replacements for phrases in the "large scale" definition that can't apply as-is to non-web ICT. I believe these are the ones most in need of addressing:

• "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." (Needs something different for non-web software, which does not have a user agent.)
• "When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would be reasonable to assume it is large text." (Needs something different for all non-web ICT, which by definition is not presented in a browser.)

I'd also like to see a note explaining how to interpret the "pt" unit (while avoiding techniques and staying technology-neutral as usual). It might be enough to quote Understanding SC 1.4.3...

"...The ratio between sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt and 18pt are equivalent to approximately 18.5px and 24px."

... and add a clarification that 'CSS pixels' should be understood per WCAG2ICT's explanation of the term. I haven't researched this, but if it doesn't have too many unwanted consequences then it would be a convenient explanation.

[mraccess77]

This came up previously in mobile and the discussion was around 1.5 times default text size non-bold or 1.2 bold times the default text size as the intent. Something along those lines could be used.

The note in the definition of SC 1.4.3 support this notation as the intent "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."

[mitchellevan]

@mraccess77, '120% or 150% of the default size for body text' is useful for explaining the general intent, and I can imagine it gaining importance in WCAG 3. However, within the scope of WCAG2ICT, I feel that it is not a solid enough basis for measuring the size thresholds for 'large scale' text. I'm not clear what 'body text' would mean in general for non-web content (not just mobile apps), and I doubt that non-web technologies reliably provide a 'default size' that would be roughly equivalent to the default size of HTML text.

I'm drafting a note for the Task Force to review. My current thinking is to equate a 'point' to 1.333 CSS pixels as Understanding SC 1.4.3 does, while applying the WCAG2ICT interpretation of 'CSS pixel'.