Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Contrast Research: APCA Peer Reviews + Defining a Visual Contrast Guideline #29

Open
Myndex opened this issue Oct 24, 2023 · 2 comments
Open

Contrast Research: APCA Peer Reviews + Defining a Visual Contrast Guideline #29

Myndex opened this issue Oct 24, 2023 · 2 comments

Comments

@Myndex
Copy link
Member

Myndex commented Oct 24, 2023 •
edited

APCA Review Status

Per the Contrast Subgroup:

...The research and resulting algorithm requires extensive peer review from other researchers in color contrast before adoption....

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

  • Book: A11Y Unraveled: Become a Web Accessibility Ninja ― by Dimitris Georgakas 2023
  • Book: Practical UI: Quick and practical UI design guidelines - by Adham Dannaway 2022

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?

WCAG v2 vs APCA Dark Mode Compare, showing the minimums for each. The WCAG 2 example is clearly unreadably low contrast, demonstrating that WCAG 2 is not useful for dark mode. APCA however is clearly readable.

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

  • The Realities And Myths Of Contrast And Color by Andrew Somers. This peer reviewed feature article is a comprehensive primer to vision, color, and contrast for design, with an emphasis on typography, readability, and visual accessibility needs.

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.

  • Related GitHub Repos of Interest:
    • SAPC-APCA Main Documentation Repo This is the primary repo for documentation, discussion, posting issues.
    • IRT ARC - Inclusive Reading Technologies The IRT GitHub repo for the APC Readability Criterion, a public working draft of actionable design guidelines.
    • apca-intro comparison discussion This is a corrected fork, with detailed discussion.
    • apca-w3 The APCA version to be licensed for use with public guidelines such as IRT-RC, WCAG 3, and others.
    • BridgePCA A simplified version of the APCA math to bridge from WCAG 2 contrast math to the future, while being 100% backwards compatible with WCAG 2 contrast.
    • DPS Contrast aka deltaPhiStar 𝜟𝜱✴︎ is a variant method of determining lightness contrast, and a sibling of APCA and SACAM. It is a simplified version using easily invertible standardized maths based around CIE $L^*$.
    • ColorParsley A lightweight but versatile Myndex MicroColor Library, to parse color strings, objects, or numbers, returning a simple rgba array, and related string utilities. This was developed as part of the basic APCA package.
    • SeeStars SeeStars is a Myndex MicroColor Library. This has standard functions for the standard (piecewise) IEC conversion of $sRGB$ to $Y$, and the CIE standard $Y$ to $L^*$ (Lstar) and back again. The math & constants here reference those of CSS 4 for compatibility.
    • MaxContrast Send it the background color, returns black or white, whichever is the maximum $L^c$ value. See also FancyFontFlipping for the related interactive experiment.

Thank you for reading.
@Myndex Myndex changed the title Contrast Research: APCA Peer Reviews Contrast Research: APCA Peer Reviews + Defining a Visual Contrast Guideline Oct 31, 2023
@Myndex
Copy link
Member Author

Myndex commented Oct 31, 2023 •
edited

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 (#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)

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

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

This was referenced Nov 20, 2023
Open
Open
@Myndex
Copy link
Member Author

Myndex commented May 6, 2024 •
edited

Memorandum:

GitHub user xi did an analysis of APCA, which he linked to in Silver issue #651.

There are a number of significant concerns regarding the nature and content of his analysis. To set the record straight and respond with corrections and brief discussion, I've created the following repo, the corrected APCA Introduction, which clearly breaks the issues down and directly addresses any misunderstandings.

Thank you for reading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Myndex