Two years ago, accessibility conversations mostly happened after launch, prompted by a complaint, an internal audit, or — worse — a legal notice. That pattern has changed faster than most product and engineering teams have adjusted to. In the RFPs we’re seeing today, from government portals to enterprise SaaS procurement, WCAG 2.2 AA conformance is showing up as a submission requirement, not a bonus point, and the products that can’t demonstrate it are being disqualified before a technical evaluation ever starts.
This shift has several drivers, and understanding each one changes what “good enough” actually means for a delivery team trying to plan around it.
Regulation Has Caught Up With Intent
Public-sector digital accessibility mandates have existed in various forms for years — Section 508 in the US, the EN 301 549 standard across the EU, equivalent frameworks in the UK, Canada, Australia and increasingly across the Gulf. What’s changed isn’t the existence of the rules; it’s the consistency of enforcement. Procurement teams that once treated an accessibility statement as a box to tick now check it against the live product, not just a design file or a written claim.
This matters because a written commitment to accessibility and a conformant product are two very different things, and the gap between them used to be invisible to a procurement evaluator without technical expertise. That’s no longer true — automated scanning tools have become good enough, and cheap enough, that a buyer’s own procurement or legal team can run a basic conformance check themselves before a contract is signed.
Enterprise Buyers Inherited the Requirement
When a government agency or large enterprise is itself accessibility-obligated, that obligation flows down through their vendor contracts whether or not the vendor’s own product is customer-facing to the public. A B2B SaaS product that fails an automated and manual accessibility review can be disqualified from a deal that has nothing to do with a public-sector end customer directly, simply because the buyer’s own compliance posture depends on every tool in their stack meeting the same bar.
This is the part that catches vendors off guard most often: the assumption that accessibility only matters for consumer-facing government services. In practice, an internal HR platform, a B2B analytics dashboard, or an admin console can all be pulled into the same requirement, because the enterprise buyer’s compliance obligation doesn’t distinguish between “public-facing” and “internal tool used by employees who may themselves have disabilities.”
Retrofitting Costs More Than Building It In
The projects that struggle with accessibility are consistently the ones where it gets treated as a post-launch checklist item: alt text added after the fact across hundreds of images, focus order patched in after QA flags it during a late-stage review, color contrast adjusted screen by screen once a scan comes back with dozens of failures.
Building semantic structure, keyboard navigation and screen-reader labeling into the component library from day one is consistently cheaper than retrofitting it across dozens or hundreds of already-shipped pages later, for a straightforward reason: a design system with accessible components by default means every new feature built on top of it inherits that accessibility automatically. A design system without that foundation means every new feature has to be individually remediated, forever, because the underlying components were never fixed.
What WCAG 2.2 AA Actually Requires
WCAG is organized around four principles — content must be Perceivable, Operable, Understandable and Robust (often abbreviated POUR) — and AA conformance sits at the level most procurement requirements and legal frameworks reference, one step above the baseline A level and one step below the more stringent AAA level that’s rarely required outside specialized contexts.
- Perceivable — text alternatives for non-text content, sufficient color contrast (4.5:1 for normal text, 3:1 for large text), content that doesn’t rely on color alone to convey meaning
- Operable — full keyboard navigability, no content that traps keyboard focus, visible focus indicators, sufficient touch target sizing
- Understandable — predictable navigation and interaction patterns, clear error identification and correction guidance on forms, consistent labeling
- Robust — valid, semantic markup that works correctly with assistive technology, not just with a mouse and a sighted user
What a Conformant Build Actually Requires
In practice, reaching and maintaining AA conformance means combining several layers of testing, because no single method catches everything on its own.
Automated scanning tools catch roughly a third of real accessibility issues — missing alt attributes, insufficient color contrast, missing form labels, invalid ARIA usage. They’re fast, cheap to run on every build, and genuinely useful as a first pass and a regression guard. But they cannot evaluate whether a keyboard user can actually complete a checkout flow, whether a screen reader announces a dynamic error message at the right moment, or whether a custom dropdown component is operable without a mouse. That requires manual testing: a tester navigating the entire interface using only a keyboard, and a tester using an actual screen reader (NVDA, JAWS, or VoiceOver) to complete the same core user journeys a sighted mouse user would complete.
For teams that need a credible external signal for procurement purposes, an IAAP-certified reviewer signing off on a conformance report carries weight that an internal self-assessment doesn’t — it’s the difference between “we believe this is accessible” and “an independent, certified expert verified this against the standard.”
The VPAT: What Buyers Are Actually Asking For
A Voluntary Product Accessibility Template (VPAT) is the standardized document format procurement teams increasingly request — a structured, criterion-by-criterion statement of how a product conforms to WCAG, Section 508, or EN 301 549, rather than a vague “we care about accessibility” paragraph on a marketing page. Producing an accurate VPAT requires the underlying testing to actually have been done; a VPAT built without real manual testing behind it is a liability, not an asset, because a mismatch between the document and the live product is exactly what a sophisticated buyer’s own technical evaluation will surface.
Building an Accessibility-Ready Procurement Checklist
- An up-to-date VPAT or equivalent conformance statement, backed by actual manual testing — not a template filled in from assumptions
- Automated scanning integrated into the CI/CD pipeline, so regressions are caught before release, not after a customer complaint
- A documented manual testing process covering keyboard navigation and screen-reader use on core user journeys, refreshed with every major feature release
- A named accessibility owner internally, even if the deep expertise is brought in externally — someone who can answer a procurement team’s follow-up questions credibly
Common Accessibility Failures We See Most Often
A handful of defects account for a disproportionate share of the failures we find in first-pass audits, and most of them are fixable at the component-library level rather than page by page.
- Custom dropdowns and modals that trap keyboard focus. A user tabs in and has no way to tab back out without a mouse, or focus silently jumps to an unrelated part of the page when the component closes.
- Color contrast that passes for body text but fails for interface elements. Placeholder text, disabled-state buttons and icon-only controls are consistently under-tested because they don’t look like “content” the way a paragraph does.
- Form errors announced visually but not to assistive technology. A red border and an error message appear on screen, but a screen reader user submitting the same form hears nothing change, and has no way to know why submission failed.
- Heading structure that skips levels for visual reasons. An h4 styled to look like a section title because it “looked right” at that size, breaking the outline a screen reader user relies on to navigate the page by structure rather than by scrolling.
- Images and icons with missing or unhelpful alt text. Either no alt attribute at all, or a filename dumped in as the description, neither of which conveys what a sighted user actually sees.
Each of these is a pattern-level fix, not a page-level one — correcting a shared dropdown component fixes every instance of it across the product in one pass, which is exactly why building these patterns correctly the first time in the design system pays for itself many times over.
Frequently Asked Questions
What is a VPAT, and do we need one?
A Voluntary Product Accessibility Template is a standardized document reporting how a product conforms to WCAG. Increasingly, enterprise and government buyers request one as part of procurement, even outside the public sector directly.
Can automated scanning alone prove WCAG conformance?
No — automated tools reliably catch roughly a third of accessibility issues. Manual keyboard navigation and screen-reader testing are required to catch the rest, including focus order and meaningful labeling that a scanner can’t evaluate.
How early should accessibility be considered in a build?
From the first component library decisions. Retrofitting accessible patterns across dozens of already-shipped pages is consistently more expensive than building them in from day one.
Does accessibility only matter for public-facing products?
No. Enterprise buyers with their own accessibility obligations increasingly extend that requirement to every vendor in their stack, including internal tools their employees use.
Where This Fits Into a Wider QA Strategy
Accessibility testing isn’t a separate discipline bolted onto QA — it’s a subset of the same exploratory, human-driven testing that catches the defects automated test suites miss more broadly. We cover that connection in more depth in What Functional QA Actually Catches That Automated Tests Miss (opens in a new tab), and for teams weighing whether a system is worth building custom at all, the decision framework in Buy vs. Build: Choosing Between Off-the-Shelf and Custom Software (opens in a new tab) is usually the right starting point before an accessibility conversation even begins.
Treating accessibility as a procurement gate rather than a QA afterthought is the difference between winning the deal and explaining, mid-cycle, why the product doesn’t qualify. Our Accessibility (opens in a new tab) team runs the combined automated-and-manual testing process procurement teams are now asking to see evidence of, backed by IAAP-certified review.