Accessibility Field Guide

Reflow Review Checklist

A practical checklist for checking whether a screen still works when people zoom, resize, or use a narrow viewport.

Original Field Notes diagram: a practical checklist for reviewing reflow behavior across real task paths.

Use this checklist when reviewing whether a screen still works after zooming, resizing, or using a narrow viewport.

The goal is not to make every layout look identical at every size.

The goal is to make sure people can still read, navigate, and complete the task without losing content, functionality, focus, or meaning.

The common project moment

A page passes the basic responsive check.

The desktop view looks good. The mobile breakpoint works. The component library seems to adapt.

Then someone zooms in, narrows the browser, opens a modal, triggers a validation error, or tries to use the page with only the keyboard.

That is when hidden reflow problems appear.

Use this checklist before formal review, especially on forms, dashboards, tables, card layouts, workflows, and pages with sticky or fixed-position UI.

Setup for the check

Identify the real task path someone needs to complete.
Include at least one state beyond the default view, such as an error, expanded menu, dialog, filter, or result set.
Test in a desktop browser, not only a phone emulator.
Zoom the browser to 200 percent.
Narrow the viewport and repeat the task path.
Use the keyboard for at least one pass.
Check the page after content wraps, not only after it first loads.

Page-level layout checks

Main content reflows into one direction of scrolling for ordinary page content.
The page does not require horizontal scrolling to read ordinary text or operate ordinary controls.
Content is not clipped, overlapped, or hidden after zooming.
Primary actions remain visible or reachable.
Navigation remains usable when collapsed or wrapped.
Banners, alerts, breadcrumbs, pagination, and footers remain readable.
Empty states, loading states, and confirmation states still fit the viewport.
The visual order still matches the reading and task order.

Text, labels, and instructions

Headings and body text wrap without being cut off.
Button and link text remains readable.
Form labels stay visible and connected to the correct fields.
Helper text and instructions remain readable.
Error messages identify the field, problem, and recovery path after wrapping.
Required-field indicators still make sense when labels wrap.
Tooltips, help text, and disclosure content do not open off-screen.
Text does not overlap icons, badges, inputs, or other nearby content.

Forms and workflows

The form can be completed at 200 percent zoom.
The submit, save, next, cancel, and back actions remain reachable.
Field groups such as radio buttons and checkboxes remain understandable.
Multi-step forms preserve progress, instructions, and current step context.
Validation errors are visible without forcing the person to hunt sideways.
Error summaries link or move focus to the right fields when used.
Date pickers, autocomplete lists, dropdowns, and file-upload controls remain usable.
The workflow can still be completed after errors are triggered and corrected.

Sticky, fixed, and floating UI

Sticky headers do not cover headings, form fields, error messages, or focused controls.
Sticky footers do not cover primary actions or validation messages.
Sidebars, chat widgets, feedback buttons, and cookie banners do not block the task.
Skip links and in-page links land in a visible place, not hidden under fixed content.
Floating controls remain reachable without covering other controls.
Dismissible overlays can be dismissed with keyboard and pointer.

Dialogs, drawers, menus, and popovers

Dialogs fit the viewport or scroll internally in a predictable way.
The dialog title, instructions, content, and primary actions remain reachable.
Focus moves into the dialog when it opens and returns predictably when it closes.
Drawers and side panels do not create two-direction page scrolling.
Menus and popovers open within the viewport where possible.
Autocomplete results or dropdown options do not cover the input in a way that blocks use.
Closing the component does not leave focus lost or hidden.

Tables, dashboards, and dense data

Wide tables have an intentional narrow-view pattern.
If a table scrolls horizontally, the rest of the page does not become unstable.
Row and column context remains understandable.
Important actions are not only placed at the far right of a wide row.
Filters, search, sorting, pagination, and export actions remain reachable.
Chart labels, legends, and values remain readable or have a usable alternative.
Cards or stacked views preserve the same important information as the wide layout.
Dense displays do not hide status, error, or warning information when narrowed.

Keyboard and focus checks

Every interactive element can still be reached with the keyboard.
Focus is visible at 200 percent zoom.
Focus order follows the visual and task order after layout changes.
Focus does not land behind sticky headers, footers, or overlays.
The focused element is not clipped or outside the visible viewport.
Opening and closing menus, dialogs, and disclosures keeps focus predictable.
No keyboard trap appears after content wraps or scroll regions appear.
The page can be completed without switching between horizontal and vertical scrolling for ordinary controls.

Questions to ask the team

What screen sizes, zoom levels, and constrained views did we actually test?
Did we complete the real task path, or only inspect the layout?
Which components are most likely to clip, overlap, or overflow?
Are tables and dense displays intentionally designed for narrow views?
Does the keyboard path still match the visual path?
Are there sticky or fixed elements that could cover content?
What should be fixed in the shared component instead of one screen?

WCAG trail markers

What to do next

Pick one important workflow and run this checklist before formal review.

If the same issue appears in multiple places, fix the shared layout, component, or design pattern instead of treating each screen as a one-off defect.