Text style readable (enhanced)
Group: text-and-wording • Guideline: text-appearance
Summary in Plain English
The authored presentation of text style properties - typeface, font size, font width, text decoration, letter spacing, capitalisation and end-of-line hyphenation - meets enhanced values, still to be determined.
Why It Matters
Defaults decide what most readers get. Setting them at the enhanced level removes the need for individual adaptation.
Test Procedure from the W3C Draft
Quoted from the provision's informative document, informative/guidelines/text-and-wording/text-appearance/text-style-readable-enhanced.md. It is the group's own procedure, not an editorial testing guide.
Procedure
For each block of text:
- HTML: Check CSS to confirm that relevant style attributes (such as font size and letter spacing) are set within the values specified in the provision.
- Non-web apps: Check GUI toolkit settings (or defaults) to confirm that they apply values within the designated range.
Expected results
- #1 or #2 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-style-readable-enhanced.md.
These are the questions the group has written down as unresolved —
not a summary of discussion written here.
If you are aware of research in this area, especially involving non-Latin scripts, please email public-agwg-comments@w3.org.
W3C Threads on This Provision
3 GitHub threads carrying 27 comments, fetched from w3c/wcag3 by the tracker. Titles, numbers and states are the threads' own.
What the Argument Is About
Nobody has said what the enhanced level actually raises โ the two threads specific to this provision have no replies, and the shared requirements thread is arguing about whether a second, stricter threshold can be defined at all now that the baseline it would sit above has been removed.
Positions taken in the thread
Rather than write separate prose for each level, build a text visibility tool that takes font, size, type, stem and height into account and returns a linear research-based score; point it at any text and pass above X. Proposes a different X for running text, which the eye must read at speed as it passes over the line, than for menus, buttons and other short strings where the user dwells on a word. He did not address the enhanced level as such; on this approach enhanced would be a higher number on the same scale. He offers to have the tool built โ but only if someone supplies the research and the interaction effects, which he asked sdw32 for directly.
Because font-size and the labels normal and bold mean substantially different things across families, the APC-RC guidelines set silver and gold levels using reference fonts that a designer matches their own typeface against, a one-time exercise per font. His acuity-reserve table, which does not mention an enhanced level, runs in small steps: 0.18 degrees, an 8.3px x-height or a 16px font at Helvetica's 0.52 ratio, is content minimum at critical size, 0.2 degrees (9.4px x-height, 18px font) is the figure for columns and blocks, and 0.24 degrees (11px x-height, 21.5px font) is preferred body. He also insists a practical standard must not demand that everything in a view hit critical values, since spot text such as a copyright bug and sub-fluent text such as captions exist deliberately to keep the visual hierarchy readable.
He points to EN 301 549, which has a two-level shape: an 8 CSS px x-height as best practice for text that can be zoomed, against a 16 CSS px x-height for text and images of text necessary for functionality that is closed to text enlargement. His glance-readability study โ roughly 40 participants, random three- and four-letter words at 300 ms, across Open Sans Light through Extra Bold and APCA 30 to 75 โ found Open Sans Extra Bold at APCA 30 outperforming Open Sans Light at APCA 75, so the minimum appropriate font size depends on the interaction of weight and APCA contrast, and a single contrast threshold applied across all weights is not fit for purpose. For weight he proposes Wilkins' pixel-density measure (rasterise the alphabet, crop to the x-height, threshold at RGB 128, count black pixels), giving Open Sans Light 20.2 percent, regular 30.7, semibold 40.0, bold 47.5 and extrabold 56.4 โ which would turn the regular-to-semibold Open Sans body-text band, from text he wrote for the non-digital standard interpreting the European Accessibility Act, into a testable range.
patrickhlauke lists the rendering variation that makes nominal size and weight values unreliable to test: OS antialiasing, font fallback and substitution, different cuts of the same typeface with subtly different metrics, and browser rendering that made fonts on macOS visually fatter than on Windows. scottaohara adds that CSS scaling can change the rendered size while the specified font-size stays exactly as authored, so the declared value is not the tested value. TestPartners notes that weight 600 is very common and looks bold while strictly not being bold, so any level that keeps the binary normal/bold split has to say how intermediate values are treated. patrickhlauke supports building GreggVan's tool but treats these as the caveats it must carry.
The enhanced level is currently stricter by banning things โ no underlining, no decorative or cursive face. In #266 detlevhfischer called the decorative-or-cursive wording too restrictive as a general rule, and Myndex agreed and called it subjective, ambiguous and arbitrary (the same objection recorded against the minimum); neither commented on underlining, and detlevhfischer did not comment on the alternative. Myndex's counter-proposal reshapes what enhanced would mean: require that a plain accessible font is offered as a fallback and that layout features keep working when the user selects it, ideally through a new prefers-font-family: plain media query. The argument is that a stricter author prohibition is the wrong instrument for a dynamic medium where user personalisation can do the work, especially as these voluntary guidelines are being pressed into law.
In #641, a voice recognition software user points out the asymmetry directly: the minimum permits some underlining and the enhanced requirement does not. Having repeatedly tried to open a link that turned out to be randomly underlined text, they want underlining restricted to links at the minimum level โ which would collapse the distinction between the two levels on this point rather than preserve it. They argue underlining is a holdover from handwriting, and that digital text has bold and italic for emphasis while underlining has become the convention for links.
Agreed
- x-height, not CSS font-size, is the right anchor for any size threshold. sdw32 states he absolutely agrees with Myndex on this and notes deriving x-height for a given font is fairly trivial programmatically if you hold the licence; teohhanhui's observation that CSS already has the ex length unit was answered โ it measures length but cannot set the rasterised size on screen โ and the gap is the proposed font-x-size property (csswg-drafts #6709). Nobody argued for keeping font-size as the anchor. tsmd later questioned whether x-height applies at all to Japanese, Chinese and Korean (see open).
- Running text and short strings need different thresholds. GreggVan reaches this from how the text is read (you dwell on a button label, you skim a line of body text) and Myndex from readability science (spot and sub-fluent text are legitimate design), and neither was contested.
- Any absolute size in the spec should be given primarily in CSS px with pt secondary. Myndex's worked example went unrebutted: WCAG 2 specifies 18pt, designers apply the number as 18px, and the resulting text is 25 percent smaller than the standard requires.
Still open
- What the enhanced requirement is for at all. julierawe asked in #484 whether it simply encourages developers to set default text presentation to the values already specified in the foundational adjustable text style requirement, how that connection could be made clearer, and whether that framing means customisation beyond those values is no longer encouraged. The issue has had no replies since December 2025, and she noted that commenters raised similar questions about readable blocks of text enhanced (#485).
- What the enhanced numbers are. The candidates on the table have never been compared: sdw32's 16 CSS px x-height for text closed to enlargement against his 8 CSS px baseline, versus Myndex's ladder from 0.18 degrees (16px font) to 0.24 degrees (21.5px font).
- Whether underlining should be forbidden at enhanced only or at both levels โ Finnberrys (#641), unanswered since April 2026.
- Whether sdw32's pixel-density approach to font weight is sound. He asked three explicit questions โ is the approach acceptable, does a free public-domain algorithm exist that could run in a website, will anyone reimplement his VBA to check his numbers โ and pinged Myndex and GreggVan by name in February 2026. None has been answered.
- Whether the research exists to build GreggVan's scale. He asked for the interactions; sdw32 offered his experimental data and asked to join meetings; nothing has been assembled.
- Whether a scored tool that returns one number is preferable to asking authors to work with several text characteristics. GreggVan said anything requiring an author to look up several characteristics and their interactions would not be practical, and patrickhlauke endorsed the tool with rendering caveats; Myndex disagreed, saying designers are more interested in working with a range of options than arbitrary binary choices, that they already refer to x-height ratio and glyph weight all the time, and that a testable result lacking utility is not helpful.
- Whether an enhanced tier can be specified above a floor that was removed. GreggVan confirmed there is no longer a minimum size requirement for default text presentation and sdw32 registered deep concern; the argument is recorded in full against the minimum entry, and nobody in the thread drew out what it means for the enhanced level.
- tsmd's point that x-height does not apply to Japanese, Chinese or Korean, which every size proposal here depends on. Earlier, in February 2026, sdw32 had replaced Wilkins' English pangram with the plain alphabet for his density metric so that it would generalise to other alphabets, but that is still a Latin-script fix, and no one has responded to tsmd.
Note
Both issues specific to this provision โ #484 and #641 โ have zero comments, so everything substantive here is drawn from #266, a requirements-tracking thread shared with the minimum level and both text contrast provisions. Part of the record is also off-thread: sdw32 posted his central proposal as a .docx attachment because the GitHub editor does not support the lists and images he needed, and, on the thread, separately asked GreggVan for the basic process rules โ whether must and should apply, whether tests have to be machine-executable, and what the deadlines are โ which GreggVan answered by saying the group does not use must and should, that anything treated as a must needs to be important, reliably testable with good interrater reliability and work across web technologies, and that it can be human-testable as long as it is objective enough that evaluators reach the same conclusion.
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.
No mapping recorded. No WCAG 2.2 criterion in this site's map is recorded as a predecessor of this provision.
W3C Raw Source Text
Verbatim from guidelines/groups/text-and-wording/text-appearance/text-style-readable-enhanced.md · informative document: informative/guidelines/text-and-wording/text-appearance/text-style-readable-enhanced.md
The default/authored presentation of text style properties meets the enhanced @@ [values to be determined] for: * typeface * font size * font width * text decoration * letter spacing * capitalization * end-of-line hyphenation :::ednote If you are aware of research in this area, especially involving non-Latin scripts, please email public-agwg-comments@w3.org. :::