Build coverage around customer tasks
List the routes and outcomes that create value: finding a service, searching, adding an item, booking, signing in, asking for help, or paying. For each, name the components that can change shape or fail: navigation, filters, cards, tables, images, banners, forms, drawers, and embedded widgets. Test widths where your content becomes constrained, not merely a catalogue of current phone models. Test just below, at, and just above each breakpoint.
Include narrow and mid-width phones, a tablet-like width, laptop, wide desktop, and landscape when it changes the task.
Use long titles, empty results, validation errors, price badges, full addresses, and longer labels when those states exist.
Prove reflow, reading, and zoom
Confirm the page has an appropriate viewport setting, then look for page-level horizontal scrolling. Fixed images, wide fields, negative margins, off-canvas panels, and banners are common causes. W3C’s WCAG 2.1 Reflow criterion describes vertical-scrolling content at a width equivalent to 320 CSS pixels, including a 1280-pixel viewport at 400% zoom. If that criterion is in scope, test the actual zoom scenario. A map, video, or data table may need two-dimensional layout, but keep that scroll within the component and let the surrounding page reflow.
Check headers, main content, footers, sticky bars, dialogs, and error summaries at every tested boundary.
Reorganize information for a narrow screen; do not silently remove a requirement, price detail, or help path.
Stress content and forms
Content operations can cause responsive failures without a CSS release. Test the longest approved heading, several badges, a missing image, a selected filter, a large legal notice, and a browser-filled field. When columns stack, confirm that the reading and keyboard order still make sense. Complete the real form on a small device: open controls, correct an error, and submit. Test third-party widgets in the production-like page because their container, consent state, fonts, and styles can alter the result.
Reflect likely maximum lengths and combinations, but do not include customer or payment data in QA evidence.
Open notices, chat, promotions, and validation messages together; none should cover the primary action or focused field.
Exercise every input path
A large screen does not guarantee a mouse, and a small screen does not guarantee touch alone. The hover media feature tests whether a primary input can conveniently hover, so hover should enhance rather than be the only route to an action or explanation. Test keyboard and pointer use on desktop, taps and scrolling on a touch device, and mixed-input devices where relevant. Review compact close buttons, steppers, chips, calendars, and icon actions. WCAG 2.2 Target Size (Minimum) specifies a 24 by 24 CSS-pixel target size with defined exceptions, including spacing and inline links. It is a criterion with scope and exceptions, not a promise that every 24-pixel control is equally easy for everyone.
Tab through the page. Focus should remain visible, follow a sensible order, and enter and exit menus and dialogs predictably.
Make an essential hover reveal available by focus, tap, or a visible control, and prevent confusing first-tap behavior.
Verify assets and performance under constraint
An image can fit its container and still be the wrong file for the device. Check that media stays contained, reserves layout space where applicable, preserves its useful crop, and requests suitable candidates. Srcset and sizes give the browser information to choose among supplied image sources; they do not guarantee a particular request. Use DevTools throttling to uncover problems early, but its CPU and network controls simulate conditions relative to the development computer. Recheck key journeys on a real device and connection. Inspect fonts, hero media, carousels, client-side work, and third-party scripts for delays, shifts, or blocked taps.
Capture the route, viewport, real or simulated connection, and what became slow or unstable; compare like conditions.
Where safe, delay nonessential embeds in a test build to learn whether the core task remains usable.
Remediate as proactive uptime work
For Status Is UP, responsive readiness is proactive uptime optimization: identify a user-blocking device path, correct its cause, prove the repair, and prevent recurrence. It is not a claim that a monitoring alert can judge every layout or interaction defect. Prioritize by task impact and reach. Before deployment, test adjacent widths and the changed journey on real hardware. Plan a rollback for changes to shared navigation, styles, scripts, payments, or integrations. After release, repeat the proof steps and attach the evidence to the change record.
State route, device or viewport, orientation, input, state, expected result, actual result, and a redacted capture.
Prefer a component, layout rule, token, or image-delivery fix over a route-only override; give exceptions an owner and removal plan.