Before You Choose a Website Builder, Run These Mobile Acceptance Tests

Define tasks and a realistic test set

Pick the journeys that matter to the site: locating a service, reading a comparison, opening a menu, completing an inquiry and finding the next step. Write each task in ordinary language and describe the expected outcome. This prevents a test from becoming a collection of screenshots with no connection to visitor needs.

Use the devices and browsers you can actually access, and record the limits of that coverage. A browser’s viewport tools can expose layout faults, but they do not reproduce every real-device interaction. Combine them with a phone or tablet where possible. Do not describe a site as tested on every device when the evidence covers only a small set of environments.

Inspect navigation, content order and page structure

Open and close the menu using the controls a visitor can see. Check that its labels match their destinations, its close action remains available and the page does not become stranded behind an overlay. Move through the page with a keyboard and make sure the focus indicator remains visible.

The W3C page-structure guidance explains the role of meaningful headings and page regions in navigation. Review whether the mobile layout preserves the intended reading order and whether a reader can identify the main content. A visual rearrangement should not make the text or controls confusing when the layout changes. Treat unexpected focus or reading order as a test result requiring investigation.

Sources: 1

Check larger text, long labels and wide content

Increase the text size using the controls available in the test environment. Look for clipped headings, overlapping buttons, hidden menu items and text that disappears behind fixed elements. Use realistic long service names and messages rather than relying on short placeholder labels that make the layout unusually easy to fit.

For tables, inspect whether the content remains understandable and whether any horizontal scrolling is contained in an appropriate region. Check captions and headings so the relationship between values remains clear. Images should preserve their intended proportions and avoid covering adjacent information. An attractive empty template is insufficient evidence for a page containing the real material you intend to publish.

Exercise forms and feedback on a narrow screen

Test a valid inquiry and a deliberate input error. Check that labels remain associated with fields, the relevant error can be found and the visitor knows how to continue. Make sure an on-screen keyboard or fixed header does not hide the action needed to finish the task.

Verify the handoff after submission as well as its layout. The destination should receive the expected controlled test information, and the page should describe any remaining step accurately. Test the failure route your implementation can support, such as a clear retry instruction or alternative contact method. Do not claim delivery merely because an animation or success banner appears.

Record failures in a form that supports retesting

Use a compact log containing the page, environment, task, expected result, observed result and an image where useful. Describe the problem precisely: a menu close control is outside the visible area, for example, rather than simply saying that mobile is broken. Assign an owner and a priority based on the effect on the task.

After a correction, repeat the original test and check the neighbouring states. A shared navigation change should be checked on another page that uses the same component. Track the failures still open rather than replacing the evidence with a broad pass label. This produces a useful acceptance record without pretending that a finite test set certifies all devices or accessibility requirements.

Frequently asked questions

Sources

1. Page Structure Tutorial | Web Accessibility Initiative (WAI) | W3C