Text Resize and Reflow
debt(d5/e5/b5/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list axe, wave, and lighthouse which can flag user-scalable=no and maximum-scale=1 via regex patterns, but content clipping at 200% text or 400% reflow generally requires manual testing — automated tools only catch the obvious viewport-meta and fixed-px cases, leaving the layout-breaks-on-resize case largely silent.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix spans switching font sizes/spacing to rem/em, removing fixed heights and overflow:hidden, and editing viewport meta — this is a coordinated CSS refactor across stylesheets rather than a single-line swap, but stays within the styling layer.
Closest to 'persistent productivity tax' (b5). applies_to web/browser contexts and tags responsive-text/css/frontend; sizing strategy (rem vs px vs vw) and container constraints are decisions that shape every layout and component going forward, slowing many frontend work streams rather than staying localized.
Closest to 'serious trap' (t7). The misconception is that a responsive layout passing every device breakpoint guarantees text-resize compliance — but breakpoints react to screen width while text resize is user-initiated font scaling, a directly contradictory mental model that catches developers who assume responsive design covers it.
Also Known As
TL;DR
Explanation
Text resize and reflow covers two distinct WCAG requirements that protect low-vision users who enlarge content. WCAG 1.4.4 Resize Text requires that text can scale up to 200% without loss of content or functionality. WCAG 1.4.10 Reflow requires that at 400% zoom (equivalent to a 320 CSS pixel wide viewport) content reflows into a single column with no need for two-dimensional scrolling, except for content that genuinely needs it like maps or data tables.
The crucial distinction from responsive design is the trigger. Responsive breakpoints react to viewport width - the device or window size. Text resize is user-initiated font scaling: the user increases the browser's default font size, or uses page zoom, independently of the device. A layout can look perfect at every device breakpoint and still break catastrophically when a user bumps their font up two notches.
The failure modes are predictable. Fixed-height containers with overflow:hidden clip enlarged text. Pixel-based heights and widths refuse to grow with content. Absolute positioning and fixed line-height crush text together or push it out of view. Layouts built on viewport units (vw) for font sizes ignore the user's preference entirely.
The fix is to build flow-friendly layouts. Use relative units (rem, em) for font sizes and spacing so they honor the user's base font size. Avoid fixed heights on text containers; let them grow. Use CSS that wraps and reflows - flexbox and grid with min-content awareness, media queries that switch to single column at narrow widths, and overflow handling that allows scroll only on the axis that needs it. Test by setting the browser default font to large and by zooming to 400% at a 1280px window, then confirm no content is clipped and no horizontal scrollbar appears for body text.
Diagram
flowchart TD
USER[Low-vision user enlarges text] --> TYPE{Trigger type}
TYPE -->|font size preference| FONT[Browser default font scaled]
TYPE -->|page zoom 400%| ZOOM[Effective 320px viewport]
FONT --> CHECK{Layout uses relative units?}
ZOOM --> REFLOW{Content reflows to one column?}
CHECK -->|rem em %| GROW[Containers grow, text readable]
CHECK -->|px fixed height| CLIP[Text clipped or overlapping]
REFLOW -->|yes| OK[No horizontal scroll - passes 1.4.10]
REFLOW -->|no| HSCROLL[Two-dimensional scroll - fails]
style GROW fill:#238636,color:#fff
style OK fill:#238636,color:#fff
style CLIP fill:#f85149,color:#fff
style HSCROLL fill:#f85149,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Setting font sizes in px so the browser's default-font-size preference is ignored entirely.
- Using fixed-height containers with overflow:hidden that clip text once it grows.
- Sizing fonts with viewport units (vw) which scale with the screen, not with the user's resize preference.
- Adding maximum-scale=1 or user-scalable=no to the viewport meta tag, blocking pinch-zoom on mobile.
- Testing only at device breakpoints and never at 200% text size or 400% page zoom.
Avoid When
- Content genuinely requires two-dimensional layout to be meaningful, such as maps, complex data tables, or diagrams that WCAG 1.4.10 explicitly exempts.
- A print stylesheet where reflow and user font scaling do not apply to the rendered medium.
When To Use
- Any text-based web content that low-vision users may need to enlarge, which is essentially all body and UI text.
- When building layouts that must pass WCAG 1.4.4 (200% text) and 1.4.10 (400% reflow) for AA conformance.
- When supporting mobile users who pinch-zoom or set large system font sizes.
Code Examples
/* Fixed pixel sizing ignores user font preference */
/* and clips enlarged text */
.card {
width: 300px;
height: 120px;
overflow: hidden;
}
.card h2 {
font-size: 18px; /* px - does not honor base font size */
line-height: 24px; /* fixed - text overlaps when scaled */
}
.hero-title {
font-size: 5vw; /* scales with viewport, not user zoom */
}
<meta name="viewport"
content="width=device-width, maximum-scale=1, user-scalable=no">
<!-- Blocks pinch-zoom entirely -->/* Relative units honor the user's base font size; */
/* containers grow instead of clipping */
.card {
width: 100%;
max-width: 20rem;
min-height: 7.5rem; /* min, not fixed - can grow */
overflow: visible;
}
.card h2 {
font-size: 1.125rem; /* rem scales with root font size */
line-height: 1.5; /* unitless - scales with font-size */
}
.hero-title {
font-size: clamp(1.5rem, 1rem + 2vw, 3rem);
}
@media (max-width: 480px) {
.layout { display: block; } /* reflow to single column */
}
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- Allows pinch-zoom and page zoom -->