A 30-day path to WCAG 2.2 AA

“Make the site accessible” sounds like a quarter-long project that competes with everything else on the roadmap. It doesn’t have to. With a clear order of operations, most teams reach a defensible WCAG 2.2 AA position in about a month — without pausing feature work.

Week 1 — Measure the real surface

You can’t fix what you can’t see. Scan the whole site, not just the homepage, and rank every issue by how often it actually blocks a user. Resist the urge to start fixing on day one: a complete picture stops you from polishing a footer link while a checkout form is unusable.

Week 2 — Kill the high-impact failures

Spend this week on the criteria that account for most real-world harm: contrast, alt text, form labels, keyboard operability, and accessible names. These are the issues that show up in nearly every audit and nearly every lawsuit — and the ones automated fixing handles best.

Week 3 — Handle the judgment calls

What’s left needs a human in the loop: meaningful alt text for complex imagery, sensible reading order, focus management in custom components, and clear error messaging. This is where an accessibility specialist earns their keep — and where automated tooling should hand off cleanly rather than guess.

Week 4 — Verify, document, monitor

Re-scan to confirm the failures are gone, publish an accessibility statement, and export your remediation record so you can prove what changed and when. Then turn on continuous monitoring — because the real risk isn’t today’s code, it’s the regression someone ships next Tuesday.

Keep it, don’t re-earn it

Accessibility is a property of a site that keeps shipping, not a milestone you pass once. The thirty-day plan gets you to AA; continuous monitoring is what keeps you there while your team keeps building. HelpBob runs both halves — the sprint and the upkeep — from one place.