On a phone, visitors should be able to understand your offer, find the right section and contact your company. Checking the mobile version helps uncover obstacles along that journey: small buttons, overlapping elements, awkward navigation or a form that is difficult to complete with the keyboard open.
Start with a specific customer task. For example: open a service page, review the terms, move to the form and submit an enquiry. This lets you check both the design and how the website works in a real scenario.
Below is a checking sequence, a compact checklist and a bug report template for your developer.
1. Choose the pages and devices to check
Check the published website by opening its usual link on a phone. The editor preview is useful during development, but assess the final result where visitors actually see it.
Choose the pages customers use on their way to contacting you: the homepage, a service page, contact details and the form. If you run a store, add a product page, the cart and checkout. For a blog, check an article and the route from it to your services.
Use analytics data to choose devices and browsers commonly used by your audience. If you do not have that data yet, start with Safari on an iPhone and Chrome on an Android phone when those devices are available. Then expand the checks based on your website's visitors.
Also open the page through channels that matter to your business: search, an advertising link or an in-app browser. This can reveal differences that do not appear when you enter the address directly.
On a computer, you can additionally check different widths using device mode in Chrome DevTools. For example, start with 360, 390 and 430 CSS pixels, then gradually vary the width between them. These are sample checking points; choose sizes that suit your website and audience.
Device mode simulates mobile display on a computer. Complement it by checking the keyboard, touch interactions and specific browser behaviour on a real phone. Chrome documentation on device mode.
2. Check the initial view and navigation menu
Open the page without scrolling first. Look at whether the service, its purpose and the available next step are clear. Long headings should wrap without being cut off, and the important button should remain accessible in its chosen position.
You do not have to fit the entire offer into the first screen. Visitors should be able to start exploring it and understand where to go next.
Then check the menu:
- Open and close it several times: the controls should work and stand out against the background.
- Go to the section you need, including submenu items if there are any.
- Make sure navigation does not require hovering a mouse pointer.
- Check a long menu: its lower items should be reachable by scrolling.
- After closing the menu, check that the page can scroll again.
- If an item leads to a section on the same page, make sure the sticky header does not cover that section's heading.
On a multilingual website, check the language switcher separately. Look at where it takes you from a service page or article: visitors benefit from reaching the corresponding content in their chosen language.
3. Check buttons with ordinary taps
Go through the main actions: open the menu, choose a service, expand an answer, move to the form and tap a phone or messaging link. Check each button in the position where a customer will see it.
Watch for accidental taps on neighbouring controls. If you have to aim precisely or zoom in, review the size of the active area and the spacing between elements.
For primary buttons and icons, you can plan a touch target of at least 44 × 44 CSS pixels. This size is used in the enhanced WCAG 2.2 target size criterion at Level AAA. The criterion has exceptions, such as links within paragraphs. It concerns the active area of the control; the icon itself can be smaller. W3C criterion on target size.
Check the outcome of the action too. A “Get a quote” button should open the intended form or lead to a clear next step. If it scrolls to a form further down the page, the fields and the form's purpose should be visible after scrolling.
4. Assess readability and whether content remains available
Read several paragraphs at the phone's normal zoom level. Check body text, terms, prices, field labels and error messages: important information should remain easy to read.
Look for the following:
- Text is distinguishable from its background, including over photographs and decorative elements.
- Headings and paragraphs are separated by clear spacing.
- Long words, addresses and names do not overflow their containers.
- Reading an ordinary paragraph does not require repeated horizontal scrolling.
- When text is enlarged, the content and main actions remain available.
For longer passages, it is worth checking left alignment: on a narrow screen, this makes it easier to find the start of the next line. Assess font size together with the typeface, line spacing and contrast.
Also check how ordinary text reflows at a width of 320 CSS pixels. The WCAG Reflow criterion calls for information and functionality to be preserved without scrolling in two dimensions at that width. Content that needs a two-dimensional layout, such as tables and maps, has exceptions. A wide table can be placed in its own scrolling container. W3C explanation of content reflow.
Compare the content of the mobile and desktop versions. If the service scope, limitations or important terms disappear during adaptation, restore access to that information. Google uses the mobile version of content for indexing and recommends keeping the same primary content in both versions. Google guidance on mobile content.
5. Complete the form with the keyboard open
Start entering details on a real phone. Check that the active field stays visible and that you can move to the next one. Then try to reach the submit button, close the keyboard and continue filling in the form.
Fields should have clear labels. A placeholder inside an empty field can provide an example, but does not replace the label: it disappears as you type. W3C guidance on form instructions.
Check several scenarios:
- Enter valid details and submit the form.
- Leave a required field empty: the website should explain what needs completing.
- Enter data in an incorrect format: make sure it is clear where the error is and how to fix it.
- Correct the error and check that the other details you entered are preserved.
- Use autofill if available, and check the result.
- For an international audience, check phone numbers with the country codes you need: the input mask should not exclude customers you serve.
For phone numbers, email addresses and other fields, a developer can configure an appropriate input type and autofill. Assess whether the chosen keyboard actually makes completion easier and allows all the necessary characters.
After a successful submission, check the visitor's confirmation and the receipt of the enquiry in your system. Mark the test enquiry so your team can distinguish it from a real customer request.
6. Check pop-ups and fixed elements
Open the website with the contact widget, cookie banner, sticky header and any other elements that actually appear for visitors. Check how they work together on a narrow screen.
Pay particular attention to the form with the keyboard open. A floating messaging button or bottom bar may cover a field, error message or submit button.
The pop-up's content, controls and intended way of closing it should be accessible. After closing it, check that you can continue using the page. Repeat the check after rotating the phone.
If several elements compete for the same area of the screen, coordinate their positions and display conditions. Sometimes adjusting the spacing or hiding a secondary widget while the form is being completed is enough.
7. Check behaviour while the page loads
Open the page over a mobile network and, where available, a slower connection. Look at whether you can read the important content and use the main actions while other elements are still loading.
Check whether a button shifts as you tap it, empty blocks appear over the text, or the form's position changes after fonts or images load.
Compare the first and repeat visits. You can use a fresh private browsing session for the first visit; bear in mind that this does not guarantee the elimination of every form of caching. Separately check a scenario with the visitor's preferences already saved.
If you find a problem, record exactly when it occurs: when the page opens, after a widget appears or during submission. This will help identify the cause more precisely.
8. Use a checklist for one complete journey
Choose an important page and follow the journey from opening it to receiving an enquiry. Record the result for each row and attach evidence of any problem you find.
One journey does not cover every page and device. Repeat it for the main page types and important combinations of device, browser and language.
9. Give your developer a reproducible report
Instead of a general comment such as “the mobile layout is broken”, identify the page and the actions that trigger the error. Add the device, browser, screen orientation and a screenshot or short recording.
Illustrative bug report:
- Page: a service page with an enquiry form.
- Conditions: an Android phone, Chrome and portrait orientation; specify the model and browser version in the actual report.
- Steps: open the form, focus the phone number field, open the keyboard and scroll to the submit button.
- Actual result: a floating messaging button covers the submit button.
- Expected result: the visitor can complete and submit the form; the elements do not overlap.
- Evidence: a screen recording showing the sequence of actions.
This report makes it possible to reproduce the error and check the fix under the same conditions.
10. Prioritise issues by their effect on customer actions
Divide the tasks you find by priority:
- Prevent an action: the menu does not open, the form cannot be completed, submission is unavailable or the enquiry does not arrive.
- Make an action harder: precise aiming is needed, important terms are difficult to read or the keyboard interferes with the fields.
- Need visual refinement: awkward heading wrapping, inconsistent spacing or a minor decorative inconsistency.
After a fix, repeat the original scenario and check related elements. For example, changing the sticky header may affect where a section appears after a menu link is followed.
If you have already documented the issues, you can send them to our website and design support billed by the hour. We work with Tilda, WordPress and Webflow; we agree on the tasks and time estimate based on the platform and the website's specific requirements.
If you first need to identify which issues require attention, you can start with a website audit.
A mobile website check delivers a useful result when each issue has a specific scenario, supporting evidence and a clear criterion for the fix. Start with the customer's journey to an enquiry, then extend the checks to other pages and devices.