Most AI design agents have a blind spot: they design for the viewport they render. Ask an agent to produce a landing page and it will often compose for a 1280–1440 px desktop canvas and validate a mobile comp at around 390 px. Those defaults are treated here as a working hypothesis, not a measured fact. This post argues that WCAG 2.1/2.2 Success Criterion 1.4.10 Reflow is one of the best computable checks an agent can adopt precisely because it tests a viewport state the agent almost never renders: 320 CSS pixels wide, reached by zooming a 1280 CSS px desktop window to 400%.
We’ll cover what the criterion actually requires, which parts of it a machine can verify, which parts remain manual, and how to encode the checkable subset into an agent’s review loop.
What SC 1.4.10 Actually Requires
SC 1.4.10 Reflow is a Level AA requirement. The normative text, as explained in the W3C Understanding document for Reflow, says content must be presentable without loss of information or functionality, and without requiring scrolling in two dimensions for:
- vertically scrolling content, at a width equivalent to 320 CSS pixels;
- horizontally scrolling content, at a height equivalent to 256 CSS pixels.
In plain terms: a user must be able to consume the page by scrolling in one direction only. If they zoom in and then have to chase content left and right and up and down, the criterion fails.
Community guides such as Deque’s SC 1.4.10 resource and TheWCAG’s 1.4.10 page summarize the same criterion for practitioners.
The 1280→320 Mechanic, and Its 256 px Counterpart
The numbers look arbitrary until you read Note 1 of the Understanding document.
320 CSS px is defined here as a zoom-derived width, though it also approximates small phones. It is the computed result of taking a viewport that starts at 1280 CSS px wide and zooming to 400%. Similarly, the 256 CSS px height for horizontally scrolling content corresponds to a 1024 CSS px viewport height at 400% zoom (W3C Understanding Reflow).
That distinction matters for two reasons:
- The test is best run as a zoom test. The accessibility.build guide for 1.4.10 describes the procedure explicitly: set the window to 1280 CSS px, zoom to 400%, and scroll the whole page; it also accepts a 320 px window resize as an alternative. A horizontal scrollbar on non-exempt content fails. The Understanding document says a page-level scrollbar caused only by excepted content still passes if the rest of the page reflows, but it calls limiting two-dimensional scrolling to the excepted section the better practice (more on that below).
- Zoom and narrowing can differ. The same guide names a common testing mistake: “Testing only by narrowing the browser window, not by zooming — zoom does not always fire the same media queries a small device does.” 320 CSS px is the target in either form, a 320px window or 400% zoom on 1280. Both are valid test states, and zoom does not always fire the same media queries as a narrow device, so an agent should run both.
For agents, this suggests a two-branch check: render the narrow-device layout and compute the zoom-equivalent state, because they are different test states and can fail differently.
The Resolution-Bias Thesis
Here is the argument about why agents are likely to miss this criterion. AI design agents default to 1280–1440 px desktop compositions and roughly 390 px mobile comps. The working hypothesis is that these defaults mirror the resolutions in their training examples, templates, and screenshot pipelines; no source here measures that. The 320 CSS px reflow viewport is a derived state: it comes from combining a desktop canvas with 400% zoom, and, by the same hypothesis, default design and screenshot pipelines rarely capture it.
The consequence: an agent can produce a layout that is flawless at 1440 px and adaptive at 390 px, yet breaks at 320 CSS px — a fixed-width sidebar, a chart that forces horizontal scroll, a grid whose minimum column width exceeds the viewport. Reflow is the criterion that lives exactly in that unrendered gap, which is why it deserves a place in any agent’s automated accessibility contract.
The Computable Subset: What an Agent Can Actually Check
Not everything in 1.4.10 is machine-checkable, but a meaningful subset is. Here is what an agent can verify statically or programmatically, with sources.
Viewport meta violations
The W3C ACT rule “Meta viewport allows for zoom” (b4f0c3) checks that the viewport allows zoom, which is the precondition for reflow testing. The accessibility.build guide gives the failing values: user-scalable=no, or a maximum-scale below 2, both of which block the zoom that reflow depends on and fail 1.4.4 Resize Text too. An agent can parse the meta tag and flag these values without rendering.
Fixed-width overflow
Content wider than the viewport is detectable. The Chrome Lighthouse audit for content sized for the viewport is the audit web.dev points to for detecting overflowing content, and the underlying patterns are well known from web.dev’s responsive design basics: fixed pixel widths on containers and images without max-width: 100%. The accessibility.build common-mistakes list adds absolutely positioned elements that extend past the viewport edge. An agent reviewing generated CSS can flag fixed widths on full-page containers before any render happens.
The exempt-table container pattern
When a data table genuinely needs two-dimensional layout, the fix is to make only the table scroll, not the page. The accessibility.build guide specifies the container pattern: wrap the table in a container with overflow-x: auto, plus role="region", an aria-label, and tabindex="0" so keyboard users can reach and scroll the region. This is directly computable: an agent can check that any horizontally scrollable container carries all four properties.
The Comparison Table: Computable vs. Not Computable
| Test method | Computable by an agent | Not computable (manual) |
|---|---|---|
Viewport meta check (user-scalable=no, maximum-scale < 2) |
Yes — ACT rule b4f0c3 checks zoom permission | — |
| Fixed-width overflow detection | Partially — Lighthouse-style audits (content-width) flag obvious overflow | Whether the overflow belongs to an exempt container requires context |
Exempt container pattern (overflow-x: auto, role="region", aria-label, tabindex="0") |
Yes — all four properties are statically checkable | — |
| Whether reading still works at 320 CSS px | — | Yes — as accessibility.build puts it, reflow is “primarily a manual, visual check” |
| Whether content meaning survives reflow (F102) | — | Yes — see below |
| Whether each carousel panel fits independently | Partially — panel width is a computable CSS check | Panel usability at 320 CSS px |
The Exception Scope — and the “Table Exempt, Cells Not” Nuance
The SC text sets the exception: content that requires two-dimensional layout for usage or meaning is exempt. Note 2 of the W3C Understanding document gives examples, including images required for understanding (maps, diagrams), video, games, presentations, data tables, and interfaces where toolbars must remain in view.
But the intent text in the W3C Understanding page adds the nuance agents most often miss: while a table or map as a whole is exempt, “sections of content within the two-dimensional layout, such as each cell within a table, would still need to meet this success criterion.” A table can scroll horizontally as a unit; an individual cell cannot force its reader to scroll within the cell. The same document’s carousel example makes the point structurally: each individual panel must fit a 320 CSS px viewport so the user scrolls in one direction per panel.
For an agent, this yields a clean rule: exempt the two-dimensional component, never the content inside it.
F102: The Failure That Hides
The Understanding document lists one published failure technique: F102 — content disappears when reflowed (W3C Understanding Reflow). This is an easy-to-miss reflow failure: it produces no scrollbar, only missing content. Content that is hidden, clipped, or collapsed at the reflowed width simply vanishes for the zooming user.
This is also where the computable boundary is sharpest. An agent can check that a horizontal scrollbar exists; it cannot check that nothing silently vanished without rendering and comparing content at both widths. web.dev’s responsive basics makes the adjacent point under “Avoid hiding content”: screen size does not predict what a user needs, so hiding content at narrow widths is a design smell even when it passes a scrollbar check.
Techniques an Agent Can Encode
Three W3C techniques map directly onto code the agent writes:
- C31 — using CSS flexbox to reflow content, so flexible containers replace fixed ones (W3C Understanding Reflow).
- C32 — using media queries and grid CSS to reflow columns (W3C Understanding Reflow).
- G224 — accounting for meaningful text indentation in lists and code blocks; the Understanding page presents these as cases that may keep horizontal scroll and suggests reducing indentation at zoomed sizes (W3C Understanding Reflow).
A generation-time linter can prefer flex/grid over fixed widths (C31), prefer media-query column reflow (C32), and reduce indentation on nested structures at zoomed sizes (G224).
Two Adjacent Failure Modes
Two neighboring criteria are often affected by the same fixed-canvas layouts:
- Text spacing (1.4.12). Per the W3C Understanding document for Text Spacing, users may override line height (≥ 1.5× font size), paragraph spacing (≥ 2×), letter spacing (≥ 0.12×), and word spacing (≥ 0.16×). Fixed-height containers clip the enlarged text — text cut off and overlap are listed failures. The accessibility.build 1.4.12 guide covers the same mechanics. Text-spacing overrides and narrow containers can interact: the Understanding page lists text cut off and overlap as failures.
- Focus not obscured (2.4.11). Sticky headers and footers can fully hide the focused element after a reflow; the sufficient technique is C43, using scroll-padding (W3C Understanding 2.4.11).
What Remains Manual — and Why That’s the Point
The summary comes from accessibility.build: automated tools can flag a disabled viewport or obvious overflow, but they “cannot judge whether reading still works.” Zooming to 400% and reading the page is a human judgment about comprehension, reading order, and cognitive load.
That limitation is not a reason to skip the check — it’s a reason to scope the agent’s claim correctly. An agent can guarantee the computable subset (viewport meta, container pattern, fixed-width smells, G224/C31/C32 preferences) and flag the residual risk (F102-style disappearance, reading flow) for human review. That division of labor is the realistic contract for agentic accessibility work.
For broader regulatory context — why AA conformance matters commercially — see our earlier post on building an accessibility compliance agent; this post deliberately does not re-cover that ground.
FAQ
Does passing a 390 px mobile render mean reflow passes?
No. The 320 CSS px reflow state is reached by zooming a desktop-width viewport to 400%, and zoom does not always fire the same media queries a small device does (accessibility.build, 1.4.10). The two states can produce different layouts with different failures. Test both.
Is a horizontally scrolling data table a reflow failure?
Not if the table itself requires two-dimensional layout — tables are explicitly exempt in Note 2 of the Understanding document. But best practice is to keep the page from scrolling as a result: wrap the table in a container with overflow-x: auto, role="region", an aria-label, and tabindex="0" (accessibility.build). And individual cells still must meet the criterion.
Can an AI agent fully automate a reflow audit?
No. It can fully automate the viewport meta check (thresholds from accessibility.build) and statically verify the exempt-container pattern and fixed-width smells. But judging whether content remains readable and nothing disappears (F102) at 320 CSS px is a manual, visual check, as accessibility.build states directly.
Why 320 and 256 CSS pixels specifically?
They are the zoom-derived equivalents: 320 CSS px is a 1280 px viewport at 400% zoom, and 256 CSS px is a 1024 px viewport height at 400% zoom (W3C Understanding Reflow). The figure is chosen to match both small displays and 400% zoom on a desktop.
The Bottom Line
Verdict: adopt 1.4.10 as a two-tier agent check. Tier one is largely computable today: the viewport meta and the exempt-container pattern are fully statically checkable, fixed-width overflow is only partially checkable, and C31/C32/G224 patterns can be preferred at generation time. Tier two — does the page actually read at 320 CSS px, and did anything vanish — stays human. An agent that claims only tier one is being honest; an agent that claims the whole criterion is overstating what automation can do. Given the resolution-bias hypothesis — agents designing for 1280–1440 desktop and 390 mobile and rarely rendering the zoom-derived state — reflow is a check worth adding, because it probes a viewport the agent rarely sees.
How This Guide Was Built
This post is desk research of published specifications and fetched guides: the W3C Understanding documents for 1.4.10, 1.4.12, and 2.4.11, and community guides from Deque, accessibility.build, TheWCAG and web.dev. No hands-on zoom or browser test was run by the author; no site was measured, and no screenshots were taken. Caveats: some W3C pages could not be retrieved during research, so only pages that were retrieved and checked are cited; tool coverage for reflow is manual-heavy, per the sourced statement above; and the resolution-bias claim about agent defaults is this blog’s thesis, presented as an argument rather than a sourced statistic.