An accessibility review checks whether people with different vision, hearing, mobility, speech, and cognitive needs can perceive content and complete important tasks. It is more useful than a single score because it combines a defined standard, representative user journeys, automated checks, manual inspection, and evidence that fixes work.
Define the review before testing
Choose the site version, pages, components, browsers, assistive technologies, and conformance target. The W3C WCAG 2.2 quick reference organizes success criteria under perceivable, operable, understandable, and robust principles and links each criterion to implementation and testing guidance. Record the level being reviewed and do not describe a partial sample as certification of the entire site.
Build a representative sample: home page, navigation, article or service page, form, search, account flow, media, error state, and any unique interactive widget. Add the highest-value tasks, such as finding contact information, submitting a request, making a purchase, or recovering from an input error. Include mobile and zoomed layouts where they materially change the interface.
Combine automated and manual checks
Use an automated checker to find detectable issues such as missing names, some contrast failures, duplicate identifiers, and invalid relationships. Then review headings, landmarks, link purpose, alternative text, form instructions, focus order, visible focus, keyboard operation, error recovery, captions, reflow, zoom, and status announcements manually.
The U.S. Department of Justice web accessibility guidance lists barriers including poor contrast, color-only information, missing image alternatives, absent captions, inaccessible forms, and mouse-only navigation. It also cautions that a clean automated report does not prove a site is accessible and recommends pairing automated tools with manual checks. This is practical evaluation guidance, not a substitute for legal advice about a particular organization.
Record findings so they can be fixed
For every issue, capture the page, component, steps to reproduce, expected behavior, observed behavior, affected success criterion, user impact, evidence, and severity. Separate tool warnings from reproduced failures. A useful severity model considers whether an issue blocks a task, how many pages share the component, and whether a workaround is realistic.
Fix shared templates and components before individual occurrences. After a change, repeat the original steps with the same viewport and input method, then test nearby states for regressions. Do not close a finding because code changed; close it when the affected interaction has been observed working.
Make review continuous
Add accessibility checks to design review, content publishing, component testing, and release verification. Recheck after navigation changes, new forms, media, authentication updates, third-party widgets, or design-system revisions. Provide an accessible way for visitors to report a problem and route that report to an accountable owner.
The review is complete for its stated scope when every sampled task has a recorded result, confirmed failures have owners and priorities, fixes have been retested, and untested areas are named. Keep the report precise: a sampled review can improve confidence, but it does not prove that every page, assistive technology, or legal obligation has been covered.
Sources
- How to Meet WCAG 2.2: Quick Reference — World Wide Web Consortium Web Accessibility Initiative
- Guidance on Web Accessibility and the ADA — U.S. Department of Justice, March 18, 2022