WCAG 2.2 Website Acceptance Checklist for Small Businesses

A useful accessibility acceptance review does more than run a scanner. It states the target—such as WCAG 2.2 Level AA—defines which pages, templates, components, states, and third-party functions are in scope, and preserves evidence for both automated checks and human evaluation.

Use this checklist when receiving a new website, approving a redesign, or evaluating a material feature release. It turns a broad “accessible” promise into a review that an owner, developer, tester, and vendor can discuss item by item.

What matters most

Write the evaluation frame before testing:

• website name, primary hostname, owner, and evaluation date;
• exact WCAG version and target conformance level;
• included and excluded domains, subdomains, applications, documents, and third-party services;
• technologies relied upon, such as HTML, CSS, JavaScript, PDF, or a media player;
• representative pages, templates, components, processes, viewport sizes, and interaction states;
• browsers, assistive technologies, automated tools, and manual methods used;
• testers, issue owner, remediation deadline, retest method, and sign-off authority.

W3C organizes WCAG under four principles: content and operation should be perceivable, operable, understandable, and robust. Acceptance evidence should trace each finding to the applicable success criterion rather than reporting only a single score.

Build a representative sample

A small-business website sample commonly needs:

• home, service, location, about, article, contact, privacy, search, and error templates;
• global header, footer, navigation, cookie or privacy controls, dialogs, accordions, sliders, and embedded media;
• forms in empty, error, success, timeout, duplicate-submission, and keyboard-only states;
• login, checkout, booking, application, quote, or other complete processes if present;
• mobile and zoomed layouts, long content, empty content, and user-generated content;
• representative PDFs, videos, maps, reviews, chat, scheduling, or payment widgets.

The sample should reflect template diversity and critical customer tasks. Testing ten copies of one service-page template provides less coverage than testing the distinct templates and processes that generate the site.

How to run the acceptance review

1. Run automated checks and preserve the limits

Use automated tools across the representative URLs and component states. Record tool name and version, ruleset, browser, URL, timestamp, raw result, triage decision, and linked issue.

Automated findings can identify many programmatic problems, but a zero-error result is not a conformance determination. Tools may miss whether alternative text is meaningful, headings describe the content, focus order matches the task, instructions are understandable, status changes are announced, or a keyboard user can complete the process.

2. Review structure and content alternatives

Check that pages have descriptive titles, a logical heading structure, semantic regions, meaningful link and button names, text alternatives for informative images, and appropriate treatment for decorative images. Verify that instructions do not depend only on color, shape, visual position, sound, or motion.

For audio, video, and documents, record which alternatives are required and which artifact was inspected. Do not infer PDF or media accessibility from the surrounding HTML page.

3. Complete every critical task with a keyboard

Starting from the address bar, navigate the complete customer path without a mouse. Confirm that focus is visible, order is logical, controls are reachable and operable, no keyboard trap occurs, content is not hidden behind sticky elements, dialogs manage focus, and skip or bypass methods work.

Repeat the test in the responsive navigation and with any consent banner, chat control, modal, date picker, or third-party widget active. Record the exact state and steps for every defect.

4. Check zoom, reflow, contrast, and spacing

Inspect representative pages at the viewport and zoom conditions required by the selected WCAG criteria. Test text resizing and reflow, orientation where relevant, non-text and text contrast, focus appearance, target size, and user-applied text spacing.

Capture the measured foreground and background colors, tool, location, state, and threshold when reporting a contrast issue. A screenshot without values or component state is weak evidence.

5. Test forms, errors, and status messages

State	Acceptance evidence
Empty submission	Required fields identified programmatically and in visible text where needed
Invalid value	Error identifies the field and problem, is perceivable, and can be reached or reviewed
Corrected value	Error state clears or updates predictably without losing entered data unnecessarily
Successful submission	Confirmation is visible and exposed to assistive technology without an unexpected context change
Time limit or expiration	User receives the required warning, extension, or documented exception
Repeated or high-impact action	Prevention, confirmation, or correction behavior is tested where the criterion applies

Use safe test data and verify the whole path, including the actual test recipient when delivery is part of the accepted function.

6. Inspect code semantics and assistive-technology behavior

Check names, roles, values, relationships, labels, descriptions, live regions, language, parsing behavior, and custom-control state. Then use relevant assistive technology for representative workflows rather than assuming correct markup always produces a usable experience.

Document the browser, assistive technology, version, settings, action, expected result, and observed result. Avoid treating one tester or one technology combination as universal coverage.

7. Maintain a criterion-level issue register

Field	Record
Finding ID	Stable identifier linked to retest history
Scope	URL, template, component, state, and viewport
Requirement	WCAG version, success criterion, and level
Reproduction	Preconditions, steps, input, and observed result
User impact	Affected task and interaction mode without guessing at all users
Evidence	Code excerpt, measurement, screenshot, video, or tool result
Ownership	Responsible party, target date, status, and release
Retest	Tester, date, method, result, and remaining limitation

Distinguish confirmed failures, potential issues needing review, best-practice improvements, and out-of-scope observations. Severity and WCAG conformance are related but not interchangeable: a Level A failure may affect one uncommon page, while a usability problem outside a specific criterion may heavily affect a core task.

What this checklist cannot prove

This checklist cannot provide legal advice or determine obligations under every jurisdiction. WCAG conformance and legal compliance are not identical questions.

It also cannot guarantee accessibility for every person, technology combination, future content update, or third-party change. A sampled evaluation supports conclusions only for its documented scope and method. Conformance claims should disclose the date, guidelines and level, scope, technologies relied upon, and known limitations.

Automated percentages should not be described as a percentage of accessibility or compliance. The scoring model of a tool is not the WCAG conformance model.

Put the accessibility checklist into practice

Attach this checklist to the statement of work before development begins. Require the same target, sample, acceptance method, issue fields, remediation ownership, and retest evidence from each vendor.

At release, keep the evaluation report, selected sample, test environment, tool exports, manual test notes, issue register, retest results, unresolved exceptions, and approval record together. W3C’s reporting template provides a useful structure for summarizing an evaluation, while WCAG-EM explains how to define scope, explore the site, select a sample, audit it, and report findings.

After acceptance, add accessibility checks to content publishing, component review, regression testing, procurement, and periodic human evaluation. The durable control is a repeatable operating practice, not a one-time badge.

Mendola.Tech can help define an accessibility target, build testable components, prepare an acceptance report, remediate confirmed barriers, and add accessibility checks to ongoing website maintenance.

Official references

• Web Content Accessibility Guidelines documentation — W3C Web Accessibility Initiative; accessed 2026-09-01. Organizes WCAG 2 resources including the standard, understanding documents, techniques, and supporting material.
• Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 2.0 — World Wide Web Consortium; accessed 2026-09-01. Defines a structured method for scoping, exploring, sampling, auditing, and reporting a website accessibility evaluation.
• Template for Accessibility Evaluation Reports — W3C Web Accessibility Initiative; accessed 2026-09-01. Provides a reporting structure for scope, methods, results, and evaluator information.