Key decisions
- Pages, languages and journeys are listed.
- Critical tasks have expected outcomes.
- An enquiry was checked through its destination.
- Approved content matches the published page.
Agree what acceptance covers
Write the pages, languages, user tasks and integrations covered by this review. A website that displays well can still send an enquiry to the wrong destination. Include the starting page, action and expected outcome for each critical journey. Agree who can decide whether a requirement is met. New ideas belong in a separate change list so they do not silently become requirements for work already delivered.
Check a journey from beginning to end
Attempt an enquiry with synthetic details, follow an important download and navigate from a category to its specific service. Confirm the visible result and the receiving system where it is part of the agreed scope. MDN’s testing strategies support testing realistic situations. A successful button animation is not evidence that the enquiry reached its intended destination; check the actual endpoint of the journey.
Review content and access on real screens
Compare names, contact information and published claims with approved copy. Open translated pages and verify that the language switch leads to the same subject. Test an important path using a keyboard and inspect a narrow screen. W3C Easy Checks provides an initial accessibility review, not a complete certification. Capture the affected page, browser and steps when a problem appears so the finding can be reproduced.
Turn findings into release decisions
Give each finding an owner, evidence and a next action. An enquiry that disappears may block release; a wording preference may be a later improvement. Keep that decision explicit. Retest corrected findings rather than accepting a message saying they are fixed. Also verify the handover items you agreed, such as editing access and a short operating note. This article supplies an editorial worksheet; the final acceptance terms belong in your actual project agreement.
Try the exercise
Create three acceptance rows for a fictional service website: find the service, send an enquiry and download the brief. Add the expected end state, the observed result and the person responsible for each unresolved item.
Expected output
A review sheet that can support a release, correction or scope-change decision. The example is fictional; it does not establish acceptance conditions for an existing VITON13 order.
Your evidence checklist
Mark only what you have checked. This records your own progress, not an independent audit or a predicted result. There is no automatic saving; download the note if you want to keep it.
0 / 6 checked
Questions and answers
Is a visual approval enough to accept the website?
It can approve appearance within a defined scope, but it does not check functional journeys or handover requirements. Review the behaviours named in the project agreement and retain observations for each. The acceptance decision should say which parts were actually checked.
Should every issue block publication?
Classify the issue by its effect on an agreed requirement and the proposed release. A failed critical journey differs from a preference for another photograph. Agree the classification, owner and next action rather than treating every comment as equally urgent.
Next step
Accept a website through agreed tasks and recorded evidence, then retest the findings that affect release.
Sources and verification
- MDN — Testing strategies ↗
Checked:
- W3C WAI — Easy Checks ↗
Checked: