Accessibility prompts: inspect zoom and reflow states

Last updated: 5 Oct 202611 min read

tutorial

A reflow prompt should fix the viewport width, zoom or text enlargement, route, language, and interface state before reviewing the result. Ask for clipped content, horizontal scrolling where reading should remain vertical, overlapping controls, hidden error text, and lost functionality. A desktop screenshot cannot prove that a form works at a narrow width. The reviewer should also check long localized labels and the opened dialog, since a page that reflows at rest may fail after validation or expansion.

Operational case

At a narrow viewport, Harbor's booking form displays the pickup-code error below the fold. That is acceptable if it remains reachable and linked; however, the opened confirmation dialog has a fixed width and its final action falls outside the visible area. The reviewer records viewport, zoom, dialog state, and the blocked action. The engineer repairs the layout, then retests with the same conditions and a longer translated button label.

Route /booking | build B-47
Viewport: 320 CSS px | zoom: 200%
State: confirmation dialog open
Observed: final action clipped and unreachable
Retest: same state plus long translated label

Performance and review cost

For V viewport settings and S states, the direct test matrix is O(VS) render-and-interaction checks. Prioritize states that can hide a required action, then sample shared components across routes. Automated screenshots help compare layout changes, but a reviewer must still verify that clipped controls can be reached and operated.

Common Mistakes

Do not test only the idle desktop page.
Do not call every horizontal scroll a failure without considering the content type.
Do not close a reflow issue from a screenshot without trying the action.

Connected lessons

prompt engineering

accessibility review