Most accessibility advice about zoom and text size stops at “make sure people can zoom in.” That’s true as far as it goes, but two separate WCAG 2.1 AA success criteria go further than simple zooming: one requires your layout to survive being viewed at 400% magnification without forcing a shopper to scroll in two directions, and the other requires it to survive a user overriding your CSS with their own line spacing and letter spacing — something a real, if small, share of low-vision and dyslexic visitors actually do. Both are frequently untested because neither shows up in a typical manual QA pass, and both tend to break in the same places on e-commerce sites: cart tables, sticky checkout bars, and price/quantity columns built with fixed widths and fixed heights.
Quick answer: WCAG 1.4.10 Reflow (Level AA) requires that content be presented without loss of information or functionality and without requiring two-dimensional scrolling, at a viewport equivalent to 320 CSS pixels wide (or 1280 CSS pixels at 400% browser zoom) — with narrow exceptions for content that’s genuinely two-dimensional, like maps, data tables, or video. WCAG 1.4.12 Text Spacing (Level AA) requires that when a user overrides your CSS with their own spacing — line height to at least 1.5× the font size, paragraph spacing to at least 2×, letter spacing to at least 0.12×, and word spacing to at least 0.16× — no content gets clipped, overlapped, or cut off. Both fail most often on fixed-width or fixed-height containers: a cart line-item row, a sticky “Add to Cart” bar, or a promo badge sized just tightly enough to fit the default text.
This is educational content about technical accessibility standards, not legal advice. Meeting WCAG 2.1 AA does not guarantee legal compliance with the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
Why this is a different failure than “text is too small”
SC 1.4.4 Resize Text (Level AA, covered in our 5-minute self-check) is about whether a user can enlarge your text at all, up to 200%, using ordinary browser zoom. Reflow and text spacing are a level deeper: they’re about what happens to your layout once someone has already done that. A site can pass the “can I zoom in” test and still fail badly here — the text gets bigger, but a fixed-width sidebar stays fixed-width, so now the page scrolls sideways as well as down, or the enlarged text spills out of a card that was only ever sized for the default font.
The W3C’s own reasoning for 1.4.10 makes the target audience explicit: the goal is to “let users enlarge text and other related content without having to scroll in two dimensions to read.” Two-dimensional scrolling — sideways and down — is markedly harder for people with low vision using screen magnification, and for anyone with a motor impairment for whom precise scrolling in two directions is more effortful than scrolling in one.
Text spacing addresses a different population with a similar mechanism: some people with low vision or dyslexia use a browser extension, a user stylesheet, or (increasingly) their operating system’s own accessibility settings to widen the spacing between lines, words, and letters — independent of font size. The Understanding doc states this directly: people with low vision “who require increased space between lines, words, and letters are able to read text,” and people with dyslexia “may increase space between lines, words, and letters to increase reading speed.” Your site doesn’t apply this spacing itself — the visitor does, and SC 1.4.12 is about whether your layout tolerates it once they have.
Where reflow actually breaks on e-commerce layouts
At a 320px-equivalent viewport (or 400% zoom on a wider screen), a page has to present everything without scrolling in two directions — vertical scrolling is fine and expected, horizontal scrolling generally is not. The most common e-commerce culprits:
- Cart and order-summary tables built with fixed pixel-width columns for product name, price, quantity, and remove button. At 400% zoom, the row either overflows sideways or the product name column gets crushed to a sliver.
- Sticky “Add to Cart” bars and filter toolbars pinned with a fixed height. Enlarged text inside a fixed-height bar gets clipped instead of the bar growing to fit it.
- Multi-column checkout forms (shipping address next to a persistent order summary) that don’t collapse to a single column, so the whole layout — not just the text — has to be scrolled both ways to complete a purchase.
The fix in each case is the same general move covered by Technique C32 (media queries and grid CSS), C31 (CSS Flexbox), and G206: let columns stack instead of compress, size containers with relative units (%, rem, min()/max()) instead of fixed pixel widths, and set a min-height rather than a height on anything that wraps text so it can grow.
The one deliberate exception is genuinely two-dimensional content — the Understanding doc names data tables and grids specifically, because a table’s row/column relationship is meaningless if you collapse it. Our size-chart article covers that exception in detail for spec tables. It’s a narrow carve-out, though: the doc is explicit that “if a section of content meets the exception for two-dimensional scrolling, the exception only applies to that section” — a wide, scrollable size chart doesn’t excuse the checkout form on the same page from reflowing normally.
Where text spacing actually breaks
Text spacing failures show up wherever a container was sized to fit exactly the default text and nothing more:
- Price and sale badges (“−20%”, “New”) built as a fixed-size pill. Widened letter and word spacing pushes the text past the pill’s edge, and
overflow: hiddensilently clips it instead of letting it grow. - Product cards in a grid, where a fixed card height means a two-line product title with extra line spacing pushes into the price or button below it — overlapping content, not just cramped content.
- Buttons with fixed dimensions (
height: 40px, nomin-height) where increased line height on the label text gets vertically clipped instead of the button growing.
You don’t need special hardware to check this. Open your browser’s DevTools, find the Styles or “new rule” panel, and add a rule targeting * (or your page’s main content wrapper) with the exact SC values:
* {
line-height: 1.5 !important;
letter-spacing: 0.12em !important;
word-spacing: 0.16em !important;
}
p {
margin-bottom: 2em !important;
}Apply that, then look at your product cards, badges, and buttons. Anything that clips, truncates, or overlaps another element fails 1.4.12 — that’s Failure F104 by name. For reflow, resize your browser window down to roughly 320px wide (or set zoom to 400% on a 1280px-wide window) and check the same pages for sideways scrolling on anything other than a genuine data table.
FAQ
Does “text can zoom to 200%” (SC 1.4.4) already cover this? No. 1.4.4 only requires that zooming be possible without losing content. 1.4.10 and 1.4.12 separately require your layout to hold up once someone has zoomed in or overridden your spacing — a site can pass one and fail the other.
Is it okay for a size chart or data table to require horizontal scrolling at 320px? Yes — SC 1.4.10 explicitly exempts genuine data tables and grids, since collapsing their row/column structure destroys the information. Everything else on the same page still has to reflow normally. See our size-chart article for the table-specific version of this exception.
Do I need to build a special “large text” mode to meet SC 1.4.12? No — the requirement is that your existing layout tolerates a user’s own CSS override, not that you build spacing controls yourself. In practice this mostly means avoiding fixed heights on anything that contains text.
Get a full layout review, not just these two checks
This covers two specific, easy-to-miss success criteria — a full Quietramp audit checks your whole site against WCAG 2.1 AA, including reflow and text-spacing behavior verified by a person actually resizing and overriding your pages, not just an automated scanner (which typically can’t detect either failure mode at all). See a real sample report, or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This is educational content about technical accessibility standards, not legal advice. Meeting WCAG 2.1 AA does not guarantee legal compliance with the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.