Axively

WCAG 2.2 AA

WCAG audit for modern websites

A WCAG audit checks whether people can perceive, understand, navigate and operate your website. For most commercial web projects the practical target is WCAG 2.2 Level AA: the level referenced by many laws, procurement rules and accessibility policies.

Axively tests public pages with axe-core rule sets for WCAG 2.1/2.2 A and AA, explains the impact of each violation, and produces developer-friendly fix suggestions.

Audit checklist

  • Confirm every interactive control has an accessible name.
  • Check heading structure, landmarks and semantic HTML.
  • Verify keyboard access and visible focus indicators.
  • Find contrast failures for text and UI components.
  • Check form labels, errors and instructions.
  • Review images, icons and SVGs for useful alternatives.
  • Re-test fixed templates and high-value pages.

Why WCAG 2.2 AA is the practical target

WCAG is organised into success criteria at levels A, AA and AAA. Level A covers the most basic barriers; Level AA adds requirements that are widely expected for public and commercial websites. WCAG 2.2 keeps the familiar WCAG 2.1 criteria and adds newer requirements such as focus appearance and target size.

For EU web content, EN 301 549 references WCAG criteria. That makes a WCAG audit a practical foundation for EAA readiness, accessibility statements and procurement questionnaires.

Common WCAG failures that hurt conversions

Accessibility problems are not only legal risk; they are conversion problems. Missing labels make forms harder to complete. Low contrast hides prices and calls to action. Keyboard traps block people using assistive technology and power users. Unclear error messages make checkout feel broken.

The fastest wins usually come from the design system: accessible buttons, form fields, modal dialogs, navigation and alert components. Fixing those patterns improves every page that uses them.

  • Buttons and links without descriptive names
  • Form inputs with missing labels or inaccessible errors
  • Modal dialogs that do not manage focus
  • Color contrast failures on CTAs and disabled states
  • Icons that are announced as meaningless file names

A realistic remediation workflow

Start with critical and serious violations on revenue pages. Then fix reusable templates. After each sprint, run a verification scan so the team can see whether the same rule still appears. Store the before/after evidence with release notes; it becomes useful when customers ask for accessibility documentation.

FAQ

Does WCAG 2.2 replace WCAG 2.1?

WCAG 2.2 builds on WCAG 2.1. A WCAG 2.2 AA audit still checks the earlier A/AA criteria and adds the new 2.2 requirements.

Can axe-core find every WCAG problem?

No automated engine can find every WCAG issue. Automated testing is excellent for many code-detectable failures; content quality, task logic and some multimedia requirements need human review.

Should developers or legal teams own WCAG fixes?

Developers fix the code, but product, design and legal should agree on scope, statement wording and risk priorities. Accessibility is a product quality process, not a one-person checklist.