Responsive and device testing

A responsive layout is built to rearrange itself as the screen changes. That rearranging is where defects hide: a menu that cannot be closed on a small phone, a table that pushes the page sideways, a sticky banner that covers the button visitors need, or a form field that disappears behind the keyboard. Responsive testing looks for those defects at the widths and on the devices your visitors use.

Devices and widths

We combine real devices with a sweep across widths. Real devices catch touch behaviour, keyboards and browser chrome; the sweep catches the in-between sizes no single device shows.

• Real phones. At least one current iPhone with Safari and one Android phone with Chrome, plus any device your analytics shows as common for your audience.
• Tablets upright and turned sideways, where your traffic includes them.
• Laptops and wide monitors, including very wide screens where content can stretch too far or float in empty space.
• A width sweep from 320 CSS pixels upwards. 320 pixels is the width that WCAG 2.2 uses for its reflow criterion, so it doubles as an accessibility check.

What we check

• Layout at each breakpoint. Nothing overlaps, nothing is cut off, and the page never scrolls sideways at normal zoom.
• Navigation. The mobile menu opens and closes, can be used with touch and keyboard, and does not trap the page behind it.
• Touch targets. Buttons and links are large enough to tap without hitting their neighbours. WCAG 2.2 added a minimum target size criterion at level AA, and we measure against it.
• Forms on mobile. The right keyboard appears for each field (numbers for phone numbers, email layout for addresses), labels stay visible while typing, and the field in use is not hidden by the keyboard.
• Text zoom. Pages remain readable and usable with text enlarged to 200 percent, and with browser zoom applied.
• Orientation. Rotating a phone does not lose content, reset a form, or lock the page into one orientation without a reason.
• Images and media. Pictures are sharp without being oversized, videos fit their containers, and maps and embeds can be scrolled past without trapping the page.
• Fixed and sticky elements. Cookie banners, chat widgets and sticky headers do not cover content or controls, especially on short screens.

How a session runs

After scoping, we list the templates and key pages to test, because a site built from templates repeats its patterns. Testing a product page template once at every width is more useful than testing forty product pages at one width. We then work through the device list, recording each defect with a screenshot from the affected device and the exact width and orientation. Retesting follows the fixes, as quoted.

Layout defects we look for

These are the layout problems our responsive checks look for deliberately:

This list is a starting point, not a limit. Each site has its own components, and those get their own checks in the plan.

Testing with real content

Responsive defects can depend on content. A heading that fits on one line in English placeholder text can wrap to four lines with the real wording, and a product name with no spaces can push a card wider than the screen. That is why we test once real content is in place, and why the report notes which content triggered each defect. If your site is edited regularly, the same note helps editors avoid the problem in future.

What you receive

• A device and width matrix showing exactly what was tested.
• A defect list with device screenshots, widths and orientation recorded for each item.
• Notes on touch target sizes and reflow at 320 pixels, which also feed any accessibility work.
• Retest results, as quoted.

What this service does not cover

We test the devices and widths in the agreed matrix. Other devices may show issues that ours do not, and the report states the matrix plainly so nobody assumes wider coverage. We do not redesign layouts or write CSS fixes; we describe the defect and the conditions that cause it, and your developer chooses the fix.

When to book responsive testing

• Before launch, ideally once the real content is in place, because long headings and real product names break layouts that placeholder text never troubled.
• After adding a new component, such as a mega menu, a comparison table or a booking widget.
• When your analytics shows mobile visitors leaving a page much faster than desktop visitors and nobody knows why.

Questions about device testing