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.
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.
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:
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.
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.
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:
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.
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:
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.
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.
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.
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.
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:
This report makes it possible to reproduce the error and check the fix under the same conditions.
Divide the tasks you find by priority:
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.