Answer in brief
Accepting a website is a few hours of list-driven checking, not an impression of the home page. Start on a phone over mobile data, follow forms through to the recipient, run the WCAG 2.2 checks yourself and send one defect list.
Website acceptance in short
Acceptance is a structured check of the finished site against what you ordered, carried out before the final payment and before you sign anything off. It takes a few hours and it runs off a written list, not off your impression of the home page.
The order matters: a phone on a weak connection first, then page content against the brief, then forms all the way to the recipient, then the WCAG 2.2 checks, then navigation, loading behaviour and the admin panel. Everything you find goes into one document.
Acceptance is not about assigning blame. Its purpose is to produce a written record of what works and what needs fixing, and to confirm that the record fits inside the revision rounds your package actually includes, rather than spilling past them.
What follows is twelve blocks of checks. Each one can be done without special tooling: you need a phone, a laptop, a browser and an hour when nobody is interrupting you with questions about something entirely different.
What to prepare before you start testing
Before the first click, gather three documents: the brief or specification, the list of pages and features that were in scope, and the emails where changes were agreed mid-project. Without them the review turns into a conversation about taste.
Ask for the exact address you are reviewing. It may be a staging domain or the live one, but it has to be the same address for you and for the developer, or you will end up arguing about two different versions of one page.
Get two devices ready: your ordinary phone and a laptop. Do not review only on the work machine with fast office internet and a wide monitor, because it shows the site under conditions your visitors may never actually have.
Open an empty table with these columns: page, what happened, what you expected, device and browser, priority. You write into it as you go, rather than trying to reconstruct the wording of a fault two days later from memory.
Start on a phone, on a slow connection
Open the site on your phone before you open it on the laptop. Layout faults that stay invisible on a wide screen become obvious on a narrow one, and you want to meet them now rather than in a message from a customer.
Turn Wi-Fi off and browse over the mobile network, ideally somewhere the signal is poor. That is where fast office internet stops hiding things: the wait before the first readable text, layout that jumps, images that arrive last.
On the phone, check three things: whether text fits without sideways scrolling, whether your thumb actually lands on buttons and links, and whether a sticky header or a consent banner covers the very thing a visitor came to the page for.
The MDN performance documentation covers perceived performance as well as raw loading speed — how responsive the interface feels. That feeling is exactly what you are testing when you open the site on a phone in the street rather than on a developer's desk.
Content check: the brief against the published page
Take the page list from the brief and walk it line by line. Every promised page has to exist, open from a direct link, and carry the block it was ordered for, rather than a placeholder paragraph of filler text left in from the build.
Read the copy for typos, outdated prices, another company's name and leftover demo data. Worth remembering here: VITON13 does not write the client's content or translations, so the copy comes from you and proofreading it stays your responsibility.
Cross-check the contact details everywhere they appear: header, footer, contact page, structured data and the message shown after a form is sent. One wrong digit in a phone number quietly costs you the calls it was meant to bring in.
Look at the images separately: correct products, no stock watermarks, orientation matching the layout. Check their alternative text as well — under WCAG 2.2 that is success criterion 1.1.1 Non-text Content, at Level A.
Forms end to end: to the recipient, not to the button
A form is accepted when the enquiry reaches the person who answers it, not when the button responds to a click. Testing as far as the button means accepting half a feature and hearing about the other half from a customer you have already lost.
Send a test enquiry with real details and follow the whole path: the thank-you screen, the email to the company inbox, the email to the customer, and the record in the CRM or spreadsheet if that was in scope. Log each step as its own line.
Then break the form on purpose: submit it empty, type letters into the phone field, use an address with no at sign, attach a file that is too large. Error messages should be text beside the field and should say what needs to change.
In WCAG 2.2 terms these are 3.3.1 Error Identification and 3.3.2 Labels or Instructions at Level A, plus 3.3.3 Error Suggestion at Level AA. A red border and the word Error, with nothing else beside it, does not satisfy them.
Accessibility: WCAG 2.2 checks you can run yourself
WCAG 2.2 is a W3C Recommendation with three conformance levels: A, AA and AAA. If your contract names no level, work to AA, and note that a substantial share of its criteria can be checked by hand, without an auditor and without paid tooling.
Text contrast under criterion 1.4.3 at Level AA is 4.5:1 for ordinary text and 3:1 for large text. Field borders, icons and interface controls fall under criterion 1.4.11 instead, where the threshold is 3:1.
Criterion 2.5.8 Target Size (Minimum) at Level AA, added in version 2.2, asks for a target area of at least 24 by 24 CSS pixels, subject to the exceptions it lists. Look at the small icons in the footer and the arrows in any gallery.
Two further additions in 2.2 belong to a form review: 3.3.7 Redundant Entry at Level A, under which information already entered in the same process should not be demanded again without reason, and 3.3.8 Accessible Authentication at Level AA if the site has a login.
Keyboard, focus and zoom
Take your hand off the mouse and move through the home page with the Tab key. You should see where focus is at all times, the order should match the visual order, and menus, modals and players should all release you again.
These are criteria 2.1.1 Keyboard and 2.1.2 No Keyboard Trap at Level A, plus 2.4.7 Focus Visible at Level AA. Version 2.2 added 2.4.11 Focus Not Obscured (Minimum) at Level AA, which is worth testing against sticky headers and cookie bars.
Test zoom: enlarge text to 200 per cent, since criterion 1.4.4 at Level AA requires content and functions to stay usable. Then narrow the browser window to around 320 CSS pixels and confirm that no horizontal scrolling has appeared.
If the interface involves dragging — reordering cards, a range slider, a file drop zone — criterion 2.5.7 at Level AA asks for a single-pointer alternative that does not require the drag, unless dragging is essential to the task itself.
Navigation, links and error states
Walk every menu item and every footer link. Each one has to lead to a page that exists on this site, not to a draft, not to the developer's own domain, and not to a page you asked to have removed several weeks ago.
Type an address you know does not exist. You should get a 404 page in the site's own design, with the menu and a route back to the home page, rather than a server message or a white screen with a technical string on it.
Check the empty states: a search with no matches, a basket with nothing in it, a catalogue filtered down to zero results. In each case a visitor should understand what has happened and what they are able to do next.
Look at the plumbing too: the browser tab title should differ per page and describe it — criterion 2.4.2 at Level A — and the language of the page should be declared, criterion 3.1.1 at the same level.
Speed and loading behaviour
Speed is judged on the same phone and the same network, not in a report produced under ideal conditions. Open the site from a cold start with no stored data and watch how long it takes for the first readable text to appear.
Watch for layout shifts. If text is already readable and then a late image or banner pushes it down the screen, that is an acceptance defect and not a quirk. Shifts like that cause mis-taps and make people lose their place in the text.
Browser developer tools include network throttling that simulates a slow connection. The MDN performance documentation makes the point that both loading and interface responsiveness are worth measuring, rather than one headline number on its own.
Do not demand a particular score in a third-party tool if no score was written into the contract. Phrase the finding as behaviour instead: on a phone over mobile data the first screen appears noticeably later than on the laptop. That can be verified.
The admin panel: can you edit without breaking anything
Log in with your own account rather than the developer's. Confirm that you hold the owner or administrator role and that you can see every section that was discussed as something you would be editing yourself after launch.
Make a real edit: change a heading on one page, add a paragraph, upload an image, save, and look at the public version. If a developer is needed for any of that, this part of the work has not been accepted yet.
Check that editing does not break the layout: a long heading should wrap rather than escape its block, and an image of an unplanned size should still fit. Paste in a very long word and a very long paragraph on purpose and look again.
Agree the boundary. Content edits are yours; template and logic changes belong to the developer. Under Ongoing Dev Support at $290/mo, the volume of that work is agreed at the start of each cycle.
Writing the defect list and fitting it into revision rounds
Send one message with one list, not ten messages across a day. Each item names the page, the device, what happened and what you expected, and carries a screenshot where possible. A note saying it looks off comes straight back as a question.
Split the list in two: things that stop the site being used, and things you would now prefer differently. The first are defects, the second are new requests, and they land differently on both the schedule and the paid revisions.
The number of rounds depends on the package and does not carry across from one to another. Launch Site at $380, with a timeline of 3-5 working days, includes 2 rounds before launch. Product Build at $880, over 2-3 weeks, includes 2 rounds per delivered feature.
Site Fix Pack at $70, in 1-2 working days, is 1 round and up to five agreed fixes, with a mobile and desktop check and a before/after list at handover. Launch Site Express at $520, in 2 working days, is 1 round after the first full build.
Sign-off and what happens after acceptance
Sign when the items on your list are closed and re-checked on the same phone you started from. The second pass takes noticeably less time than the first, because by then you already know the route through the site.
Put in writing what stays outside the work: content and translations, if those sit on your side by agreement, or native mobile apps and payment licensing, which are not part of Product Build.
Decide what happens to the site next. One-off fixes after launch fit Site Fix Pack, while priority updates, a weekly release rhythm and technical maintenance belong to Ongoing Dev Support at $290/mo, billed on a monthly cycle with 30 days notice to stop.
Then keep the checklist itself. In six months, when you are accepting the next piece of work or changing supplier, a route you have already walked saves you an evening and settles the argument about what counts as finished.
Practical checklist
- Open the site on your own phone over mobile data rather than office Wi-Fi.
- Walk the page list from the brief and mark anything missing or still a placeholder.
- Send a test enquiry and follow it to the company inbox, to the customer and to the CRM.
- Tab through the home page and confirm focus stays visible and modals release the keyboard.
- Check text contrast and target sizes against criteria 1.4.3, 1.4.11 and 2.5.8.
- Collect every finding in one prioritised table and send it as a single message.
Questions and answers
How long should website acceptance take?
Plan for a few hours of uninterrupted work rather than a quick look. The time goes on walking a written list from a phone and a laptop, sending test enquiries and recording what you find. Splitting it across two sittings is fine; sending your findings as ten separate messages is not.
Which device should I start on?
Your own phone, on mobile data rather than office Wi-Fi. A wide monitor with fast internet hides narrow-screen layout faults, late-arriving images and the wait before the first readable text appears.
How many revision rounds do the development packages include?
It depends on the package and never carries across from one to another. Site Fix Pack at $70, in 1-2 working days, includes 1 round. Launch Site at $380, in 3-5 working days, includes 2 rounds before launch. Product Build at $880, over 2-3 weeks, includes 2 rounds per delivered feature. Launch Site Express at $520, in 2 working days, includes 1 round after the first full build.
What if problems appear after I have signed off?
Small, precisely described corrections fit Site Fix Pack at $70: up to 5 agreed fixes in 1-2 working days, with a mobile and desktop check and a before/after list at handover. It does not cover new pages, redesign or migrations. For a continuing rhythm, Ongoing Dev Support at $290/mo runs on a monthly cycle with 30 days notice to stop, and the volume of work is agreed at the start of each cycle.
Do I really need the accessibility checks on a small site?
The WCAG 2.2 checks listed here need no auditor and no paid tooling: contrast, keyboard order, visible focus, target size and clear form errors. They also catch ordinary usability faults along the way, because a control too small to hit and an error message with no explanation get in everyone's way.