Editorial scope: This is a practical review workflow, not a certification or legal opinion. Accessibility obligations depend on the organization, service, users and jurisdiction. WCAG conformance also does not guarantee that every person can use every experience.
Use the current standard and define the target
The Web Content Accessibility Guidelines organize testable success criteria under four principles: content and interfaces should be perceivable, operable, understandable and robust. W3C recommends using the latest WCAG 2 version. WCAG 2.2 adds nine success criteria to WCAG 2.1 and removes the obsolete parsing criterion; content that conforms to 2.2 also conforms to 2.1 and 2.0.
Level AA is a collection of Level A and AA success criteria, not a percentage score. Before testing, define the target standard, conformance level, website version, supported browsers and assistive technologies, pages and user flows in scope, and any third-party content. A statement about conformance is meaningful only when its scope is clear.
Step 1: Build a representative sample
List the site's templates and essential tasks. Include the home page, navigation, search, article, contact form, authentication if present, error states, legal pages and any checkout or booking flow. Add pages with tables, video, documents, custom controls, dynamic updates and third-party embeds.
Sampling helps organize an evaluation, but defects on an untested page still affect users. W3C's WCAG Evaluation Methodology provides a structured approach for defining scope, exploring the target, selecting a sample, auditing it and reporting findings.
Step 2: Inspect structure and accessible names
Begin with the document rather than the visual design. Check that each page has a useful title, one descriptive primary heading, logical heading levels, correctly marked lists and landmarks that match the page regions. Use native HTML elements whenever they provide the required behavior.
- Every form control needs a programmatically associated label or another valid accessible name.
- Buttons should perform actions and links should navigate. Avoid clickable generic containers that lose keyboard and semantic behavior.
- Images that convey information need concise alternatives. Decorative images should be ignored by assistive technology.
- Status and error messages that appear dynamically must be exposed without forcing a user to hunt for them.
- The page language and any meaningful language changes should be identified in markup.
Step 3: Complete the full keyboard path
Put the mouse aside and use Tab, Shift+Tab, Enter, Space, arrow keys and Escape where the component pattern requires them. Confirm that every interactive element can be reached and operated, the focus order follows the intended task, and focus is always visible.
Open every menu, modal and disclosure. A modal should move focus appropriately, keep interaction within the active dialog when required, close predictably, and return focus to a sensible control. Check for keyboard traps. WCAG 2.2 adds the Focus Not Obscured (Minimum) criterion at Level AA, so sticky headers, cookie banners and floating widgets must not completely hide the focused component.
Step 4: Test zoom, reflow, contrast and non-text cues
Review text contrast using the specific WCAG criterion and exceptions that apply. Normal text generally requires a contrast ratio of at least 4.5:1, while qualifying large text generally requires 3:1. User-interface components and meaningful graphical objects have their own non-text contrast requirement.
Then test browser zoom and a narrow viewport. Content should reflow without forcing two-dimensional scrolling except where it is essential, such as a complex data table or image. Increase text spacing and verify that labels, instructions and controls remain readable and usable. Do not communicate an error or state through color alone; include text, an icon with a name, or another programmatic cue.
Step 5: Review forms, errors and authentication
Complete each form with missing, invalid and valid data. Instructions must appear before they are needed, required fields must be identifiable, and errors should describe the problem and point to the affected field. Preserve entered data after an error whenever possible.
For important submissions, review confirmation, correction and reversal safeguards where the applicable criteria require them. WCAG 2.2's accessible-authentication criteria also require teams to examine whether a cognitive-function test, such as remembering or transcribing a password, is imposed without an allowed alternative or assistance mechanism.
Step 6: Test media, motion and timing
For prerecorded media, determine which captions, transcripts or audio descriptions are required by the relevant criteria. Check that controls are keyboard operable and named. Content that flashes can create serious harm and requires specific review.
Pause or stop automatically moving content when required. Respect reduced-motion preferences for non-essential animation, and do not set a short session timeout without warning and a supported way to extend it where the standard requires one.
Step 7: Combine tools with human evaluation
Automated tools efficiently detect some missing names, invalid relationships and contrast failures. They cannot decide whether alternative text communicates the right meaning, whether focus order makes sense, whether instructions are understandable or whether a task works well with assistive technology. W3C states that no evaluation tool alone can determine whether a site meets accessibility standards.
Use automation as one layer. Add manual code inspection, keyboard-only testing, screen-reader checks and testing with representative users when possible. Involving people with disabilities can reveal usability barriers that a conformance checklist or individual evaluator may miss.
Step 8: Report reproducible findings
For each issue, record the page, component, steps to reproduce, expected result, actual result, affected success criterion, severity, evidence and suggested owner. Capture browser and assistive-technology versions. Distinguish confirmed failures from observations that need specialist review.
After remediation, retest the exact steps and run a short regression pass across other templates that reuse the component. Publish an accessibility statement only when its claims accurately reflect the evaluated scope and current status, including known limitations and a working feedback route.
Practical completion checklist
- The standard, level, scope, sample and test environment are documented.
- Semantics, names, headings, landmarks and page language are reviewed.
- Essential flows work with a keyboard and visible, unobscured focus.
- Contrast, zoom, reflow, text spacing and color-independent meaning are checked.
- Forms, errors, dynamic status messages, media, motion and timing are tested.
- Automated results are supplemented by knowledgeable human evaluation.
- Findings are reproducible, assigned, retested and tracked over time.