Website user acceptance testing (UAT) checks whether the site lets its intended users complete the agreed tasks. It is the acceptance round before release: reviewers use realistic scenarios, compare the result with a defined expectation, and record what passes or fails. Use this checklist as a starting point, then adapt it to the journeys your site actually supports.
What website UAT should answer
A homepage can look correct while the inquiry form sends nothing, the confirmation page gives the wrong next step, or a mobile menu hides the service your customer needs. Test complete journeys with business stakeholders and representative users. Unit tests and technical QA support the process, but they do not decide whether the delivered experience meets the agreed business need.
- Identify the release candidate, test environment, test accounts, and approved content.
- Write the core journeys and expected outcomes before testing begins.
- Choose supported browser and device combinations from your audience and requirements. Record the combinations you actually test.
- Name who can accept the release and who owns each failed test.
- Use synthetic data and a test payment environment where applicable. Keep real customer information out of reports.
Write acceptance criteria that produce a clear result
‘The contact form works’ leaves too much interpretation. ‘A visitor enters valid details, submits once, sees the agreed confirmation, and the test inquiry reaches the intended destination’ describes a result that a reviewer can verify. Include error and recovery paths as separate cases.
| Case | Action | Expected result |
|---|---|---|
| FORM-01 | Submit valid synthetic contact details | One inquiry reaches the test destination and the approved confirmation appears |
| FORM-02 | Submit with a required field empty | An understandable error identifies the field; valid entries remain available |
| NAV-01 | Find a service from the mobile menu | The menu opens, the correct page loads, and the primary next step is usable |
| RECOVERY-01 | Use a deliberately invalid page URL | The error page gives a working route back to the site |
Download the editable website UAT checklist (.csv)
The download contains starting cases and blank fields for environment, actual result, status, owner, and evidence. Add your own acceptance criteria before using it to approve a release. It is a review aid, not a guarantee of completeness.
The website user acceptance testing checklist
| Area | What to test |
|---|---|
| Navigation and discovery | Find the main pages, open and close menus, follow breadcrumbs, and verify internal links and search if present. |
| Content and next steps | Check approved wording, offer details, downloadable files, contact details, and the destination of primary calls to action. |
| Forms and validation | Test success, missing fields, invalid values, clear errors, repeat clicks, and the actual delivery of submissions. |
| Accounts and permissions | If applicable: sign in, sign out, reset access, and verify the journeys allowed for each test role. |
| Mobile and responsive layout | Test supported widths, orientation changes, menus, input controls, and overlays covering important actions. |
| Keyboard and basic accessibility | Navigate core tasks by keyboard, check visible focus, meaningful labels, and controls you can reach and operate. |
| Privacy and consent behavior | Test journeys before and after each consent choice; confirm the behavior matches your approved requirements. |
| Failure and recovery | Test empty states, failed submissions, unavailable content, and error pages. Check that the user has a sensible next action. |
| Integrations and notifications | Confirm test submissions reach the intended destination and any agreed confirmation or notification arrives. |
| Release verification | Repeat critical journeys on the intended release and record any known issues and the release decision. |
Basic keyboard checks can find important barriers, but UAT is not a complete accessibility audit. The W3C Easy Checks guide describes preliminary checks and their limits; use specialist evaluation when your acceptance requirements call for it.
W3C: Easy Checks for a first accessibility review
For performance, use agreed targets and representative conditions. A page that responds well on your development machine may behave differently on a mobile connection. Record the device, connection, and tool used instead of treating one lab score as proof of every user's experience.
Report a failed test so the team can repeat it
Record the case ID, build, browser, starting conditions, actions, expected result, actual result, and evidence. A screenshot suits a static layout problem; a short recording suits a sequence. Keep the original failed result when retesting so the history shows what changed.
When the failure is tied to the page, Annot8 can collect a pinned comment with page and browser context. Set up a separate staging environment and send reviewers a review link. The Free plan supports three distinct guest reviewers; paid plans add unlimited reviewers, screen recording, and tracker integrations.
Write a reproducible report with the website bug report template
Make a release decision from the evidence
Agree release criteria before the acceptance round. For a small inquiry site, that might mean every critical journey passes, required content is approved, and every remaining issue has an owner and an explicit decision from the approver. Your criteria should reflect the site's purpose and obligations rather than a generic severity label.
Retest corrected failures and the nearby journey they could affect. Do not count an untested case as a pass. At sign-off, record the release version, tested scope, unsupported or untested combinations, accepted known issues, and the approver. After release, repeat a small set of critical checks on production and monitor the actual outcomes.
