Text contrast sufficient (minimum)

sdw32 says he was surprised to find the words "contrast ratio" still in the latest WCAG 3 draft, because there is neither empirical nor theoretical evidence that the eye perceives contrast in proportion to the lightest colour divided by the darkest; the evidence supports perception of a brightness difference, which is what APCA computes. He argues that for mobile devices in typical indoor lighting the eye adapts to the room, so the difference can be used directly without normalising against an average or ambient level, and points to his cedc.tools comparison of APCA against ratio for black and white text on coloured backgrounds. Myndex adds in #29 that 4.5:1 degrades the experience for 100% of sighted users rather than only impaired ones, that roughly 86% of sites fail WCAG 2 contrast on automated survey with some of those failures being perceptual artefacts rather than real inaccessibility, and offers a side-by-side dark-mode comparison in which the WCAG 2 minimum is unreadable while the APCA minimum is legible.

Issue #29 exists to answer the Contrast Subgroup's condition that APCA needs extensive peer review before adoption. Myndex's position is that peer review is not in the WCAG 3 charter and no other subgroup has been asked for it, and that APCA has been in open public beta since the stable February 2021 release regardless. The dossier lists journal and book-published work (Ulitin in Culture and Technologies Studies 2021 and a 2023 Springer chapter), Sam Waller's Cambridge paper "Does the contrast ratio actually predict the legibility of website text?", Chris Lilley's internal W3C review in the silver repo, and a Low Vision Task Force thread involving Bailey, Campbell and Avila. He renews a 2020 proposal that AGWG convene a standing panel of subject experts on the SMPTE or ISO model, on the grounds that it would strengthen the standard's footing in future legislation.

GreggVan does not dispute that stroke weight, font design, presentation time and anti-aliasing all affect reading; he says stem width was considered and dropped because most people cannot measure it, and that the current simple measure is a deliberate trade, not an oversight. What he wants from critics is proposed wording: a single statement of the musts and a second of the shoulds, where a must is important, works across web technologies and has good interrater reliability. Machine testability is not required, only enough objectivity that different evaluators reach the same conclusion. He offers to have a "text visibility" tool built that takes font, size, type, stem and height and returns a linear score against a pass threshold, with a different threshold for running text than for menus, buttons and other short strings where the reader has time to fixate.

Direct rebuttal to the testability framing in #266: if the result of the test lacks utility then making it testable has not helped, and because WCAG 2.x is now being written into law, a flawed test carries flawed consequences with it. He offers the APC-RC reference-font matching method as a simple testable alternative, where a designer matches their chosen typeface against reference fonts for the silver and gold levels, necessary because "normal" and "bold" mean substantially different things per family. He also disputes GreggVan's premise that authors will not handle multiple variables, saying designers work with x-height ratio and glyph weight routinely and prefer a range of options to a binary, and that in practice only the critical content text needs testing, body text above all, and only once.

sdw32's glance-readability study, about 40 participants shown random three and four letter words for 300 ms across Open Sans Light through Extra Bold at APCA Lc 30, 45, 60 and 75, found that the minimum workable font size depends on the interaction between weight and contrast: Open Sans Extra Bold at Lc 30 outperformed Open Sans Light at Lc 75. His proposed fix is to quantify weight by pixel density after Wilkins, rasterising sample text, cropping to the x-height and thresholding at RGB(128) to split the anti-aliased pixels; using Wilkins' "the quick brown fox" phrase that gives Open Sans Light 20.2%, Open Sans 30.7%, Open Sans Semibold 40.0%, Open Sans Bold 47.5%, Open Sans Extrabold 56.4%, with Arial 35.4% and Verdana Bold 50.3%. He later proposed switching to the bare alphabet so the method generalises beyond Latin, without publishing revised figures. TestPartners notes WCAG 2 recognises only 400 and 700 while weight 600 is common and reads as bold. patrickhlauke's objection is upstream of all of it: the same nominal CSS weight renders differently between typefaces and even between cuts of one typeface, so the value is meaningless unless anchored to specific font metrics, which font fallback then breaks.

In #590 nakano0949-web proposes a rendering-aware model: a rendered glyph divides into a Core of pure glyph colour, an anti-aliased band of blended pixels, and a background ring, with Core Ratio approximated as (C/W) squared and AA Impact as 1 minus that. Measurements show AA impact climbing sharply below 14px and dominating at 12px and below, so text that passes on CSS colour values can measure substantially lower as actually drawn, worst for small sizes, thin weights and particular font cuts. The proposal supplies a five-step extraction algorithm to automate the measurement and offers data and code. patrickhlauke cross-references the earlier w3c/wcag#4954 discussion and elsewhere in #266 lists the same class of variables the model is trying to capture: OS anti-aliasing settings, font substitution, differing cuts, and the period when macOS rendered fonts visibly fatter than Windows in the same browser.