Responsive Design Testing Checklist

Test responsive design by starting with the narrowest supported layout, widening the viewport until the content needs a layout change, and checking each transition for content integrity, usability, keyboard order, zoom, and accessibility. Use the checklist below at every meaningful layout change, then repeat it in the browsers and devices your project supports.

1. Establish the test range and breakpoints

Confirm the supported range. Record the minimum and maximum viewport widths and heights your product intends to support. Include portrait and landscape where relevant.
Start narrow and widen. Increase the viewport until line length, spacing, navigation, or a component arrangement needs to change. Place a breakpoint where the content needs it rather than copying a named-device breakpoint list.
Record actual breakpoint conditions. Note the width and any height, orientation, or aspect-ratio conditions that affect the layout. If behavior depends on input, consider pointer and hover capabilities too. A large screen is not necessarily mouse-driven, and a small one is not necessarily touch-driven.
Probe each boundary. Check immediately below and above every breakpoint, as well as at the supported minimum and maximum. A layout can fail in the small interval around a transition even when the usual device presets look fine.
Choose browsers and devices from your support policy. There is no universal browser/device matrix that fits every product. Include representative real browsers and devices for the audiences and support commitments your team has chosen.

Breakpoint worksheet

Layout or condition	Test points	What to verify
Minimum supported width	Minimum width and one nearby width	No clipped content, unusable controls, or forced horizontal scrolling
Each width breakpoint	Just below, at, and just above	Expected component change; no overlap, jump, or missing content
Maximum supported width	Maximum width and one nearby width	Readable line lengths, sensible spacing, and stable alignment
Orientation or aspect-ratio rule	Both sides of the condition	Content and controls remain available after rotation or resize
Input-dependent behavior	Relevant pointer, hover, keyboard, and touch modes	Actions work without relying on hover or a particular pointer

2. Verify viewport setup

Check the page’s viewport metadata in the rendered page. A wide virtual viewport can prevent narrow-screen media queries from running as intended on mobile browsers. MDN explains this behavior in its guidance on the viewport meta tag.

<meta name="viewport" content="width=device-width, initial-scale=1">

Keep user zoom available. Do not disable scaling with restrictive viewport settings. Verify that the narrow layout is being evaluated at the device width, rather than only looking small because the browser scaled down a wider layout.

3. Check layout and content integrity

Look for horizontal scrolling, content wider than the viewport, clipped text, overlapping elements, and unexpected blank space.
Check images, video, maps, code blocks, tables, and embedded content at narrow and wide widths. Confirm they fit, scroll within an intentional container, or have another usable presentation.
Confirm navigation, headings, forms, cards, dialogs, and primary actions remain present and usable at each layout.
Check that long words, user-generated content, translated strings, and validation messages do not break containers.
Inspect sticky headers, fixed footers, menus, and dialogs. Verify they do not cover focused controls or the content a user needs to act on.
Resize continuously as well as testing fixed points. Watch for transitions that flicker, jump, or leave a component temporarily unusable.

4. Test text, zoom, and reflow

Responsive layouts must work when users enlarge text or zoom the page. Test at ordinary size and under magnification, then check that text, controls, and important content remain readable and functional. Narrower effective viewports can expose the same issues as a physically narrow screen.

Increase text size using browser or operating-system settings where available. Confirm labels and instructions are not clipped or overlapped.
Zoom the page and inspect whether controls remain reachable and dialogs fit the visible area.
Check that content does not require avoidable two-dimensional scrolling to read or operate.
Use relative text units where user text-size preferences should affect the content.
Confirm browser zoom remains enabled; do not solve layout problems by preventing users from scaling.

See W3C’s WCAG guidance on reflow when evaluating content at a narrow effective viewport.

5. Check keyboard and interaction at every distinct layout

Visual inspection alone will not reveal every responsive failure. At each meaningful layout, navigate the page with a keyboard and verify that focus order still matches the reading and task order. CSS visual reordering can diverge from document and focus order.

Tab through links, buttons, fields, menus, and dialogs. Confirm focus is visible and moves in a sensible sequence.
Compare the visual order with reading and focus order, especially where columns or cards reorder.
Open and close menus and dialogs with the supported keyboard interactions. Ensure focus does not disappear behind a sticky element or outside a modal when it should remain inside.
Check hover, focus, and touch states. An action available only on hover is not available to many touch users.
Make sure status and meaning are not conveyed by color alone. Add text, shape, or another visible cue where needed.
Rotate the device or change orientation while a form, menu, or dialog is open. Check that the current task remains possible.

6. Review accessibility details

Touch targets: Measure applicable controls and their spacing at narrow layouts. WCAG 2.1 Success Criterion 2.5.5 is a Level AAA criterion: its target-size requirement is 44 by 44 CSS pixels and it includes exceptions, such as inline text links. Do not describe this as a universal WCAG AA threshold. Read the W3C explanation of Target Size.
Contrast: Check text, icons, focus indicators, and control boundaries in each visual state, including responsive variants.
Labels: Confirm every form control has an understandable label that remains visible or programmatically available when layout changes.
Orientation: Ensure content is usable in supported orientations unless a specific orientation is essential.
Pointer and touch: Check that controls do not require a precise gesture or hover-only input when an alternative interaction is appropriate.

