Text contrast sufficient (enhanced)
Group: text-and-wording • Guideline: text-appearance
Summary in Plain English
A higher contrast bar than the minimum requirement, with the same scope and exceptions. The measure itself is still to be determined in the draft.
Why It Matters
The minimum level is a floor, not a comfortable reading level. The enhanced level is aimed at people whose contrast sensitivity is significantly reduced.
Scope: When This Applies
The draft's own conditions, quoted from guidelines/groups/text-and-wording/text-appearance/text-contrast-sufficient-enhanced.md.
Applies when
- text is presented, including text embedded in an image format.
Except when
- the text is:
- also present elsewhere in the page/view which meets the requirement
- part of an inactive interactive element
- pure decoration
- not visible to anyone
- part of a picture that includes significant other visual content
- part of a logo
Test Procedure from the W3C Draft
Quoted from the provision's informative document, informative/guidelines/text-and-wording/text-appearance/text-contrast-sufficient-enhanced.md. It is the group's own procedure, not an editorial testing guide.
Procedure
For each foreground and background combination of text:
- Identify the foreground color.
- Identify the background color.
- Check the contrast of text meets the [TBD algorithm].
Expected results
- #3 is true.
W3C Working Group Status
Open Questions Recorded in the Draft
The editors' own notes (:::ednote) in
guidelines/groups/text-and-wording/text-appearance/text-contrast-sufficient-enhanced.md.
These are the questions the group has written down as unresolved —
not a summary of discussion written here.
The contrast algorithm used in WCAG 3 is yet to be determined. For this draft, the requirement assumes the algorithm will include a size/weight factor. If the algorithm does not include size/weight, it will need to be added to this requirement text.
W3C Threads on This Provision
3 GitHub threads carrying 32 comments, fetched from w3c/wcag3 by the tracker. Titles, numbers and states are the threads' own.
What the Argument Is About
Whether a higher contrast threshold buys anything once text is past contrast constancy, and how a higher tier would relate to thresholds keyed to what the text is for.
Positions taken in the thread
Myndex rests his argument on Lovie-Kitchin's critical contrast, the point past which further increases in text-to-background contrast produce no improvement in reading speed or comprehension. Once a design reaches that Lc level it enters contrast constancy, and from there the spatial factors โ whitespace, stroke weight, size, crowding โ govern readability, with the perceived luminance difference ranking, in his words, among the least important. He cites Chung and Tjan for the mechanism: reading speed shows strong spatial-frequency dependence when text contrast is low, which is to say the payoff from added contrast is conditional on size and weight rather than additive to them. sdw32's glance study, which tested APCA Lc 30, 45, 60 and 75, supplies a matching data point, with Open Sans Extra Bold at APCA Lc 30 outperforming Open Sans Light at Lc 75, from which he concludes a single contrast threshold for all font weights is not fit for purpose (the weight-quantification method behind it is covered under text-contrast-sufficient-minimum).
Myndex's #207 restructure groups 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced) under one guideline, "Visually readable content uses ample luminance contrast," keeping 1.4.6 as its own row and attaching to it 1.4.6a on font weight and glyph characteristics and 1.4.6b on text use cases. His categories are FLUENT โ high-fluent body text, defined as more than two continuous lines in a block or column at an x-height of about 16px or less, fluent text up to two and a half lines, and large fluent headers above about 32px โ and SUB-FLUENT, covering soft readability, spot readability (readable with fixation), logo and branding colours, and incidental text in images. GreggVan, in #266 and without reference to the enhanced level, proposes a text visibility tool with one pass threshold X for running text and a different X for menus, buttons and other short strings where the reader has time to fixate.
Answering sdw32's question about minimum size and contrast requirements for default presentation, GreggVan's position is that if a size is large enough for typical vision, then that size under magnification is good enough for low vision โ large print for typical viewers is large print for low vision users, fine print is fine print, and anyone with very low vision has magnification built into every OS. He adds that stating any floor would require specifying screen size and CSS pitch, which the author does not control, and says a lot of thought went into concluding there is no way to guarantee text is never too small.
sdw32 rejects the premise of typical vision outright โ vision is a bell curve like grip strength, and he routinely measures young people at 20/10, twice the 20/20 reference. Since designers default to designing for themselves, a site built by a 20/10 designer accommodates only 20/50 at the browser maximum of 500% zoom, which he does not accept as maximising foreseeable use. Working backwards from 20/200 access at 500% gives a target of 20/40 suitability at 100%, which is his 8 CSS px x-height floor. On GreggVan's pitch objection he answers that no screen pitch need be specified, only the CSS px definition itself โ 96 DPI viewed at 28 inches or 711mm, implying 427mm for a 160 DPI phone โ and offers a live failure, the string "achetรฉs = 30% d'รฉconomies" on carrefour.fr, as text that fails EN 301 549 while passing the current WCAG 3 draft. The minimum-level half of this exchange is covered under text-contrast-sufficient-minimum and text-style-readable-minimum.
EN 301 549 v4.1.0, which sdw32 worked on, already ships the two-level structure but keys it to whether the text can be enlarged rather than to a conformance level. Zoomable text gets a best-practice x-height of at least 8 CSS px, corresponding to 1.2mm at a 400mm viewing distance with no zooming or screen scaling; text and images of text necessary for all functionality that is closed to text enlargement get at least 16 CSS px of x-height, an exact doubling. The weight rule he wrote for the separate non-digital standard interpreting the European Accessibility Act is two-sided rather than a floor: body text between regular-weight and semi-bold Open Sans, and keywords or short phrases neither thinner than regular Open Sans nor heavier than extra-bold.
APC-RC carries silver and gold levels with reference fonts a designer matches their own typeface against, and Myndex states the selected contrasts for both are intended to serve a Pelli-Robson score down to 1, a profound contrast deficit on a scale where 2 is normal and lower is worse. That makes the higher tier an answer to a measured population rather than a round multiple of the minimum. nakano0949-web pressed him in #590 on whether APC-RC addresses colour vision deficiency and low vision, which she said physical contrast models alone cannot fully capture; Myndex answered that APCA already improves on WCAG 2 for protans, that a protan compensator pre-shaping luminances for colours with high red primary content is due this year, and that SACAM, an accessibility-adjustable colour model for dynamic personalisation, is in progress. In #207 he notes the same physics already rejects pure red against black or dark colours, since red on black is poor for standard vision too.
Agreed
- Luminance contrast and the spatial properties of text are not independent levers. Myndex's framing that contrast sensitivity is dictated by spatial frequency, which he calls peer-reviewed consensus dating to Stevens 1961 and Bartleson and Breneman 1967, drew no rebuttal in either thread where he raised it.
- Not everything in a view should be at maximum contrast or maximum size. Myndex argues variation is required for visual hierarchy and for cognitive accessibility in particular, and GreggVan's separate thresholds for running text and for short strings reach the same conclusion from the testability side.
- Whatever the enhanced requirement asks for has to be anchored in x-height rather than font-size. sdw32 states he absolutely agrees with Myndex on this; the ratios that make font-size uninstructive are 0.55 for Verdana, 0.52 for Arial and Helvetica and 0.45 for Times New Roman. teohhanhui's correction that CSS already has the ex unit was answered by Myndex โ ex is a length unit, not a way to set rendered glyph size, which is what the font-x-size proposal in csswg-drafts#6709 exists for โ and teohhanhui did not press it. tsmd later cautioned that x-height does not directly apply to Japanese, Chinese or Korean.
Still open
- Whether a separate enhanced level should exist at all. No participant argues against it; Myndex's #207 keeps 1.4.6 Contrast (Enhanced) as a row with font-weight and text-use-case sub-items, and has sat since February 2023 with no comment from anyone.
- What the enhanced threshold actually is. No participant in any of the three threads proposes or defends a numeric value for it. sdw32's Lc 30, 45, 60 and 75 are study conditions rather than proposals, and APC-RC's gold level is named but never given a value.
- alastc's requirement list in #266 opens with "Maximum text contrast: The rendered text against its background meets a maximum โcontrast ratio testโ for its text appearance." and no one in the thread's twenty-plus comments addressed the maximum. Myndex's argument against uniform maximum contrast bears on it but never names it.
- Whether an enhanced threshold stated in CSS colour values survives rendering at the sizes where it matters. nakano0949-web's measurements in #590 show anti-aliasing impact climbing sharply below 14px and dominating at 12px and below; only patrickhlauke and Myndex replied.
- Whether the protan compensator and SACAM change the enhanced-level answer once released. Both were described as forthcoming in April 2026 and the thread records no release.
- sdw32's pixel-density method for quantifying font weight was put to the group with three explicit questions โ is everyone happy with the approach, does a public-domain algorithm exist, and will anyone reimplement it outside VBA to check his numbers. He asked on 20 January 2026 and re-asked on 10 February tagging Myndex and GreggVan by name. Neither answered.
- Whether any of this transfers beyond Latin scripts. tsmd's closing comment in #266 is that x-height does not directly apply to Japanese, Chinese or Korean; Myndex's own note that Japanese mixes thin-stroked logographic Kanji with thicker syllabic Kana on the same line means a single spatial threshold is already strained within one writing system.
- How far text zoom must go. Myndex says 200% only reaches accommodation for 20/40 and body text should be able to reach 400%, 16px to 64px and 48px headlines to 96px-128px, with diminishing returns beyond about 2 degrees; sdw32 reasons from the 500% browser maximum, and GreggVan relies on AT magnification as much as is needed. No one engaged Myndex's figures directly.
Note
There is no discussion specific to the enhanced level. All three threads carry both the minimum and enhanced provision labels, and every substantive exchange in them is about the floor โ whether a minimum exists, what unit it uses, how weight is quantified. #207, the only thread that engages the enhanced level structurally, was opened by Myndex in February 2023 as a survey item, was last updated in May 2026, carries six provision labels including graphical object, interactive element, focus indicator and pointer contrast, and has never received a single comment.
WCAG 2.2 Criteria That Map Here
From this site's reviewed WCAG 2.2 → WCAG 3 map. The map is an interpretation, not a W3C mapping: W3C has not published one yet.
W3C Raw Source Text
Verbatim from guidelines/groups/text-and-wording/text-appearance/text-contrast-sufficient-enhanced.md · informative document: informative/guidelines/text-and-wording/text-appearance/text-contrast-sufficient-enhanced.md
The default visual presentation of text meets @@[contrast measure to be determined, at a higher level than the core requirement for Text contrast sufficient (minimum)].
:::ednote
The contrast algorithm used in WCAG 3 is yet to be determined. For this draft, the requirement assumes the algorithm will include a size/weight factor. If the algorithm does not include size/weight, it will need to be added to this requirement text.
:::
:::applies-when
* text is presented, including text embedded in an image format.
:::
:::except-when
- the text is:
* also present elsewhere in the page/view which meets the requirement
* part of an inactive interactive element
* pure decoration
* not visible to anyone
* part of a picture that includes significant other visual content
* part of a logo
:::