WCAG 2.2 AA as an acceptance criterion, not an audit

Most organisations treat accessibility as a phase. Build the product, then engage someone to test it, then receive a report of several hundred issues, then prioritise the ones visible to a procurement questionnaire.

That sequence fails three ways. The fixes are more expensive late. Automated scans catch roughly a third of real problems. And the report arrives as a list rather than as a set of decisions.

Moving WCAG 2.2 AA into the build acceptance criteria costs less and produces a better result, provided a small number of things happen.

Decide the target, precisely

"Accessible" is not a target. WCAG 2.2 AA is — 56 criteria, of which some apply and some do not.

Two scoping decisions matter early:

Does AA apply to the whole product or to specific journeys? For a lending portal, an onboarding flow and an account dashboard carry very different risk. Scoping to critical journeys is defensible and achievable; committing to everything at AA is often neither.

Which parts of the platform are exempt? Internal admin tools with a known user base can sometimes be scoped out. Documented, with a review date.

Build the things that cannot be retrofitted

Most WCAG failures come from structural choices made in the first week:

• Semantic HTML instead of divs with click handlers
• A visible focus indicator that is never removed
• Colour contrast checked in the design tokens, not per component
• Form fields with real labels, associated programmatically
• Every interaction available from the keyboard, in a logical order
• Respects for prefers-reduced-motion and prefers-color-scheme

Each of these is cheap on day one and expensive on day ninety. Each is also nearly impossible to fix in bulk later without rewriting components.

The most common preventable failure is removing focus outlines. It is usually done because the default looked untidy, and it is the single change that most often fails a WCAG criterion outright.

Automate the mechanical checks, then test by hand

Automated tooling catches missing labels, insufficient contrast, duplicate ids and unassociated form fields. It will not catch a keyboard trap, an illogical focus order, or a flow that only makes sense visually.

Run the automated check on every pull request so regressions surface immediately. Then budget for manual testing: keyboard-only walkthroughs and screen-reader passes on the critical journeys, done by someone who uses a screen reader daily rather than someone reading a checklist once.

Treat it as a purchasing requirement

For a bank or insurer, an accessible platform is frequently a legal requirement and frequently a procurement gate. Put it in the contract:

• WCAG 2.2 AA as a defined scope, not "accessible to best practice"
• An accessibility statement published with the product
• A named route for reporting a barrier, with a response commitment
• VPAT or ACR documentation as a deliverable where it is required

Requiring this of a supplier you are evaluating is easier than arguing for it later against something already built.

The realistic position

Full WCAG 2.2 AA conformance is not achievable for every internal tool within a normal budget. Trying to achieve it anyway produces an argument about whether partial conformance is acceptable.

The defensible answer is: conform fully on the journeys that affect customers, document exclusions precisely, publish what you have and what you do not, and plan the remainder. That is a stronger position than claiming full conformance and being wrong about it during an audit.