Reflow

Reflow is the accessibility check that asks whether a screen still works when the view changes.

A person may zoom in, enlarge text, use browser magnification, split their screen, rotate a device, or work in a narrow viewport. The layout should adapt without hiding content, breaking the reading order, or making the person scroll in two directions just to complete the task.

This is closely related to responsive design, but it is not the same thing.

Responsive design usually checks whether the layout has useful breakpoints.

Reflow checks whether the actual task still works when content is enlarged or space is constrained.

The common project moment

A team says the page is responsive.

At the usual desktop size, the screen looks good. At the main mobile breakpoint, it also looks good. The layout uses modern components, flexible cards, collapsible menus, and a design system that seems to handle different screen widths.

Then someone zooms the page to 200 percent or uses a narrower viewport and starts walking through the real workflow.

The problem is not always obvious at first glance.

It shows up when the person tries to complete the task:

• the primary action is pushed off-screen;
• form labels, helper text, or errors are clipped;
• a table forces horizontal scrolling across the whole page;
• a sticky header or footer covers content;
• a modal becomes taller than the viewport and traps the next step;
• focus lands on controls that are hard to see after the layout wraps;
• content appears in a different visual order than the reading or keyboard order.

That is when “responsive” stops being enough.

Use this when

Use this page when a screen includes:

• multi-column layouts;
• cards, tiles, dashboards, or summary panels;
• forms with labels, instructions, helper text, errors, or grouped controls;
• data tables or wide comparisons;
• sticky headers, sticky footers, sidebars, or fixed-position controls;
• dialogs, drawers, popovers, menus, date pickers, or autocomplete results;
• charts, maps, reports, or dense visual displays;
• workflows that must be completed in a browser, webview, tablet, or small laptop window.

Start with the task path

Do not start by judging the screenshot.

Start by walking the path someone actually needs to complete.

For example:

• find the page;
• read the instructions;
• complete the form;
• trigger an error;
• recover from the error;
• open any menu or dialog;
• review a table or result set;
• submit or save;
• confirm what happened.

Then repeat that path with the page zoomed and the viewport narrowed.

The question is not only, “Does the layout still look acceptable?”

The better question is:

Can someone still complete the workflow without losing content, controls, instructions, focus, or meaning?

Check whether content wraps instead of disappearing

Reflow problems often show up as clipping, overlap, or fixed containers.

Look for:

• text cut off inside cards, buttons, tabs, table cells, or form fields;
• content hidden behind fixed headers, footers, chat widgets, or side panels;
• error messages that appear but are partly covered;
• buttons that move outside the visible area;
• labels that no longer stay connected to their fields;
• tooltips or popovers that open off-screen.

Content can change shape. It should not silently disappear.

Watch horizontal scrolling

WCAG reflow does not say every single thing can never scroll horizontally.

Some content, such as maps, diagrams, data tables, and complex visual presentations, may need a two-dimensional view.

But ordinary page content and task flow should not require sideways scrolling just to read, navigate, or operate controls.

When horizontal scrolling appears, ask:

• Is this because the content is genuinely two-dimensional?
• Or is the layout refusing to stack, wrap, resize, or simplify?
• Can the person still understand the page without scrolling both ways?
• Is only the table or graphic scrolling, or is the entire page forced sideways?
• Are important controls or labels outside the visible area?

If the whole workflow becomes a sideways hunt, the layout is not reflowing well enough.

Forms need special attention

Forms often look fine until labels, helper text, validation messages, and grouped controls wrap.

Check:

• labels stay visible and close to the correct field;
• required-field indicators still make sense;
• helper text remains readable;
• error messages identify the field and recovery path;
• grouped controls such as radio buttons and checkboxes stay understandable;
• submit, cancel, save, and next-step buttons remain reachable;
• field focus is visible after the layout changes.

A form that technically fits the viewport can still be hard to use if the relationship between label, instruction, input, and error breaks.

Tables and dashboards need a plan

Wide data displays are one of the hardest reflow cases.

Sometimes the right answer is not to squeeze the table until it becomes unreadable.

Possible patterns include:

• allow the data table itself to scroll while the rest of the page stays stable;
• provide a stacked card view for narrow layouts;
• let users choose which columns matter;
• keep row and column context visible;
• provide summaries or filters before dense results;
• avoid placing critical actions only at the far right of a wide row.

The goal is not to pretend every table is simple.

The goal is to make sure people can still understand and act on the information.

Check focus after the layout changes

Reflow can change what is visible, but keyboard focus still has to make sense.

After zooming or narrowing the viewport, tab through the page.

Watch whether:

• focus is visible;
• focus order follows the task order;
• focus does not land behind sticky content;
• menus and dialogs keep focus in a predictable place;
• opening and closing content does not leave the person lost;
• the focused control is not partly clipped or hidden outside the viewport.

A screen can visually reflow and still create a keyboard problem if focus does not follow the usable path.

Questions teams can ask

Ask these before the screen goes to final review:

• What happens at 200 percent browser zoom?
• What happens in a narrow desktop viewport, not only a phone-sized mockup?
• Can the main task still be completed without sideways scrolling across the whole page?
• Do labels, helper text, errors, and actions remain visible?
• Do sticky headers, footers, sidebars, or widgets cover content?
• Do dialogs, menus, popovers, and drawers still fit and scroll predictably?
• Can someone use the keyboard and see where focus goes after the layout changes?
• Are wide tables handled intentionally, or are they just overflowing?
• Does the reading order still match the visual order after wrapping?

Common trail hazards

• Treating one mobile breakpoint as proof that reflow works.
• Testing zoom on the home page but not inside forms, tables, dashboards, or modals.
• Checking the layout visually without completing the task.
• Allowing the entire page to scroll horizontally because one component is too wide.
• Letting sticky headers, banners, footers, or chat widgets cover content.
• Assuming clipped helper text is a cosmetic issue.
• Forgetting to trigger errors, validation states, empty states, loading states, and expanded content.

A small habit

When reviewing a screen, add one simple pass:

Zoom in, narrow the window, and complete the real path.

If you cannot finish the task without hunting sideways, losing controls, or guessing what got clipped, the layout needs attention before formal review.

WCAG trail markers

• WCAG 2.1 Success Criterion 1.4.10 Reflow — content can be presented without loss of information or functionality and without scrolling in two dimensions, except for parts of content that require two-dimensional layout.
• WCAG 2.1 Success Criterion 1.4.4 Resize Text — text can be resized without loss of content or functionality.
• WCAG 2.1 Success Criterion 2.4.7 Focus Visible — keyboard focus is visible as people move through the page.
• WCAG 2.1 Success Criterion 1.3.2 Meaningful Sequence — reading and navigation order should still make sense after layout changes.

Related resources

• <a href="/accessibility-field-guide/reflow-review-checklist/">Reflow Review Checklist</a>
• <a href="/accessibility-field-guide/tables-and-data-displays/">Tables and Data Displays</a>
• <a href="/accessibility-field-guide/forms-and-labels/">Forms and Labels</a>
• <a href="/accessibility-field-guide/keyboard-only-navigation/">Keyboard-Only Navigation</a>
• <a href="/accessibility-field-guide/focus-visible-and-focus-order/">Focus Visible and Focus Order</a>

What to do next

Use <a href="/accessibility-field-guide/reflow-review-checklist/">Reflow Review Checklist</a> on one real screen that has a form, table, modal, dashboard, or sticky layout.

Do the check before formal accessibility review so reflow issues are found while the layout is still easier to adjust.