Defining Requirements for a Complete Visual Contrast Guideline

[Myndex]

Defining Requirements for a Complete Visual Contrast Guideline

This post was moved from the Use Cases thread, which had become something of a catch all.

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

Science (empirically based models)

• 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

---

Spatial Frequency (size, weight, spacing, zoom)

• 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."

• Technology for zooming, reflow

  • functional zooming & reflow is more of a browser technology problem, than an author issue, other than authors must be prohibited from blocking people from zooming.
  • what is needed are browsers that zoom not by a percentage for all fonts, but to a specific size for the smallest fonts with larger fonts zooming at smaller percentages percentages to prevent from overrun and allow larger overall zoom sizes.
  • maximum required zoom size is therefore based on x-height in px, with limits based on display device.

• Zoom examples in practice. For the following examples, let's assume that our default size body text is 16px Verdana, and we have a 36px headline in Barlow. Then let's compare a regular desktop screen and a mobile phone in portrait mode, the two extremes of display device size.

  • If for a desktop we set the requirements to be able to zoom to 500% of default, then a 16px font becomes 80px, which accommodates 20/100.
  • above the 16px text, we have the 36px headline. If we zoom to make it 500% we end up with a 180px headline which is not only much larger than it needs to be, it's so big readability starts to suffer from being too large. Instead we simply want it noticeably larger than the body text which is now at 80px. Zooming 36px 300% brings us to 108px, which is good relative to the 80px body text.
  • But this won't function well on a cell phone in portrait mode, in which case the zoom requirement of 32px (200%) for the body text is more reasonable, accommodating 20/40. And that large headline, once again we'll increase it less, let's say 150%, that still makes it 54px. If we try to zoom the large headline 200% to 72px, the word "HEADLINE" would not even fit on the screen!
  • For an iPad in portrait or a large iPhone in landscape, we could reasonably bring the body text up about 350% to 56px (20/70), and the large headline up 233% to 84px.
  • Actual examples: myndex.com/WEB/TextZoomExample

---

Non-Text (spatial semantic non-semantic)

• 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)

---

Hue and Chroma (CVD, auto adjust, auto invert)

• 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. Browser zoom for a relative font size instead of percentage.
3. Automated font weight assessment (something I am working on)
4. Creation of an "accessible reference font"
5. Method for use-case flagging for automated testing (using CSS classes maybe?)
6. 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 simplified 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.}

_{Copyright © 2021 to 2023 by Somers & MTI. All Rights Reserved.}