On this page
- 01Key takeaways
- 02What are acceptance criteria?
- 03Why is 'fully responsive' not enough?
- 04Which ten criteria should you include?
- 05Which devices and pages should be named?
- 06How should testing and sign-off work?
- 07What are the limits and trade-offs?
- 08What does this look like in practice?
- 09Next step
- 10Sources and further reading
- 11Frequently asked questions
Key takeaways
Mobile acceptance criteria for a website are the specific, testable conditions the finished site must meet on phones before you accept it and pay the final invoice. 'Mobile-friendly' and 'fully responsive' are not criteria. They cannot be tested, so they cannot be enforced. Ten plain statements in the contract turn a hope into a deliverable.
- A criterion must be testable: a number, a named device or a yes or no.
- Cover five areas: readability, touch, speed, action and content parity.
- Name the devices and the pages the tests will be run on.
- Agree who tests, when, and what happens if a criterion fails.
Want acceptance criteria drafted for your website project? Message us on WhatsApp.
Chat on WhatsApp →What are acceptance criteria?
Acceptance criteria are the conditions a piece of work must satisfy to be accepted by the client. In a website project they define what 'finished' means. For mobile, they describe how the site must behave on phones in terms both sides can check on the day, without argument.
They protect both parties. The client gets a site that works for most of its visitors. The agency gets a clear target and a defence against 'it does not feel right' feedback after launch. Global Bridge Labs (GBL) writes them into proposals for that reason, and we recommend asking any supplier to do the same.
Why is 'fully responsive' not enough?
Because it describes a technique, not an outcome. A site can be fully responsive and still have 12px text, a menu that cannot be closed and a contact button at the bottom of a twenty-screen page. The agency has delivered what was written. You have a site that loses mobile enquiries.
The cure is to write what a visitor must be able to do, and the measurable properties that make it possible. Each of the criteria below can be verified in minutes with a phone, a browser and free tools.
Which ten criteria should you include?
These ten cover the five areas of the GBL Mobile Readiness Scorecard: Read, Tap, Speed, Act and Parity. Adapt the numbers to your project, but keep every line testable.
- Body text is at least 16px on mobile, with contrast of at least 4.5 to 1.
- No page scrolls sideways at a width of 320 CSS pixels.
- All buttons, links and form fields have a touch area of at least 44 to 48px, with spacing between them.
- Pinch zoom is enabled and the layout works with text enlarged to 200%.
- Named key templates pass the Core Web Vitals lab thresholds in PageSpeed Insights on mobile: LCP within 2.5 seconds and CLS under 0.1.
- Every phone number is a tap-to-call link, and the main action is reachable on every page without opening the menu.
- Forms use correct input types and autocomplete, and can be submitted on iPhone and Android.
- No promotional pop-up appears on arrival on mobile.
- Mobile pages contain the same text, links and structured data as desktop.
- All of the above are verified on a named list of real devices.
Which devices and pages should be named?
Name them explicitly. 'Tested on mobile' could mean one phone. List the devices, the browsers and the pages or templates each test applies to. For most UK small business sites, a set of two iPhones, two Android phones and a laptop is sufficient.
- Devices: a recent iPhone, a smaller or older iPhone, a mid-range Android, a Samsung phone.
- Browsers: Safari, Chrome and Samsung Internet on those devices.
- Templates: home, service, contact, blog post, landing page and any checkout or booking flow.
- Conditions: tested on mobile data as well as Wi-Fi.
Want a device and template matrix prepared for your project? Message us on WhatsApp.
Chat on WhatsApp →How should testing and sign-off work?
Agree the process before work starts. The agency tests against the criteria and shares the results. You then test the same criteria yourself on the staging site, on your own phones. Failures are logged, fixed and re-tested. Final payment follows acceptance, not launch.
Include a short snagging period after launch, commonly two to four weeks, during which defects against the criteria are fixed at no charge. Real traffic finds things staging does not, and you want that covered in writing.
- Agency provides a completed test sheet for each criterion and device.
- Client tests on staging before launch and records pass or fail.
- Failures are fixed and re-tested before acceptance.
- Final payment is tied to acceptance.
- A snagging period covers defects found after launch.
What are the limits and trade-offs?
Criteria cover what can be measured. They do not guarantee the site persuades anyone. A page can pass all ten and still have a weak headline. Keep judgement in the process: review the designs on a phone, and ask whether a stranger would understand and act.
Be reasonable about what the agency controls. Speed depends partly on your hosting, your images and third-party scripts you insist on. If you require a chat widget and three tracking tools, the speed criterion should be tested with and without them, or adjusted. Criteria that cannot be met through no fault of the supplier lead to disputes, not better websites.
What does this look like in practice?
A pattern we see in disputes after launch: the contract says the site will be 'modern, responsive and optimised for all devices'. The client is unhappy with the mobile version. The agency points out, correctly, that the site is responsive. There is nothing in writing to settle it, and the relationship sours over a few days of unbudgeted work.
A page of criteria would have cost nothing and prevented the argument. Where they exist, sign-off becomes a checklist exercise: twelve passes, two fails, fixed by Friday. Both sides know where they stand.
Next step
If you are about to sign a website contract, ask for the mobile acceptance criteria to be added as a schedule. A supplier who is confident in their work will agree readily.
Message us on WhatsApp and we will send a one-page set of mobile acceptance criteria you can adapt.
Chat on WhatsApp →Sources and further reading
- Understanding Core Web Vitals and Google search results · Google Search Central
- Accessible tap targets · web.dev (Google)
- Web Content Accessibility Guidelines (WCAG) 2.2 · W3C
- Designing for different browsers and devices · GOV.UK Service Manual
Frequently asked questions
What are acceptance criteria for a website?
They are the specific, testable conditions a finished website must meet before the client accepts it. For mobile they cover things such as minimum text size, tap target size, loading speed on phones, working forms and the devices the site was tested on.
What mobile requirements should be in a website contract?
Include testable statements on readability, touch targets, speed, ease of contact and content parity, plus a named list of devices and templates to be tested. Add the sign-off process, a snagging period after launch and the link between acceptance and final payment.
Is 'fully responsive' a good enough requirement?
No. It describes how the layout adapts, not whether the site is usable on a phone. A site can be responsive and still be hard to read, tap or enquire from. Replace it with measurable criteria that describe what a mobile visitor must be able to do.
Who should test the website before launch?
Both parties. The agency should test against the agreed criteria and share the results, and the client should repeat the tests on the staging site using their own phones. Independent testing by the client is what makes acceptance meaningful.
Written by
Global Bridge Labs (GBL) is a UK–Sri Lanka partner for social media, websites and BPO. Everything here comes from client delivery, not theory.
