Text Reflow Supported
Group: user-control • Guideline: adjustable-viewport
Summary in Plain English
Blocks of text stay legible at 320 CSS pixels in the orientation of the text, without having to scroll in that direction to read a line. Text whose meaning depends on a two-dimensional structure is exempt.
Why It Matters
Having to scroll sideways to read every line makes sustained reading impossible, which is the everyday experience of magnification users on unreflowed layouts.
Scope: When This Applies
The draft's own conditions, quoted from guidelines/groups/user-control/adjustable-viewport/text-reflow-supported.md.
Except when
- The meaning of text relies on a two-dimensional structure.
Examples from the Draft
Worked examples the W3C editors wrote into the provision itself, not examples invented here.
Two-dimensional structure might be relied upon in preformatted text such as code, poems, maps, or comics.
Test Procedure from the W3C Draft
Quoted from the provision's informative document, informative/guidelines/user-control/adjustable-viewport/text-reflow-supported.md. It is the group's own procedure, not an editorial testing guide.
HTML paragraph reflow without requiring scrolling in two dimensions
Procedure
For each page/view:
- Set the viewport at 320 CSS pixels in the direction of text.
- Identify all the blocks of text within the scope.
- Check that each block of text does not require scrolling into two dimensions.
- Check that the text in each block of text is legible.
Expected results
- #3 and #4 are true.
W3C Working Group Status
Open Questions Recorded in the Draft
The editors' own notes (:::ednote) in
guidelines/groups/user-control/adjustable-viewport/text-reflow-supported.md.
These are the questions the group has written down as unresolved —
not a summary of discussion written here.
Other languages may have other rules around line breaking: https://r12a.github.io/scripts/script-features/index.html
W3C Threads on This Provision
2 GitHub threads carrying 60 comments, fetched from w3c/wcag3 by the tracker. Titles, numbers and states are the threads' own.
What the Argument Is About
Whether WCAG 3 should anchor sizing in CSS px or rem, and how far text-only resizing has to work.
Positions taken in the thread
CSS px is relative to assumed viewing distance, which is what lets a requirement say how large something must appear across platforms. alastc notes WCAG 3 does not currently use px or rem for text sizing at all, and drafted a response proposing the issue be closed without changing any provision. GreggVan argues rem only says how big something is relative to something else, so an accessibility requirement cannot be written in rem because it sets no minimum size, and adds that px has only ever been cited as a minimum, not a fixed size. Myndex adds that the CSS px is defined as a unit of visual angle, the measure vision and readability science uses, while em and rem have no fixed relationship to it; using rem in practice is fine, but guidelines should trace to visual angle.
A user who sets a larger default font size sees rem-based layouts adapt and px-based layouts stay rigid. Argues this makes px a technical regression against user autonomy, and that calling it a user-agent problem shifts responsibility away from the standard.
Neither layout stability nor user scalability is the goal — people being able to read what is published is. Tested the disputed demo across Vivaldi, Avast, Safari and Firefox and found the px box adapts in some Chromium builds and not others, so the behaviour is not uniform. On the unit question itself he leans toward rem: asked whether px makes sense as a core unit for layouts rather than rem, his answer is "generally not"; he tells GreggVan an accessibility statement based on rem is perfectly feasible; and after browsing about 100 pages at a 64px font size he traced most serious problems to layouts set in pixels, concluding that promoting rem instead of px would really help. He also wants a reasonable default text size stated. Proposes a separate issue: content should support text-size adjustment well beyond the current 100–200% range.
On the related question of high-DPI viewports, raised in #156 by PAFaieta, who suggested a baseline native resolution and DPI or a baseline minimum magnification such as 200%, patrickhlauke replies that authors cannot predict or test the physical resolution a user runs, so a guideline cannot introduce that variability. A user running a small monitor at very high resolution has made that choice and can adapt their device.
Agreed
- Zoom currently works better across real sites than text-only resizing — alastc's claim, which chaals accepted ("Yes, zoom works better in most sites than increased text-size"), while calling his own survey anecdotal and attributing the breakage it found to layouts set in pixels.
- Large headings scaling proportionally is a real layout problem, which is why the draft asks for 200% of default body size rather than 200% of starting size.
Still open
- Whether content must support text-size adjustment beyond 200%.
- Whether the spec should state a reasonable, commonly legible default text size.
- Whether px-based layouts breaking under user font scaling is an author obligation or a user-agent gap.
- Whether provisions should be written as regulation-ready requirements or as guidance grounded in common practice — GreggVan says outcomes are shalls that regulators must be able to use, while chaals says the group's only formal authority is to develop guidance.
- alastc's draft response has not been through the group, so the issue is not resolved.
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/user-control/adjustable-viewport/text-reflow-supported.md · informative document: informative/guidelines/user-control/adjustable-viewport/text-reflow-supported.md
Blocks of text are legible at 320 CSS pixels in the orientation of text, without the need to scroll in the orientation of text. :::except-when * The meaning of text relies on a two-dimensional structure. ::: :::example Two-dimensional structure might be relied upon in preformatted text such as code, poems, maps, or comics. ::: :::ednote Other languages may have other rules around line breaking: https://r12a.github.io/scripts/script-features/index.html :::