WCAG 2.1 AA for Government Software: What Compliance Actually Requires

If you're procuring or building software for a public body, "must meet WCAG 2.1 AA" is probably already sitting in your requirements. It's in the contract, it's in the policy, and yet most teams couldn't tell you what it actually demands, only that failing it is a problem. So they treat it as a checkbox, hand it to a vendor, and find out at audit time that a checkbox isn't what they bought.

Here's the practical version: what the standard is, what it actually requires day to day, and why the timing of when you address it changes the cost dramatically.

What WCAG 2.1 AA actually is

WCAG, the Web Content Accessibility Guidelines, is the international standard for making digital content usable by people with disabilities. It's organized into three conformance levels: A (the minimum), AA (the level almost every public body is held to), and AAA (an aspirational ceiling that's impractical to meet universally).

AA is the real-world bar. It's the level referenced by accessibility legislation across Canada and internationally, and it's what shows up in public-sector procurement. The guidelines are built on four principles, easy to remember as POUR:

• Perceivable. People must be able to perceive the content (text alternatives for images, captions, sufficient colour contrast).
• Operable. People must be able to operate the interface (full keyboard access, no traps, enough time to complete tasks).
• Understandable. Content and operation must be understandable (predictable navigation, clear labels, helpful error messages).
• Robust. Content must work with assistive technologies like screen readers, now and as they evolve.

Where teams actually fail

Audits rarely fail on exotic edge cases. They fail on the same handful of basics, over and over:

• Colour contrast. Light grey text on a white background looks clean in a mockup and fails AA instantly. This is the single most common failure, and it's entirely preventable.
• Keyboard access. Every interactive element (links, buttons, form fields, menus, custom widgets) must be reachable and operable with a keyboard alone, with a visible focus indicator. Anything that only works with a mouse fails.
• Form labels and errors. Inputs need programmatic labels a screen reader can announce, and error messages need to be tied to the field and stated in plain language ("Enter a valid email address"), not just a red border.
• Images and media. Meaningful images need text alternatives; video needs captions. Decorative images need to be marked as decorative so screen readers skip them.
• Structure. Proper headings, landmarks, and reading order so someone navigating by screen reader can move through the page the way a sighted user moves through it visually.

None of these are hard to build in. All of them are expensive to retrofit, because by the time you're retrofitting, the failures are woven through every screen.

Why "we'll add accessibility later" is the costly path

This is the part teams get wrong. Accessibility is not a layer you paint on at the end. It's a property of how the thing is built: the markup, the colour system, the component behaviour, the focus management. Bolt it on afterward and you're not adding a feature, you're reworking the foundation.

Build it in from the first line and the marginal cost is close to zero. The colour palette is chosen to pass contrast from the start. Components are keyboard-operable because that's how they were written. Forms announce themselves because the labels were never optional. Done this way, AA isn't a phase. It's just how the software works.

That's the approach we take: WCAG 2.1 AA as the default, not an add-on or a change order. You can read more about how we build accessible software, and if you're a public body, how we work with the public sector more broadly.

Automated checks are necessary but not sufficient

Automated tools, the kind that scan a page and produce a report, are genuinely useful. They'll catch missing alt text, contrast failures, and missing labels fast. Use them; run them in your build pipeline.

But they catch only part of the picture. Automated tools typically surface somewhere around a third to half of real WCAG issues. The rest (does the keyboard focus order make sense, does the screen-reader experience actually convey what's on screen, can someone complete the task without a mouse) requires a human testing with the actual assistive technology. A vendor who claims AA conformance on the strength of a clean automated scan alone hasn't finished the job.

What to ask for in writing

If you're procuring, put these in the statement of work, not in a hopeful email:

• The target standard, named explicitly: WCAG 2.1 AA.
• How conformance will be verified. Automated scanning plus manual keyboard and screen-reader testing.
• An accessibility statement describing the conformance level and how users report issues (often required for public bodies anyway).
• Bilingual support (English/French) if your jurisdiction requires it, and note that bilingual content has its own accessibility implications, like correct language attributes so screen readers pronounce each language properly.

If a vendor treats any of these as an upsell, you've learned what their definition of "accessible" really is.

The bottom line

WCAG 2.1 AA isn't mysterious and it isn't optional for public-sector software. It's a known standard, the failures are predictable, and the cost is dominated almost entirely by when you address it. Build it in from the start and it's nearly free. Retrofit it under audit pressure and it's a project of its own.

We build to AA as standard, verify with both automated and manual testing, and deliver bilingual where it's required. If accessibility is a hard requirement for your project, send us the requirement and we'll write back with exactly how we'd meet it. Where the obligation applies to a system you already run, an application condition assessment will tell you how far from AA it currently sits before you commit to remediating it.