U.S. Accessibility Testing for Small Websites: WCAG 2.2 Without False Compliance Claims

WCAG 2.2 provides testable success criteria, but no automated scan can prove a site is accessible. A small team that tests keyboard focus, headings, labels, errors, contrast, zoom, captions, motion and screen-reader output against representative tasks will find more real barriers than any tool alone. This plan keeps you honest about what a scan did not do and how to document what you will fix.

Define the journeys before you test

• Checkout, contact, account creation/login, search, and any form that collects money or sensitive data.
• For each journey, write the expected task and the success condition a user with a disability would experience.

What to test manually — every release of core flows

• Keyboard only: Tab, Shift+Tab, Enter, Space, Esc and arrow keys reach every interactive element; visible focus is always present; no trap.
• Headings and semantics: One H1 per page, headings in logical order, landmarks, and lists/tables that screen readers announce correctly.
• Labels and errors: Every input has a programmatic label, required fields and error messages are announced, and form re-entry preserves data where feasible.
• Contrast and zoom: Text contrast is sufficient and the layout remains usable at 200% zoom and on reflow without horizontal scrolling for text.
• Captions and motion: Videos have captions, audio has a transcript where required, and motion can be paused where the criterion applies.
• Screen reader: At least one screen reader + browser combination appropriate to your audience reads content in a meaningful sequence.

What a scan can and cannot do

A scan finds a subset of issues such as missing alternative text, empty headings, duplicate IDs, and some contrast failures. It cannot judge whether alternative text is accurate, whether heading hierarchy is meaningful, or whether a task can be completed. Use a scan as a first pass, then do manual testing.

How to record failures so they get fixed

For each failure capture: page/URL, component, user impact ("keyboard user cannot reach checkout"), WCAG criterion, steps to reproduce, severity, owner, and next review date. Publish an accessibility statement with a real contact and a way for users to report barriers. Avoid "100% compliant" language unless a qualified process supports it — over-claiming creates legal exposure.

Third-party and document risk

Widgets, chat tools, cookie banners, embedded maps, and PDFs often break otherwise accessible pages. Test embedded content in the composed page, not the vendor's demo. Provide an accessible alternative while a complex component is being repaired.

Planning and cost

Fix structural issues first: semantics, focus order, names, and error recovery. These improvements unblock the most users for the least effort. Then address contrast, reflow, captions, and motion. Budget for retesting with real users or an accessibility specialist and document known limitations.

Caveats that matter

WCAG conformance levels and legal duties are not identical. U.S. obligations can arise under multiple statutes and regulations (ADA, Section 508 where it applies, state laws), and standards evolve. Consult counsel for jurisdiction-specific duties.

Official source

W3C — WCAG 2.2. Verify success criteria and understanding documents on the live recommendation.

Frequently asked question

Q: Can an overlay make a site compliant? No. Overlays that inject scripts do not fix underlying barriers, can interfere with assistive technology, and must not replace testing, fixes, and documented retesting.