Testing your website on real devices

Testing on real devices means physically opening the live or staging site on an actual phone and working through it as a real visitor would. Tap every button, fill in the form, rotate the screen. Do not just resize a desktop browser window and call it done.

Why a minimum set of real devices, not just one phone

Testing on a single device — even the tester’s own current phone — misses genuine differences between platforms and hardware generations. A reasonable minimum for a small business build is three devices: one recent iPhone, one recent mid-range Android phone, and ideally one older or lower-cost Android device. Android’s hardware and screen-size range is genuinely broader than Apple’s more limited device line-up. Older devices reveal performance problems a brand-new phone can mask.

For a business without physical test devices, cloud services such as BrowserStack provide real, remote access to a wide range of mobile devices and browsers for structured tests. This is a reasonable substitute for buying hardware outright. It still tests through a network connection to the device, though, not the device’s own local behaviour end to end. A desktop browser’s device-simulation mode is not a substitute for either. It is useful for a rough layout check. It is not useful for the tap-target, keyboard and connection-speed checks this page actually recommends.

The real-device testing checklist to actually work through

Every tap target, tapped with a thumb, not a fingertip-precision click. Buttons, links, form fields and any icon-only controls — confirm each responds reliably and that nearby elements are not accidentally triggered instead, covered structurally on touch targets and thumb reach on a small screen.

The phone number, tapped, confirming the dialler actually opens. A malformed tel: link can silently fail to trigger the phone app — covered on phone-first design for trades and emergency services — and this is one of the highest-cost failures to miss for an emergency trade business.

Every form field, focused, with the on-screen keyboard actually open. Confirm the field being typed into, and the submit button, both remain visible and reachable while the keyboard is showing.

Scrolling a long page slowly, watching for layout shift. Confirm nothing jumps or overlaps as the browser’s own address bar expands and collapses during scroll, a failure mode covered on what actually breaks on a phone.

Rotating the device to landscape and back. Confirm the layout adapts sensibly rather than breaking or requiring a page refresh to recover.

Turning on the device’s accessibility text-size setting and confirming the layout still holds. A layout that assumes a fixed text size can overlap or cut off content when a visitor has increased their device’s default font size — a genuine, common accessibility setting, not an edge case.

Testing on a real, non-Wi-Fi mobile connection at least once, ideally the slowest available, to confirm the page load time is acceptable under real-world Australian mobile network conditions rather than only the office Wi-Fi the site was built on — covered further on mobile page speed and why it differs from desktop.

Testing with the device’s own screen reader: VoiceOver on iOS, TalkBack on Android

Beyond the visual and touch checks above, both major mobile platforms include a built-in screen reader — VoiceOver on iOS, TalkBack on Android. Turning one on and navigating the site by swipe gestures, rather than direct taps, reveals a different category of problem entirely. That includes content read in a confusing order, an interactive element with no accessible label, or a control that a screen reader announces without enough context to understand what it does. This is a meaningfully different test from checking colour contrast or tap-target size visually. It tests the experience of a real assistive-technology user directly, rather than inferring it from a static accessibility guideline.

What happens when a visitor navigates back to a partially completed form across mobile browsers

Testing should include using the device’s back button, or swiping back, midway through filling in a form, then returning forward again — to confirm whether entered data survives that round trip. Mobile browsers handle this inconsistently across platforms and page implementations. Some preserve form state through back-forward navigation, others silently clear it. A visitor who briefly checks another tab or app and returns to a form that has quietly emptied itself experiences exactly the kind of data-loss frustration covered in the forms discipline on enquiry forms that people actually finish — just triggered by navigation, not a validation error.

This is a per-deploy check, not a one-time launch task

The device checklist above is easy to treat as something done once before a site first launches, then forgotten. But a content update, a new plugin, or a platform update can reintroduce exactly the failures this page describes on a site that passed every check at launch. Build a lightweight version of this checklist into the routine for any significant update. Not the full device set every time — at minimum a quick real-device pass on the changed pages. That catches regressions while they are new, rather than months later when a customer reports a problem.

A one-page checklist for your device lab and how to view results

Check	Pass condition
Every button and link, tapped with a thumb	Responds reliably, no accidental adjacent taps
Phone number tapped	Dialler opens with the correct number pre-filled
Form fields focused with keyboard open	Field and submit button remain visible
Slow scroll on a long page	No content jump or overlap
Rotate to landscape and back	Layout adapts without breaking
Device text-size setting increased	Layout holds, no overlapping or cut-off text
Loaded on a real mobile connection, not Wi-Fi	Loads in an acceptable time under real network conditions

What to do next: responsive testing on real browsers and devices

Run this checklist before any launch or major update goes live, not after a problem is reported by a real visitor. If several of these checks fail on an existing site, web development services covers what fixing them typically involves, and whether that is a targeted fix or points to a broader rebuild is worth discussing directly with whoever built the site.