Responsive QA is often reduced to three screenshots: mobile, tablet, desktop. The pictures look polished, the ticket closes, and the first real user with a long surname or visible keyboard focus finds the part nobody exercised. This Skill treats responsive behavior as a change in available space, content priority, reading order, and interaction—not as a collection of device frames.
What the Skill reviews
The workflow combines a mechanical pass with a human pass. Measurements find page-level overflow, out-of-viewport elements, viewport/document dimensions, console errors, and visible headings. Human inspection decides whether content disappeared, a table scrolls intentionally, a sticky banner hides the active control, the mobile hierarchy still makes sense, or the visual order conflicts with keyboard order.
That separation matters. An automated check can report that scrollWidth exceeds innerWidth. It cannot tell whether the excess belongs to an intentionally scrollable data table or whether the page has lost functionality. A screenshot can show a drawer. It cannot prove that a keyboard user can open, traverse, and dismiss it.
The default matrix is small on purpose
Unless the product has its own device contract, the Skill starts at 390×844, 768×1024, and 1440×900 CSS pixels. It adds 320 CSS pixels for a reflow review and widths immediately before and after a suspected breakpoint.
This is a diagnostic matrix, not a device-coverage claim. Its job is to expose changes in structure. If a card grid shifts at 720 pixels, testing 719 and 721 is usually more informative than adding five popular phone models that all use the same narrow layout.
Pass 1: collect boring facts
At every viewport, record the final URL, page identity, browser, inner dimensions, root scroll dimensions, visible top-level headings, fixed or sticky regions, and a full-page screenshot. When Node.js and Playwright are available, the optional collector in the bundle does this without clicking controls.
The collector deliberately reports candidates rather than conclusions. It checks a limited set of headings and interactive elements whose bounding boxes exceed the viewport. It retains console errors without assuming each error was caused by the reviewed page. It does not install an accessibility scanner, transmit data, or modify the app.
Pass 2: review what changed
Compare the actual experience across widths. Ask:
- Did a required action disappear, or was it relocated into a usable menu?
- Can long labels, translated copy, URLs, code, and validation messages fit without clipping?
- Does a desktop side panel become a sensible sequence on mobile?
- Does the most important action remain distinguishable without crowding everything else?
- Can dialogs, filters, date pickers, and table controls still open and close?
- Do sticky headers, chat launchers, consent panels, and footers cover content or focus?
- Does CSS reordering create a different story from the DOM and keyboard sequence?
This is where “technically fits” separates from “usable.” A toolbar can fit at 390 pixels because every label has been reduced to an unexplained icon. That is not overflow, but it may still be a hierarchy and comprehension problem.
Make keyboard testing part of responsive testing
Narrow layouts often introduce new components: hamburger menus, bottom sheets, carousels, collapsed filters, and sticky action bars. Those components change the focus path. Starting from a known location, tab through the in-scope controls, confirm that focus remains visible, and verify that overlays can be dismissed without trapping the user.
Pay special attention to fixed elements. A focused button can exist in the DOM, be technically operable, and remain entirely hidden beneath a sticky footer. That is why the report records both focus behavior and the visible rectangle.
Use finding categories that point to the right conversation
| Category | Observed problem | Typical owner conversation |
|---|---|---|
REFLOW | The page requires unintended two-dimensional scrolling or loses information/function. | Layout and content structure |
CLIPPING | Text or a control extends beyond its visible container. | Wrapping, min-width, sizing, localization |
OBSCURED | Fixed content covers an action, message, or focused control. | Sticky regions, offsets, dismissal |
ORDER | Visual, reading, and focus order materially disagree. | DOM order and CSS layout |
INTERACTION | A responsive-only control cannot be reached, used, or dismissed. | Component behavior and input methods |
HIERARCHY | The mechanics work, but priority becomes confusing. | Content design and product intent |
EVIDENCE_GAP | A required state could not be safely observed. | Test setup or authorization |
Categories prevent every issue from becoming “mobile broken.” They also keep an unobserved cause out of the title. A reviewer can say the action row extends 84 pixels past the viewport without guessing which utility class caused it.
Write findings developers can reproduce
A strong finding records the exact viewport and route, the initial UI state, shortest reproduction path, expectation, actual behavior, evidence locator, user impact, confidence, and a narrow recommendation. It separates the visual fact from the likely implementation cause.
ID: RUI-003
Category: OBSCURED
Severity: high
Viewport: 390 × 844 CSS px
Start: /tickets/SQ-104 with the details panel open
Observed: the sticky notice covers the entire focused “Back to queue” control
Evidence: mobile-390-ticket-sq-104-tab-07.png
Impact: a sighted keyboard user cannot see which action Enter will activate
Recommendation: reserve space for the sticky region or provide a dismissal;
verify the focused rectangle after the fix
Confidence: observed“Fix the z-index” would be weaker. The real solution might be spacing, a non-sticky mobile treatment, or a dismissible notice.
Do not turn an audit into a conformance claim
The W3C reflow criterion has a precise scope and exceptions. Some content—such as data tables, diagrams, maps, video, and interfaces whose meaning depends on two dimensions—may need an internal horizontal strategy. The rest of the page should not overflow accidentally.
The Skill can map an observed behavior to a relevant success criterion, but it does not declare the whole page compliant. A complete accessibility evaluation may require assistive technologies, multiple browsers, user settings, domain expertise, and human judgment beyond this review.
What is inside the download
SKILL.md— the viewport, two-pass, keyboard, findings, and verdict workflow.references/review-protocol.md— detailed per-viewport checks plus table, zoom, and sticky-content cases.references/report-contract.md— a compact finding schema.scripts/collect-responsive-evidence.mjs— an optional Playwright first-pass collector.agents/openai.yamland MIT license.
The separate Responsive UI Review Checklist is useful for teams that do not install Skills. It retains the same evidence ceiling and fits into an ordinary release ticket.
Read the verification label correctly
The Skill passes structural validation. The collector was syntax-checked and used on a localhost fixture with a deliberate narrow-width overflow at 390 pixels and clean wider layouts. The manual protocol was applied to the seeded sticky-content state.
No screen reader, browser farm, real account, localization matrix, production traffic, or exhaustive accessibility audit was used. The package is labeled Structure Checked, and the automated output remains a first pass.
For a broader safe-browser test harness, use How to Test an AI Browser Agent Safely. If the job is a one-off page check rather than a cross-viewport audit, the Read-Only Browser QA Skill has the smaller scope.
Bottom line: responsive review is not about collecting more screenshots. Freeze a meaningful matrix, measure the rendered page, use the keyboard, compare what changed, and write findings that preserve the difference between observed behavior and guessed cause.
