WCAG 2.2 Compliance: A Practical Level AA Guide for Developers

Let me be upfront: WCAG is one of those topics that sounds intimidating until you actually sit with it. The spec is long, the language is dense, and the number of "levels" and "success criteria" can make your eyes glaze over before you've even started.

But here's the thing — for most developers building real-world apps, WCAG 2.2 Level AA comes down to a manageable set of things that you either do or don't do in your code and design. It's not magic. It's patterns.

This post is my attempt to make WCAG feel less like a bureaucratic nightmare and more like a checklist you can actually ship against.

What Even Is WCAG?

WCAG stands for Web Content Accessibility Guidelines. It's published by the W3C and defines what "accessible" means on the web. The current version is 2.2, which added a handful of new criteria on top of the already-solid 2.1 foundation.

The guidelines are organized around four principles — often called POUR:

• Perceivable: Can users perceive all the content? (alt text, captions, contrast)

• Operable: Can users operate the interface? (keyboard nav, no time traps)

• Understandable: Does the interface make sense? (labels, errors, language)

• Robust: Does it work with assistive tech? (semantic HTML, ARIA done right)

Why This Matters Right Now

This issue is not theoretical. Accessibility lawsuits have been increasing annually. The EU Accessibility Act was fully implemented in 2025. U.S. courts have long applied the ADA to websites. Government contractors already face procurement requirements.

More practically: if you're building anything for a client or shipping a product, there's a real chance someone will ask for a WCAG audit report. Being able to say "yes, we're AA compliant" is increasingly a table-stakes deliverable.

The Stuff Developers Actually Mess Up

Here's where I'll save you time. The most common failures I see in audits aren't exotic edge cases — they're patterns that show up everywhere:

1. Images without alt text

<!-- Bad -->
<img src="product-shot.jpg">

<!-- Good -->
<img src="product-shot.jpg" alt="Blue running shoe, side profile view">

<!-- Decorative image — intentionally empty alt -->
<img src="divider.svg" alt="">
```

The rule: every non-decorative image needs descriptive alt text. Decorative images need alt="" (not missing, empty) so screen readers skip them cleanly.

2. Interactive elements that aren't keyboard accessible

If you built a dropdown with a <div> and an onclick, you've got a problem. Screen readers and keyboard users can't interact with divs. Use <button> for actions, <a> for navigation, and <input> for form controls. Semantic HTML isn't just good practice — it's what makes WCAG Operable work.

<!-- Bad -->
<div onclick="openMenu()">Menu</div>

<!-- Good -->
<button onclick="openMenu()" aria-expanded="false" aria-controls="nav-menu">
  Menu
</button>

3. Color contrast failures

WCAG 2.2 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px+ or 14px+ bold). This is one of the most common failures on nice-looking designs.

Use the WebAIM Contrast Checker or install the Colour Contrast Analyser. Check your grays against white. Check your placeholders. Check disabled states — they're often excluded but they still need to pass.

4. Form inputs without visible labels

Placeholders are not labels. They disappear when the user types and are invisible to screen readers that use label associations.

<!-- Bad -->
<input type="email" placeholder="Enter your email">

<!-- Good -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="yourname@example.com">

5. Focus indicators removed with CSS

/* This breaks keyboard navigation for sighted keyboard users */
*:focus { outline: none; }

Never do this globally. If you hate the default outline, replace it — don't remove it.

6. Missing language attribute

<!-- Bad -->
<html>

<!-- Good -->
<html lang="en">

Screen readers use the lang attribute to determine which pronunciation rules to apply. Missing it makes content harder to parse for users relying on text-to-speech.

The New Stuff in WCAG 2.2

WCAG 2.2 added nine new success criteria. The ones most relevant to developers:

• 2.4.11 Focus Not Obscured (Minimum): When a focused element is visible, it can't be completely hidden behind a sticky header or floating element. You need to account for this in your sticky nav implementations.

• 2.5.7 Dragging Movements: Any functionality that requires dragging must have a single-pointer alternative. Think: drag-to-reorder lists need a fallback.

• 3.2.6 Consistent Help: If you have help/support mechanisms, they must appear in a consistent location across pages.

• 3.3.7 Redundant Entry: Don't make users re-enter information they've already provided in the same process.

These aren't hard to implement — they just require being intentional.

How to Actually Run a WCAG Audit

You can't fully automate a WCAG audit. Automated tools catch roughly 30-40% of issues. The rest requires human judgment. That said, a good audit workflow looks like:

1. Automated scan — Run axe, Lighthouse, or WAVE on your key pages. Fix everything flagged.

2. Keyboard-only testing — Unplug your mouse. Navigate your app using only Tab, Shift+Tab, Enter, Space, and arrow keys. Can you reach everything? Can you tell where focus is?

3. Screen reader testing — Use NVDA (Windows, free) or VoiceOver (macOS, built-in). Navigate a core user journey. Does it make sense?

4. Color contrast pass — Check your palette systematically, not just the obvious text.

5. Form review — Every input needs a label. Every error needs to explain what happened and how to fix it.

If you want a structured starting point for this process — what to check, in what order, and what to do with what you find — there's a detailed walkthrough at altaudit.com/wcag-compliance.

The Mindset Shift

The teams I've seen ship accessible products don't treat WCAG as a separate audit at the end of the project. They just write semantic HTML, test with keyboards, and use real labels on form inputs — as a baseline habit.

Once those patterns are muscle memory, WCAG compliance is mostly just... how you build things.

Start there. Run your first audit. Fix the easy wins. The spec gets less scary the more you work with it.

---

If this was useful, the full audit guide is at altaudit.com/wcag-compliance — it covers tooling, remediation prioritization, and what to document if you need to produce a VPAT or compliance report.