What is needed in a complete readability guideline

[Myndex]

This week marks the three year anniversary of "thread #695" and also in view of the recent discussions and comparisons, I've prepared this outline that lists the specific problems with WCAG 2 contrast, and then outlines "what is needed" in an idealized contrast guideline.

Comments and thoughts welcome,

WCAG 2 Contrast — Key Failure Points

• Perceptually inaccurate
  • When text is WHITE, then WCAG 2 math under-rates the contrast. (incorrectly fails colors)
  • When either color is BLACK, then then WCAG 2 math severely over-rates the contrast. (incorrectly passes colors)
  • Through the middle ranges (#76 to #a3), WCAG 2 is incorrect in determining when to flip from black to white text.
    • the fact the contrast midpoint is incorrect makes the claim of "three way contrast" spurious.
• WCAG 2 ignores contrast polarity and can not be used to calculate dark mode.
• WCAG 2 dismisses anti-aliasing effects, including author selected AA.
• WCAG 2 has a single breakpoint for text size, and therefore does not consider the important effects of spatial frequency.
  • the breakpoint as stated (at 24px normal and 18.7px bold) is not aligned with the contrast sensitivity curve.
  • the text size breakpoint is derived from physical "large print" and not related to spatial contrast effects.
• WCAG 2 does not define a minimum font size (other than the large text breakpoint).
• Font size and spacing specs in WCAG 2 rely on font metrics which are not consistent per family.
• WCAG 2 does not consider use cases, other than permitting certain complete exceptions
  • some Incidental, disabled, or decorative text.
  • corporate logos.
  • complete exceptions to many of these are inappropriate.
• Spatial frequency is ignored by 1.4.11 non-text, an area where designers especially need guidance.
  • 1.4.11 as written has no scientific basis nor evidentiary support.
  • The cited references are self-referential, out of context, or with qualifications ignored.
• WCAG 2 conflates readability contrast with discernibility contrast, when they should be considered separately.
• No padding or margin definitions

---

What Is Needed In a Complete Visual Contrast Guideline

• Developed based in modern vision science & readability science

  • Text use cases based on critical size and critical contrast, per Bailey/Lovie-Kitchin

• Math model that is uniform to human perception of contrast

  • Said uniformity to be sensitive to spatial frequency effects (weight/size/thickness)
  • Said uniformity to be sensitive to light and dark mode polarities

• Considers important aspects of text on a device or computer display

  • Guidance for Antialiasing and rasterizing issues (i.e. no smoothing small fonts)
  • Common monitor mis-adjustment and ambient/environment issues
  • Whole page luminance factors (at least estimated as per worst expected case)

• Defines a standardized observer environment.

  • To be used as a foundation for testing and evaluations
  • Specified observers for various impairment and vision types

• Defines sizing guidance based on x-height per expected visual angle (CSS ref px)

  • Font sizing relative to x-height for body text and mixed case text.
    • Cap height used for upper case only text, or single-case writing systems.
  • Layout metrics such as leading (line height) and padding relative to x-height (not font body)
  • Kerning: per metrics or optical.
  • Tracking/letterspacing/indentations relative per x-height & glyph aspect ratio

• Font weights 100 to 900 defined with standard reference font.¹

  • Author fonts to use a weight offset, determined by comparison to standard reference font.
  • For latin, the primary reference is a sans-serif font with consistent stroke width, 0.5 x-height ratio.
  • Secondary reference fonts for serif, trans-serif, slab-serif, monospaced sans, and mono typewriter
  • Tertiary reference fonts for display, dingbat, ornamental.

• Provides design flexibility by dividing readability into appropriate use cases²

  • Body text needs near-maximum contrast for readability.
  • Fluent content text needs high contrast, but relaxed slightly from body text.
  • Soft-content text for dataviz needs, "important" footer matter (contact us, etc)
    • Soft content has relaxed size and contrast, similar in quality to 1.4.3
  • Spot readable text for disabled controls, placeholder, copyright, etc.
  • Layout characteristics and use of whitespace and information organization needs to be discussed at least as a "should."

• Encompass non-text contrast and design guidelines in a complementary manner.

  • Spatial frequency effects are just as important to non-text as to text.
    • non text typically has a much wider spatial frequency range
    • non text often has very low spatial frequency, so very different contrast requirements, including extending into hue/chroma contrast.
  • Non-text use cases divided into semantic and discernible groups.
    • Intrinsically semantic (icon or pictogram, land map)
    • Contextually semantic (chart lines, pie chart pieces, demographics map, lat/long lines, legend codes)
    • Meta semantic (focus or state, dynamic driving map, animatable potentially in combination with 1 & 2)
    • Discernible non-semantic (border, abstract button shape, map outer edge or legend area, zoom-up enlargement areas)

• Enhanced-Level Color (hue chroma saturation)

  • Guidelines for alternate color modes including
    • Light mode "paper-reading-experience" guidelines
    • Dark mode(s)—dark mode for day, dark mode for night.
    • daltanization modes enhancing limited color vision
    • monochrome mode and minimum luminance mode (for achromats)
    • high contrast and low contrast modes
  • Extension to the main math method that specifically addresses red and blue light issues
    • especially important for emerging WGD HDR technologies.
  • Extension to the main math method adding in multi-way color considerations.

Needed Technology Adds

1. A CSS property to directly set font size by x-height.
   • related properties for setting spacing relative to x-height.
2. Automated font weight assessment (something I am working on)
3. Creation of an "accessible reference font"
4. Method for use-case flagging for automated testing (using CSS classes maybe?)
5. Media type queries and use profiles for daltonization types, etc.

Not the Kitchen Sink

The list looks long, but this list is more about process, the actual guideline(s) should have much of this "hidden" and simplifed for ease of use by designers and testers.

---

FOOTNOTES
_{1) Ideally a custom primary reference font is created, with variable weight for at least 300 thru 700, and including 100,200,800,900 at least as individual weights. Primary reference to have a 0.5 x-height ratio, and aspect, letter and line spacing to be consistent with best practices for body text.
2) Appropriate use-case definitions is the appropriate design-friendly way to deal with what WCAG2 called "three way contrast". Not only does WCAG 2 contrast fail for not actually being 3-way, it is trying to solve design use-case definitions without any consideration of use cases.}