Accessibility in practice
Test responsive accessibility across widths and page states
Combine measured multi-viewport scans with keyboard, zoom and visible-state review when responsive layouts reveal a different interface.
By A11y Scan editorial team
Published
Updated
Responsive pages can contain more than rearranged desktop content. Navigation may become a menu button, a table may scroll and a form may reveal new instructions or errors. Scanning several widths helps inspect rendered versions, while meaningful review also exercises the tasks people need to complete.
Choose widths around real changes
Imagine a shop whose desktop header shows navigation links and whose narrow header replaces them with a menu button. Start with a wide layout and a width where that menu appears. Add conditions where the checkout form changes or a fixed banner overlaps content. Device names are shorthand; evidence should describe measured browser widths in CSS pixels.
Enable multi-viewport scanning for a single-page scan and choose the widths. Review the measured width of each result. Browser window constraints can prevent a requested width, and an individual capture can fail. A failed width is not a clean accessibility result and should remain visible in the report.
A width does not open the menu
The initial narrow state may contain a well-named menu button while its panel stays hidden. Scanning that state does not establish whether keyboard activation opens the menu, focus moves appropriately, links are understandable or dismissal works. Open it yourself and perform the task.
Use a workflow session for named snapshots after your own actions. Capture the initial state, open the menu and capture the visible panel. Operate it with the keyboard and a real screen reader where relevant. Captures collect findings for the rendered states; they do not replay actions or establish correct keyboard behavior.
Include errors and fixed content
Repeat this approach for an invalid form submission. Check whether errors are identifiable, explain a known correction and are available to assistive technology. A scanner may report a structural or naming issue, while the clarity of instructions and the experience of correcting an error require judgment.
At relevant widths, move focus through the page with sticky headers, banners and dialogs present. Check reachability and visibility after scrolling. A fixed element that looks harmless at the top can cover a focused control later. Record the actual state and steps instead of labeling the whole responsive page as passed.
Check zoom and reflow separately
Resizing a window is useful but does not replace checking text resizing and zoom behavior. WCAG's Reflow and Resize Text criteria have specific requirements and exceptions. Consult W3C guidance and test the required conditions for lost content or functionality. A horizontal scrollbar alone is not enough to decide whether a particular exception applies.
For example, a data table can have different two-dimensional layout needs from a paragraph. Keep table relationships understandable and check the surrounding text, controls and instructions at the narrow condition. Distinguish necessary table layout from an unnecessarily wide surrounding page.
Keep the report bounded
Export the measured viewport report and retain manual notes with it. Record tested menu, error and dialog states, failed widths and the effective configurations. A finding at one width describes that capture; its absence at a second width does not establish that the interaction is usable there.
Multi-viewport scanning currently stays separate from Movie and Crawl, and workflow capture is a distinct single-page review. Use these supported workflows deliberately. After a fix, repeat the widths and actions, then interpret automated findings alongside keyboard and assistive-technology observations.