How Do You Audit a Site Against WCAG 2.2? A Prioritised Checklist

## The short answer

To audit a site against WCAG 2.2, combine three layers: **automated scanning** to catch the mechanical issues, **manual keyboard and assistive-technology testing** for the things tools cannot judge, and a **targeted review of the new WCAG 2.2 criteria** that older tools may not yet check. Start by confirming WCAG 2.1 AA, then specifically verify the six new A/AA criteria in WCAG 2.2: Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7), and Accessible Authentication Minimum (3.3.8). Automated tools typically find a minority of issues, so plan for manual work.

## Step 1: Set the target

Decide your conformance target before you start. Most legal and procurement requirements aim at **WCAG 2.2 Level AA**. AAA is rarely required wholesale and is usually applied selectively. Write the target down, along with the scope - which pages, templates, and user flows are in or out. Auditing every page is impractical; audit representative templates plus your critical journeys (sign-up, login, checkout, account management, search).

## Step 2: Run automated scans

Automated tools quickly catch a class of mechanical failures:

- Missing alternative text on images.

- Insufficient colour contrast.

- Missing form labels.

- Empty buttons and links.

- Missing document language.

- Some ARIA misuse and landmark problems.

Use them on a sample of pages and across states (logged in, error states, modal open). But understand the ceiling: automated tools reliably detect only a fraction of WCAG issues. They cannot tell whether alt text is *meaningful*, whether focus order is *logical*, or whether a drag interaction has a real alternative. Treat automated results as the floor, not the finish line.

## Step 3: Manual keyboard testing

Unplug the mouse and operate the whole site with the keyboard:

- Tab through every page - is the order logical and the focus indicator always visible?

- Is any focused element fully hidden behind a sticky header or banner? (2.4.11)

- Can you reach and operate every control, including menus, modals, carousels and custom widgets? (2.1.1)

- Can you escape from modals and menus without a trap? (2.1.2)

- For every drag interaction, is there a non-drag alternative? (2.5.7)

## Step 4: Screen-reader and zoom testing

- Navigate key flows with at least one screen reader to check names, roles, states, and announcements.

- Zoom to 200% and reflow to a narrow viewport - does content remain usable without horizontal scrolling? (1.4.10, 1.4.4)

- Check that focus and error messages are announced.

## Step 5: Specifically verify the WCAG 2.2 additions

Because these criteria are newer, give them a dedicated pass rather than assuming tools covered them:

1. **Focus Not Obscured (2.4.11)** - tab with banners present; check nothing fully hidden.

2. **Dragging Movements (2.5.7)** - confirm tap/click alternatives for all drags.

3. **Target Size Minimum (2.5.8)** - measure small and crowded controls against the 24-pixel rule.

4. **Consistent Help (3.2.6)** - check help links keep the same relative order across pages.

5. **Redundant Entry (3.3.7)** - walk multi-step flows; flag anything asked twice.

6. **Accessible Authentication (3.3.8)** - confirm paste and autofill work and no puzzle is mandatory.

## Step 6: Record findings against criteria

Log each issue with the specific success criterion, the location, the impact, and a suggested fix. Tag severity by user impact - a keyboard trap on checkout outranks a cosmetic contrast issue on a footer. A criterion-linked log makes re-testing and reporting straightforward, and supports an accessibility statement if you need to publish one.

## Step 7: Fix at the right layer

Many findings repeat across pages because they live in shared components - a button without a visible focus style, an icon below 24 pixels, a header that obscures focus. Fixing the shared component resolves the issue everywhere at once. This is why we treat accessibility as a property of the design system when building enterprise-grade products at neart.ai: a single corrected primitive clears a whole class of audit findings, and a regression test on that primitive stops them returning.

## Step 8: Prevent regressions

- Add automated accessibility checks to CI for the mechanical issues.

- Add component-level tests for focus visibility and target size.

- Re-run manual checks on changed flows, not the whole site, each release.

- Keep the criterion-linked log as a living document.

## A fast triage order

If time is short, prioritise in this order: keyboard operability and focus, forms and authentication, target size and dragging, then contrast and content semantics. These map to the highest-impact barriers.

## Practical takeaway

Audit in layers: automate the mechanical checks, then do the real work by hand with keyboard, screen reader and zoom, and give the six new WCAG 2.2 A/AA criteria a dedicated pass because tools may miss them. Log every finding against its success criterion, fix recurring issues in shared components, and add component-level and CI checks so the fixes stick.