Responsive Testing

Why it matters

A layout that works only at the widths in the design fails real people: a pay button hidden under a sticky footer, a menu that will not open in landscape, a price cut in half. When the user cannot finish the task, that is a functional failure, not a cosmetic one.

WCAG 2.2, the W3C accessibility standard, makes part of this testable: reflow at 320 CSS pixels (success criterion 1.4.10), text that resizes to 200% (1.4.4) and no lock to one orientation (1.3.4).

Viewports and breakpoints: choosing the widths

The viewport is the area the page is laid out in, in CSS pixels. Mobile browsers size it from <meta name="viewport" content="width=device-width, initial-scale=1">; without that tag they lay the page out at a desktop-like width and shrink it. A breakpoint is a width, sometimes a height, where a media query (CSS rules that apply only while a condition such as min-width: 600px is true) switches the layout; between breakpoints a fluid layout stretches and shrinks with the viewport.

Each breakpoint is the boundary between two layouts, so test the last width of one layout and the first width of the next: a media query that is one pixel off fails only at those two widths. The lesson on boundary value analysis explains the technique in full. Take the breakpoints from the design system or from the CSS itself (search it for @media; the CSS Formatter makes a minified stylesheet readable), not from a list of popular phones, because breakpoints are where the layout changes.

• The smallest supported width, usually 320 CSS pixels.
• Both sides of each breakpoint: 599 and 600 for min-width: 600px, but 600 and 601 for max-width: 600px.
• A slow drag through each range: fluid layouts also break between breakpoints, mostly near the narrow end.
• A very wide screen, where content stops at its maximum width, and short heights such as a phone in landscape.

Try it: Boundary Value Generator Try it: CSS Formatter

Orientation, zoom and reflow

Rotating a phone swaps the viewport's width and height: 360 CSS pixels wide in portrait can become 740 in landscape and cross a breakpoint mid-task. WCAG criterion 1.3.4 requires that content is not restricted to one orientation unless a specific one is essential.

Browser zoom on a computer enlarges each CSS pixel, so the viewport narrows: a 1280-pixel window is 640 CSS pixels wide at 200% and 320 at 400%, and fires the same media queries as a small screen. Criterion 1.4.4 requires text to resize to 200% without loss of content or function; 1.4.10 requires content at 320 CSS pixels to work without two-way scrolling, except parts such as data tables and maps. Pinch zoom on a phone only magnifies, without a new layout, so it does not test reflow.

• Rotate mid-task: typed text, filters, scroll position and open dialogs must survive.
• Enlarge only the text with the browser's font-size setting to expose fixed-height boxes that clip their labels.
• Report user-scalable=no, or a maximum-scale below 2 such as maximum-scale=1, in the viewport tag: they try to stop people enlarging the page, which fails 1.4.4.

Worked example: a test plan for a product list

A shop's product list shows one column and a menu button below 600 CSS pixels, two columns from 600, four columns and a full menu bar from 1024, and content at most 1200 wide. The CSS is mobile-first (@media (min-width: 600px), @media (min-width: 1024px)), so 600 and 1024 start the new layouts.

The tester sweeps the plan below in the device toolbar, then repeats the add-to-basket flow on a real Android phone and iPhone. Two defects turn up: from 600 to 680 pixels the "Add to basket" label is cut off, and rotating the phone clears the selected filters; the report for the second follows the plan.

• 320 × 640: minimum and reflow width; one column, no sideways scrolling.
• 599 and 600, 1023 and 1024, plus a slow drag through each range.
• 1920 × 1080: content stops at 1200 pixels, centred.
• 360 × 740 rotated to 740 × 360 while filtering: two columns, filters and scroll position kept.
• A 1280-pixel window at 200% and 400%: two columns, then one, with every function reachable.

Title:    Product list: selected filters are cleared after rotating the phone
Where:    /products, build 3.8.0 on staging
Device:   real Android phone, Chrome; also in the device toolbar, 360 x 740 to 740 x 360
Steps:    1. Open the product list in portrait (viewport 360 x 740)
          2. Select the filters "Size 42" and "Colour: black"
          3. Rotate the phone to landscape (viewport 740 x 360)
Expected: 2-column layout, both filters still selected, list still filtered
Actual:   2-column layout, filters cleared, full unfiltered list shown
Notes:    Also happens when a desktop window is resized across 600 px, so it
          follows the breakpoint, not the device. Nothing is lost while the
          width stays on one side of 600.

Try it: Test Scenario Generator

What the device toolbar can and cannot tell you

The device toolbar is the right tool for that sweep: type exact sizes or drag through a range, rotate, and in Chrome show the media queries as bars above the page. A device preset also sends that phone's user agent, which you can read in the User-Agent Parser. It is still a desktop browser imitating a phone, so confirm layout-critical flows on real devices; it does not reproduce:

• The phone's engine: an iPhone preset in Chrome does not render with Safari's WebKit.
• Mobile browser bars that hide and reappear: 100vh is the height with them hidden, so full-height panels can lose their bottom edge.
• The on-screen keyboard, which can hide the focused field or a fixed submit button.
• A finger's imprecision: small or crowded targets that fail WCAG 2.5.8 (24 × 24 CSS pixels or enough spacing) feel fine with a mouse.
• The phone's text-size settings and its real performance: CPU and network throttling only approximate it. The toolbar's own zoom only scales the preview, not the CSS viewport.

Try it: User-Agent Parser

Typical responsive defects

• Horizontal scrolling: a fixed width, a long unbroken word or URL, a wide table or an image without a maximum width.
• Covered or unreachable content: a sticky header or footer over a field or button, or a dialog taller than a short viewport that cannot scroll.
• Missing functions: an action hidden with display: none on mobile with no other route, or a menu that will not open or scroll in landscape.
• Clipped text and lost state: labels cut off by longer translations or enlarged text; input or filters reset after a rotation, often because the page swaps components at a breakpoint.
• Query gaps and overlaps: max-width: 767px with min-width: 768px matches neither rule at fractional widths such as 767.5 (some high-density screens and zoom levels); max-width: 768px with min-width: 768px applies both at 768.
• Stretched, cropped or blurry images, and in right-to-left pages a mobile menu that slides in from the wrong side.

Try it: Lorem Ipsum Generator Try it: Multilingual Test Data Generator

Frequently asked questions

References

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)The informative explanation of each WCAG 2.2 guideline and success criterion: intent, who benefits, examples and techniques (not normative).
• Responsive web design — MDNMDN Web Docs (Mozilla)Responsive design in practice: flexible layouts with flexbox and grid, media queries and the viewport meta tag, so one page works across screen sizes.
• Responsive web design basicsGoogle (web.dev)The basics of responsive design: set the viewport, size content to fit it, and use media queries with breakpoints chosen by the content rather than by device.