If you make a WCAG conformance claim, responsive presentations count: each automatically presented variation must conform or have a conforming alternate version. Consider the full scope of the conformance claim, including pages in a complete process where relevant. See W3C’s WCAG conformance guidance.

7. Repeat checks in your project’s browser and device coverage

Viewport emulation helps you repeat width and layout checks quickly. Real browsers and devices are needed for behaviors affected by browser engines, operating systems, touch input, text sizing, and device characteristics. Choose coverage from your support policy rather than assuming a standard universal list.

For each representative browser/device combination, repeat the checks that matter to the page: breakpoint boundaries, navigation, forms, menus, keyboard order, zoom/text resizing, orientation, and any pointer- or touch-specific interactions. Record the browser, OS/device, viewport, input mode, and reproduction steps with each issue so another person can reproduce it.

8. Capture screenshots to review and compare layouts

Save screenshots at the minimum supported width, around each breakpoint, and at the maximum supported width. Full-page captures help review long pages; focused captures help compare a component. Screenshots make visual differences easier to discuss, but they do not replace keyboard, touch, zoom, or screen-reader checks.

For a local browser workflow, use your browser’s responsive design mode to set the viewport and capture the result with its screenshot feature. Record the viewport dimensions with each capture so comparisons are repeatable. If you automate captures, use the same URL, viewport, device scale, wait condition, and page state for each run.

Screenshot comparison checklist

Capture just below and above each breakpoint, not only at a popular device preset.
Keep viewport and page state consistent between before-and-after captures.
Wait for critical content and images to render; lazy-loaded content may need scrolling or a full-page capture workflow.
Compare content presence, wrapping, spacing, overlap, and control visibility, not just pixel-level differences.
Investigate dynamic content, animation, fonts, and timestamps before treating every pixel difference as a regression.

Or skip the browser setup

Use ScreenshotNeo to capture a page with one GET request. The request supports screenshot output such as PNG, JPEG, or WebP, and PDF. See the ScreenshotNeo API documentation for parameters and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server gives AI agents screenshot, page-info, and PDF-capture tools. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

9. Troubleshooting responsive test failures

Symptom	Likely cause	What to check or fix
Mobile layout looks like a scaled desktop page	Viewport metadata is missing or does not use the device width	Inspect the viewport meta tag and verify the browser is using the device width.
Horizontal scrolling appears only at one width	A child element has a fixed or minimum width, an unbroken string, or an oversized embed	Inspect the overflowing element at that exact width; allow wrapping, constrain media, or give wide data an intentional scroll region.
Text or controls overlap after zoom	Fixed heights, absolute positioning, or text sizing that cannot accommodate enlargement	Allow containers to grow, preserve zoom, and retest with larger text and a narrower effective viewport.
Keyboard focus order feels wrong after columns reorder	Visual order differs from document order	Align the content and DOM order with the intended reading sequence, or choose a layout that preserves it.
Menu works with a mouse but not on touch or keyboard	Interaction depends on hover or pointer-specific behavior	Provide equivalent click/tap and keyboard operation, with visible focus and state.
Capture does not show the final page state	Fonts, images, asynchronous content, or animation have not settled	Use a repeatable wait condition, disable or account for animation, and verify the page state before comparing.
Screenshot differs between runs	Dynamic content, rotating assets, timestamps, viewport, or device scale changed	Keep capture settings and state consistent; isolate dynamic regions before interpreting the difference.

10. Keep the process repeatable

For each page or component, keep a compact record of supported width range, actual breakpoints, browser/device coverage, input modes, and accessibility checks. When a defect is found, include the exact viewport, orientation, zoom or text-size setting, browser/device, steps, and an annotated capture where useful. Re-run the affected boundary and the surrounding layouts after a fix.

Responsive testing has no single representative viewport. Checking the boundaries and the interaction modes that affect a component gives a more useful signal than collecting many screenshots from arbitrary device presets. Emulation is quick and repeatable; real-device checks add evidence for behaviors emulation cannot fully reproduce.

FAQ

Should every page use the same breakpoints?

Not necessarily. Breakpoints should follow where each layout’s content needs to change. Shared design-system breakpoints can be useful, but verify that they still suit the components using them.

Is 44 by 44 CSS pixels a WCAG AA requirement?

No. WCAG 2.1’s 44-by-44 CSS-pixel target-size criterion is Level AAA and has exceptions. Avoid presenting it as a universal AA requirement.

Can screenshots prove a responsive page is accessible?

No. They show visual output at a captured state. Keyboard operation, focus order, zoom, touch behavior, labels, and other accessibility checks require interaction and inspection.

How many viewport widths should I test?

Test the supported minimum and maximum, each actual breakpoint boundary, and widths where content or behavior changes. The right set depends on the layout rather than a fixed count.