Keep important information on mobile too
Mobile usability covers both how content is displayed and whether visitors can use it. Check the offering, readability and functionality in the same review.
How does responsive design differ from mobile usability?
Responsive design allows the same page to adapt its presentation to the screen size. Mobile usability also needs to be tested through real tasks, such as reading conditions and submitting an enquiry. A layout that changes its number of columns shows how the page responds to width; a functional test shows whether visitors can use it. Google’s guidance on mobile websites describes responsive design as a solution using the same HTML and URL for different devices.
Which information needs to remain available on mobile?
Pricing conditions, the offering and the contact route must not disappear when the layout becomes narrower. Google uses the mobile version’s content as the basis for mobile-first indexing. Read Google’s guidance.
A compact presentation can use clear sections or expandable elements, but the content must remain accessible and understandable.
A different mobile layout must not leave out the main information. A closed tab can reveal content already available in the page. That differs from fetching the main text only after a click. Google recommends not loading the main content solely after a user action. Check both what visitors can open and what content the search engine can process.
How do you check readability on a small screen?
Read the real text in a narrow viewport and with zoom, checking that information remains understandable and is not clipped. Long headings, links, pricing conditions and language-specific word lengths need testing with actual content. Short placeholder text can hide the problem.
- Body text should be readable without following every line by scrolling sideways.
- Zoom must not make the contact route or a required field inaccessible.
- Tables and diagrams need an understandable way to be read when they require more space.
- Text within an image needs an accessible equivalent when it communicates important information.
W3C’s Reflow criterion describes presenting content at a width equivalent to 320 CSS pixels without loss of information or functionality. Exceptions exist for parts requiring a two-dimensional layout for their meaning or use. This width check is a bounded check, not certification that the entire website meets WCAG.
Test the visitor’s task
Test the entire journey from finding the right information to completing the task. Use the task the website is actually intended to support. For a service website, the check could look like this:
- Find a relevant service from the homepage.
- Read the scope and pricing conditions.
- Follow the link to the correct contact channel.
- Complete the form and review the error messages.
- Check what happens after a successful submission.
Also test keyboard use, zoom and different content lengths. Fitting the page into a screenshot is not enough.
How do you test a contact form on mobile?
Test both invalid and valid input, and check the confirmation and whether the enquiry reaches the correct recipient. Illustrative example: submit a test enquiry with a deliberate error in the email field. The error message should explain what needs correcting, and information already entered should remain available to check. Correct the error, then check both the confirmation on the page and whether the enquiry reached the intended recipient.
How do you document a mobile issue?
Record the URL, device, browser, action and actual outcome. Also state the result you expected. Examples of issues include a button hidden behind another component, body text that requires horizontal scrolling, or a form error indicated only by colour. A screenshot shows the symptom; the description makes the test reproducible.
What should be checked in the mobile menu?
If the menu is implemented as a modal dialog, focus also needs handling: keyboard focus stays within the open dialog and normally returns to its opening control when closed. This applies to that modal pattern, not to every ordinary menu. See W3C’s dialog pattern.
What should the form show before submission?
The form needs clear field labels, understandable requirements and instructions where needed. Identify required fields and explain a necessary format before a failed attempt. A placeholder disappearing when someone starts typing does not replace a visible label. W3C’s form instructions guidance explains the distinction.
An error message needs to identify the affected field and explain how to correct it. Check that the message can be understood without relying on colour alone and that a successful attempt receives a clear confirmation. W3C describes feedback after form input. Use designated test details and check receipt before treating the flow as complete.
How can a concrete test case be documented?
Describe the action, expected result and observed result separately. The following is an illustrative template to complete, not results from a performed client test:
| Part | What to record |
|---|---|
| Environment | Full URL, language, phone model, operating system, browser and date. |
| Action | Open the contact form, enter test details and attempt submission with an invalid email address. |
| Expected result | The error is explained, details can be corrected, and a valid attempt leads to confirmation and a received enquiry. |
| Actual result | Record what happened during each attempt. Add the relevant screenshot or log entry. |
| Follow-up | Responsible person, completed fix and result when the same steps are repeated. |
Assess responsiveness and stability
A page may look correct yet still respond slowly or move content as resources load. Core Web Vitals provide evidence about parts of that experience.
After optimisation, the features need to be checked again.
What should be tested on a slower connection or phone?
Check whether visitors can still understand the page’s status and use important features while content loads. Try opening the menu, starting a form and reading further down the page during loading. Record anything that temporarily disappears, moves or does not respond. Investigate the cause before removing content visitors need.
Illustrative example: a form displays a waiting indicator after submission but provides no further instructions when the network request fails. It needs a controlled route back to retrying. Check how the same flow handles a double tap so visitors understand whether the enquiry was already submitted. This is a functional test case; a fast page-load test cannot answer it on its own.
Make mobile testing part of delivery
Specify which tasks and screen sizes need to be checked, and document actual issues. Let the approved design determine the appearance, but give specific feedback when content or functionality does not fit.
Record the tasks and who approves them in the website requirements specification. This makes it possible to distinguish a failure to meet an agreed requirement from a new request.
When problems require changes to structure, content or components, they need to be included in the website project’s requirements. Read about SOVRA Digital’s web development and the checks on the agreed delivery.
Is shrinking the browser window sufficient?
No. A simulated mobile viewport needs relevant real-device testing to assess how those devices function. Chrome DevTools describes its simulation as an approximation because the code still runs on the computer. See the device mode limitations. Choose test environments based on the website’s visitors and agreed delivery.
Record which device and browser combinations were actually tested, which tasks could be completed and which issues remain. Test relevant orientation, zoom and open on-screen keyboards within forms. Approval covers these documented checks; it must not be presented as verification of every possible phone and situation.
Build a website that works on mobile
SOVRA Digital coordinates content, UX, design and development around visitor tasks. See what a website project includes and how functionality, contact paths and mobile use are checked.