Myndex
commented
11 months ago This is copypasta from Defining Requirements for a Complete Visual Contrast Guideline #103.
More related contrast discussions at the readability forum.
Defining Requirements for a Complete
Visual 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 (
#76to#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)
For mixed case writing systems only:
- 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 sizing relative to x-height for body text and mixed case text.
For most writing systems:
-
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
16pxfont becomes80px, 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)
- If for a desktop we set the requirements to be able to zoom to 500% of default, then a
-
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)
- Spatial frequency effects are just as important to non-text as to text.
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.
- Guidelines for alternate color modes including
Needed Technology Additions
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.
APCA Review Status
Per the Contrast Subgroup:
Our understanding is that peer review is not a part of the charter, and that no other subgroup for WCAG 3 has been required to seek out peer review. Nevertheless the Visual Contrast group has proactively compiled a listing of independent peer and other reviews. APCA and related guidelines have been developed in the open, starting with thread wcag #695, and have been in open public beta testing since the stable February 2021 release (nearly three years of beta testing).
In 2020 we suggested setting up a panel of experts from relevant fields, as is done at standards groups such as SMPTE or ISO. Such a process would help support future legislative efforts. It is this author's opinion that AGWG and WCAG would only be strengthened by developing a professional independent committee/panel process, as used in other standards organizations.
A Solid Foundation of Science
It is important to again point out that the APCA Readability Criterion guidelines are derived directly from the peer-reviewed scientific consensus in readability research, and the APCA formula rests on decades of well established vision science and the latest advances in peer reviewed color appearance modeling.
We are aware that some individuals have made derisive statements to the contrary, but their uninformed demurrers have no factual basis and are notwithstanding — such spurious statements are an affront to the many a11y advocates, members, study participants, beta testers, and developers who have been working with all due diligence over the last 4 2/3 years of research, development, and/or testing of these methods.
Independent Peer Reviews of APCA & More
The following is a collection of journal published peer reviews, independent peer reviews, public reviews, and including reviews by PhDs, vision scientists, corporate stakeholders, developers, designers, and engineers. Several reviews include demonstrations of the functional superiority to existing methods. The first few listed below are technical reviews by peers evaluating the APCA math and methods. Some look into the internals, functioning, or the usability and practicality of APCA.
APCA Featured in Print
Reviews of WCAG 2 Contrast
Discussion with links to third party articles
written prior to the development of APCA
The problems of 4.5:1 as a target for a guideline is that it not only impact those with impairments, but impacts standard vision as well. WCAG 2 contrast SCs affect 100% of sighted users. The inherent problems with the WCAG 2 contrast math have been known for some time and widely criticized. Including studies by others showing that color insensitive types are not well served.
The WCAG 2 contrast specs often cause enough problems for designers that it is ignored and today, some 86% of websites are failing WCAG 2 contrast per an automated survey—though some of these failures are not due to poor actual accessibility, but due to the perceptual inaccuracies of WCAG 2 contrast.
The unfortunate end result is a grave distrust of the WCAG 2.x accessibility standards overall, despite the many other important aspects of those standards.
Prima Facia Evidence and Public Comment
Outside of the peer reviews, third party reviews, and the extended 2.75 years of public test data collected thus far, you as a user can make your own judgements, using these tools and inspecting the results.
For instance, look at the following examples of minimum compliance for content for WCAG 2 (left) and APCA (right). Which one would you rather defend in a court of law? Which one would you rather have sites follow?
Public Comment and Discussion
Public comment and discussion is encouraged. The APCA discussion forum is alive and well, please join in the discussion, share and discuss your findings as part of the open public evaluation.
More About APCA, Direct from the Creators
The easy quickstart to becoming an expert in perceptually uniform contrast guidelines.
Smashing Magazine
Discussions on Contrast, Design, WCAG & APCA
The following articles, blogs, gists, and documentation written by APCA research lead Andrew Somers, examine the technical and functional differences between APCA and WCAG 2. Some of these are work-in-progress pre-prints relating to ongoing research.
Better Reading on the Web Published by UX Collective, this article discusses and demonstrates issues with automated testing and WCAG 2 contrast math, methods, and guidelines.
The Tangled Web tech blog (TangledWeb.xyz):
Thank you for reading.