Remediation & WCAG 2.2 conformance

We fix the code, not the symptom

Every finding has a root cause in your markup, your components or your content workflow. That is where we work. No script tag, no overlay, nothing that reads your page at runtime and guesses. When we are finished, the accessibility lives in the product — which means it survives a redesign, a CMS migration, and a subpoena.

Two ways to run it

We implement

Our engineers work in your repository on a branch, in your review process, with your CI. You get pull requests with a description of the barrier, the criterion, the fix and the retest evidence. Most clients start here for the high-risk items.

Your team implements, we direct

We supply annotated specifications, reference implementations and code review, then retest every fix before it is closed. Slower to start, cheaper over time, and your developers come out of it knowing how to build accessibly.

What we typically touch

WCAG 2.2 in particular

The nine criteria added in WCAG 2.2 are the ones most sites fail today, because they were written after most design systems were built. Level A and AA additions we check and fix on every engagement:

New in WCAG 2.2 — Level A and AA criteria we remediate. (2.4.12, 2.4.13 and 3.3.9 are Level AAA and are handled on request.)

Criterion	Level	What it usually means in practice
2.4.11 Focus Not Obscured (Minimum)	AA	Sticky headers, cookie bars and chat bubbles must not hide the focused element.
2.5.7 Dragging Movements	AA	Sliders, sortable lists and map controls need a single-pointer alternative.
2.5.8 Target Size (Minimum)	AA	Interactive targets at least 24×24 px, or adequately spaced.
3.2.6 Consistent Help	A	Help and contact options appear in the same relative place on every page.
3.3.7 Redundant Entry	A	Multi-step forms must not ask for the same information twice.
3.3.8 Accessible Authentication (Minimum)	AA	No cognitive function test in login without an alternative — puzzle CAPTCHAs and “retype this code from memory” fail.

WCAG 2.2 also removed 4.1.1 Parsing, which is now obsolete. If a vendor is still billing you for “HTML validation errors” as accessibility findings, that is worth a question.

Keeping it fixed

Remediation without guardrails decays within two release cycles. Every engagement ends with the things that stop that happening: accessible component patterns folded into your design system, linting and axe checks wired into your pull-request pipeline, a written definition of done, and training for the people who will build the next feature. We would rather not be back next year for the same findings.