WCAG Accessibility Audit: 9 High-Impact Checks for WCAG 2.2 Conformance

1. What Is a WCAG Accessibility Audit? Standards and Conformance Levels

At its core, a WCAG Accessibility Audit measures software conformance across four foundational principles: Perceivable, Operable, Understandable, and Robust (POUR). The World Wide Web Consortium establishes three distinct conformance tiers: Level A (minimum baseline), Level AA (the global legal and commercial standard), and Level AAA (specialized enhanced accessibility).

Understanding the WCAG Level AA audit checklist ensures that every WCAG Accessibility Audit tests Level A and Level AA criteria across responsive breakpoints, touch screens, and desktop viewports. Level AA serves as the official benchmark referenced by the United States Department of Justice, federal courts in ADA Title III litigation, the Canadian Accessible Canada Act, and the European Union EN 301 549 procurement framework.

2. What Changes in WCAG 2.2? The 9 New Success Criteria Evaluated in an Audit

When teams commission a modern WCAG Accessibility Audit, they must ensure testers evaluate the new WCAG 2.2 success criteria published by the W3C. WCAG 2.2 expands coverage for three vital user groups: individuals with cognitive and learning disabilities, users with low vision, and people with motor and mobility impairments navigating touch interfaces.

In a WCAG 2.2 audit, deprecation of Criterion 4.1.1 means your WCAG Accessibility Audit shifts attention toward actual accessibility tree interaction rather than trivial HTML syntax nuances. As documented in our guide to what an accessibility audit tests, evaluating dynamic components requires testing real user workflows rather than relying on automated parsers.

3. Checks 1 to 3: Focus Appearance, Target Size, and Accessible Authentication

The first three checks of a WCAG Accessibility Audit target direct physical interaction and authentication hurdles that commonly block assistive technology users:

Check 1: Focus Appearance (Criterion 2.4.11 – Level AA)

Focus indicators must be clearly noticeable. The indicator area must have a contrast ratio of at least 3:1 between the focused and unfocused states, and measure at least a 2-pixel perimeter thickness.

Check 2: Target Size Minimum (Criterion 2.5.8 – Level AA)

Code inspection during a WCAG Accessibility Audit checks Criterion 2.5.8 Target Size Minimum (24×24 CSS pixels) for all interactive touch targets. If a target is smaller, spacing around it must ensure that a 24-pixel diameter circle does not intersect adjacent targets.

/* Compliant target size styling verified in a WCAG Accessibility Audit */
.mobile-icon-button {
  min-width: 24px;
  min-height: 24px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  padding: 8px; /* Increases effective clickable touch bounding box */
}

Check 3: Accessible Authentication Minimum (Criterion 3.3.8 – Level AA)

Evaluating Criterion 3.3.8 (Accessible Authentication) in a WCAG Accessibility Audit confirms that cognitive function tests like memorizing passwords, solving math puzzles, or decoding distorted CAPTCHAs are not required unless an alternative method (such as password manager paste, WebAuthn passkeys, or email magic links) is provided.

4. Checks 4 to 6: Focus Not Obscured, Dragging Movements, and Consistent Help

The second cluster verified during a WCAG Accessibility Audit inspects layout persistence and alternative gestures:

Check 4: Focus Not Obscured Minimum (Criterion 2.4.11 – Level AA)

During a WCAG Accessibility Audit, auditors test Criterion 2.4.11 and 2.4.12 (Focus Not Obscured) to confirm that sticky headers, cookie consent banners, floating action buttons, and modal overlays do not completely hide focused elements as users tab through the page.

Remediating sticky positioning identified during a WCAG Accessibility Audit ensures modal drawers do not conceal active elements by implementing CSS scroll-margin-top or dynamic keyboard focus boundaries.

Check 5: Dragging Movements (Criterion 2.5.7 – Level AA)

Any functionality that relies on dragging motions (such as reordering kanban cards, sliders, or drag-and-drop file uploaders) must offer an equivalent single-pointer alternative like up/down buttons or direct click-to-move options.

Check 6: Consistent Help (Criterion 3.2.6 – Level A)

If help mechanisms like contact forms, live chat buttons, or FAQ links appear across multiple pages, they must appear in the same relative order and location across all templates.

5. Checks 7 to 9: Redundant Entry and Cognitive Assistance

The final new checks in a WCAG Accessibility Audit focus on cognitive ergonomics and checkout usability:

Check 7: Redundant Entry (Criterion 3.3.7 – Level A)

Under Criterion 3.3.7 (Redundant Entry), a WCAG Accessibility Audit tests whether multi-step checkouts auto-populate previously entered data or allow users to select from stored addresses rather than forcing them to re-enter billing details already provided in earlier steps.

Check 8: Accessible Authentication Enhanced (Criterion 3.3.9 – Level AAA)

Eliminates all cognitive tests for authentication, even object recognition or user-supplied picture matching, ensuring complete zero-barrier access.

Check 9: Focus Not Obscured Enhanced (Criterion 2.4.12 – Level AAA)

Ensures that absolutely zero portion of any focused element is obscured by content or sticky interface components.

6. Manual Testing Mechanics: Real Screen Readers and Assistive Hardware

Executing manual WCAG compliance verification represents the decisive technical phase of a WCAG Accessibility Audit. Code linters can verify that an ARIA attribute exists, but only a human auditor can verify whether the announced name, role, and value accurately represent the visual UI.

Within a professional WCAG Accessibility Audit, testers verify screen reader output across NVDA, JAWS, and VoiceOver, validating that interactive state changes (such as expanding accordions, modal disclosures, and toast notifications) are communicated in real time.

7. Automated Scanners vs. Human WCAG Accessibility Audit Inspection

Relying strictly on automated linters creates false confidence that an authoritative WCAG Accessibility Audit quickly dismantles. Scanners like axe, WAVE, and Lighthouse evaluate purely programmatic conditions, missing over 60% of WCAG success criteria.

Consulting our comprehensive WCAG 2.2 testing guide explains why a WCAG Accessibility Audit requires human verification to evaluate alt text context, keyboard logic, and meaningful heading structure.

The following evaluation matrix demonstrates why automated tools capture only partial criteria compared to a complete WCAG Accessibility Audit performed by IAAP certified accessibility specialists.

8. Enterprise Conformance Reporting and Remediation Roadmaps

The final deliverable of a certified WCAG Accessibility Audit is a formal VPAT 2.5 Accessibility Conformance Report (ACR). This report documents conformance for every WCAG 2.2 criterion as Supports, Partially Supports, Does Not Support, or Not Applicable.

Publishing a completed WCAG Accessibility Audit provides legal counsel with verified documentation to moot ADA Title III lawsuits, satisfy Department of Justice consent decrees, and win enterprise corporate software bids.

Organizations building durable digital accessibility programs should schedule a WCAG Accessibility Audit annually to maintain continuous conformance across modern CI/CD software deployments.