How to accept a website against WCAG 2.2 AA before launch

Begin with a decision someone can actually make

“The website should be accessible” is a goal, but it does not tell a business owner what to inspect before launch. A useful acceptance plan states the target, scope, sample, methods, evidence and decision owner. For example: “Before release, evaluate the approved site and its inquiry journey against WCAG 2.2 Level AA, record each applicable finding by page and criterion, retest fixes on the release candidate, and have the named owner review unresolved barriers.” Level AA includes the Level A success criteria as well as Level AA; it is not a small list of visual checks.

W3C’s WCAG Evaluation Methodology (WCAG-EM) provides a fuller structure: define the evaluation scope, explore the product, select a representative sample, evaluate it and report findings. Its 2026 revision applies beyond websites, but the same steps help a small website team avoid a vague “accessibility passed” sign-off. An acceptance plan supports evaluation. It does not, by itself, establish conformance or confer certification.

Inventory pages, shared templates and complete processes

List every public page type, not just the homepage: service detail, article, listing, contact, legal page and error state may use different structures. Add the shared header, footer, navigation, consent controls, search, pop-ups and embedded components. Include downloads, video, interactive graphics and third-party widgets that visitors need to use. For each type, choose at least one representative instance and include unusual variations, such as a long title, an image-heavy article or a form with an error. Define the evaluation boundary clearly. Within that scope, do not carve a component out of an included page because another supplier built it; WCAG conformance applies to full pages and complete processes.

Follow complete processes. If someone starts an inquiry, encounters validation, submits it and receives a confirmation or failure message, each state belongs in the review. A consent panel can block the page before any other task begins. A downloadable guide can be a promised part of a visitor journey. WCAG-EM 2.0 supplements the structured sample with randomly selected views equal to at least ten percent of the structured sample, unless no new views remain, and includes every view in each selected complete process. Sampling makes evaluation manageable, but a result for selected pages alone does not establish that every page across a larger website conforms.

Copy this website accessibility acceptance matrix

Create one row per meaningful page, component, state or process step. The column prompts below can be copied into a spreadsheet. Keep a stable row ID so findings and retests point to the same obligation. Use “not applicable” only with a reason, and do not mark an untested row as passed. Link detailed findings to the relevant WCAG success criteria; these prompts do not replace the full WCAG 2.2 A and AA criteria.

• Row ID and scope: page URL or template, component, content format, representative state, complete-process step and reason for choosing the sample.
• User task and expected behavior: what the visitor must do or understand; how it works without depending on color, pointer use or an unannounced visual change.
• Evaluation target: WCAG 2.2 Level A and AA; record applicable success-criterion numbers and any agreed extra usability checks separately.
• Test method and environment: keyboard, manual inspection, screen reader or automated tool; browser, assistive-technology combination, viewport and zoom where used.
• Test record: evaluator, release/build ID and date, observed pass, fail, not tested or not applicable with reason.
• Privacy-safe evidence ID: a link to concise reproduction steps, redacted screenshot or recording and evaluator notes; keep visitor and participant data out.
• Issue and retest: severity, repair owner, fix build, retest evaluator and date, retest result and remaining impact.
• Acceptance decision: who reviewed the row, which unresolved findings remain, and the dated release decision or action.

Combine tools, manual review and user evidence

Run an automated checker across the representative pages and states it can reach. It can quickly flag some missing labels, structural problems and contrast candidates. Record the tool, configuration and build so the result can be repeated. W3C’s tool-selection guidance is explicit that evaluation tools cannot determine accessibility on their own; human judgement is needed, and automated findings can be misleading. A clean scan is a useful signal, never the acceptance result.

Manually work through the site with only a keyboard: reach navigation, skip repeated blocks, open and close panels, select consent options, complete forms and find the confirmation. Check visible focus and whether fixed headers or overlays obscure it. At enlarged text and a narrow viewport, check reading order, reflow and whether controls or content are lost. Inspect heading order, link purpose, image alternatives, form instructions, errors, non-text contrast and content that moves or updates. Include screen-reader testing with a named browser and assistive-technology combination for priority journeys, performed by someone who understands the tools. These are representative checks, not a substitute for evaluating all applicable criteria.

Invite people with disabilities to try priority tasks where possible and record what their experience reveals. W3C recommends involving users during evaluation, while distinguishing this from a technical conformance assessment. A participant may find unclear language or a tiring interaction that a criteria checklist misses. Protect participant privacy and record task-level findings rather than publishing personal details or recordings unnecessarily.

Treat content and outside components as release work

The final words and media matter. Replace placeholders before review, then check whether page titles identify the page, headings describe sections, links make sense in context, meaningful images have useful alternatives and videos have the required accessible alternatives. A content editor can break an otherwise sound template by pasting an image of text or using a vague “click here” link. If authors will keep publishing after launch, give them a short content check and identify who will review new page types.

For a map, booking widget, chat control, consent manager or payment step supplied by another company, record which task it serves, who can fix a barrier and what usable alternative exists if it fails. Check the actual version embedded in the release candidate. WCAG 2.2 discusses third-party content in its conformance section; supplier ownership does not justify silently declaring the whole visitor path complete. When the product changes, assess the effect on the site’s acceptance record.

Hypothetical example: a six-page service website

Imagine a hypothetical six-page advisory website with a shared navigation, three service pages, an article template, a contact form, a consent dialog and a downloadable guide. The team samples the homepage, one service page with an illustrated motion module, one long article and the entire contact journey: empty form, invalid email, corrected form and confirmation. It also tests the consent choices, mobile menu, motion controls and download because they are part of real visitor paths. This is a planning example, not a Kinetivy client result.

In the sample matrix, row W-04 covers the contact error state. A keyboard tester submits an empty required field, sees a red outline but receives no text identifying the problem. The evaluator records the page, build, steps, expected outcome, actual outcome and applicable WCAG criterion; the owner links a fix. On the next release candidate, an independent tester repeats the same steps, confirms the error is identified in text and can be found with the screen reader used for this test, and attaches the retest result. Until that retest, W-04 remains open. The example shows what evidence should contain; it does not claim that one test proves the whole website conforms.

Make the release decision, then keep the record useful

Set the acceptance rule before results arrive: who can stop release, which barriers block essential tasks, who owns each fix, and what evidence is required for retest. A critical inquiry or navigation barrier should not be renamed “low priority” to meet a launch date. If a finding remains, record the affected users and tasks, the reason for any temporary decision, a reachable alternative, an owner and a repair date. Do not call the site WCAG-conformant while known applicable failures remain unresolved.

The sign-off pack should include the exact site/build reviewed, scope boundaries, page and process sample, evaluator expertise and methods, matrix, issue log, retest evidence, and the dated decision of the business owner. Keep it with the website’s maintenance and handover records. Recheck affected templates and flows after content, design or supplier changes. If your team is still defining audience, pages and inquiry journeys, start with the small-business website brief; if the main open question is general product acceptance rather than website accessibility, use the separate web-app acceptance guide.