Why accessibility is now a procurement condition
Four buyer segments, one converging contractual standard.
US federal. Section 508 of the Rehabilitation Act has required accessible procurement of electronic and information technology since 1998. The 2018 refresh aligned the standard with WCAG 2.0 AA and EN 301 549 by direct reference, which means a federal buyer's procurement gate is no longer a domestic checkbox — it is a global accessibility standard with a US legal wrapper. Every federal RFP now lists a conformance statement as a deliverable, and every federal contracting officer is now empowered to reject a delivery that lacks one.
US state and local. Most state IT procurement now requires VPATs and WCAG conformance as a default contract term — California, New York, Texas, Illinois, Massachusetts, Minnesota, and Washington have all adopted procurement standards that mirror or exceed the federal 508 baseline. Cities and counties increasingly follow suit, often citing their state's standard verbatim. An integrator bidding into US public-sector work without a VPAT-ready posture is bidding against teams that already have one.
EU. The European Accessibility Act (Directive 2019/882) imposes accessibility as a product-and-service property. When an integrator ships into an EU-scoped client, the integrator is part of that client's compliance posture — Article 9 obligations apply to the placed-on-market entity, and supply-chain due-diligence means clients will reach back to integrators for the evidence. Member-state enforcement moved from warning-letter phase in 2025 into fine-issuing phase in 2026.
Enterprise (private). Fortune 500 procurement teams now embed accessibility warranties in master services agreements as boilerplate. The cost of an accessibility failure falls partly on the integrator under those warranties — particularly under indemnity clauses that haven't been negotiated. The same MSA that includes data-protection, security, and IP warranties now includes an accessibility-conformance warranty, and treating it as an afterthought is how integrators end up funding a client's ADA Title III settlement.
30-point WCAG 2.2 AA delivery checklist for integrators
Six delivery surfaces × five checks. Print it, tick it, then audit it.
-
01 Contract & SOW posture
-
02 Engineering practice
-
03 Component & design system
-
04 Documentation & evidence
-
05 Testing & sign-off
-
06 Handoff & maintenance
Vendor and platform notes for integrators
Where the checklist actually lands in code, by delivery stack.
Salesforce, ServiceNow, Workday
Enterprise SaaS platforms ship with a baseline accessibility posture and a published VPAT — usually the best-documented in the category. What they give you for free: a layout system that meets contrast and focus baselines, a component library with sensible semantics, and a screen-reader story on the primary flows. What you still have to build accessibly: every custom Lightning component, every Now Experience UI Builder page, every Workday Studio integration UI. The platform clears the bar at the framework level; your customisation is what gets audited.
SAP, Oracle, Microsoft Dynamics
Legacy enterprise UI surfaces are the hardest category. Fiori (SAP) has come a long way and ships a real accessibility story; Oracle JET and Redwood are credible; Dynamics 365 inherits the broader Power Platform posture. But the integrator's footprint on these stacks is usually screens that pre-date the modern framework — Web Dynpro, classic Forms, custom JSP — and the conformance gap there is real. Negotiate the scope of your accessibility warranty to exclude pre-existing legacy surfaces unless explicitly contracted to remediate them.
Sitecore, Adobe Experience Manager, Optimizely
CMS platforms are the case where the VPAT quality varies most. AEM and Sitecore both publish VPATs for their authoring environments — usable, with caveats — but the conformance of the published front-end depends entirely on the templates your team ships, not on the CMS. Optimizely is similar. The integrator's obligation is the rendered HTML, not the authoring UX; build your delivery posture around the front-end templates, the component library, and the personalisation rules that swap content at runtime.
Custom React, Vue, Angular front-ends
Full-ownership stacks mean full ownership of the conformance story. The recurring failure modes are framework-level: hydration mismatches that leave aria attributes in inconsistent states between SSR and client; client-side route changes that never announce because the router replaces the page without re-rendering a heading or moving focus; and component-library choices that look accessible in isolation but fail in composition. Lean on the accessible component libraries survey when picking a base — Radix, Reach UI, React Aria, Headless UI, and a few others have meaningfully better accessibility baselines than the bootstrap-era kits still floating around enterprise repositories.
Public-sector platforms
State and local procurement frameworks attach accessibility riders that go beyond the federal 508 baseline: California's Government Code §7405, New York State OFT P04-002, Texas TGC §2054.451. Read the rider before bidding — many require the VPAT delivered against a specific revision of the standard, against a specific test methodology, and reviewed by a named accessibility officer. The accessibility-aware RFP teardown walks through the boilerplate clauses that turn into deliverables, and which clauses to flag to your contracts team before signature.
The monitoring + audit cycle
A one-time pass at delivery doesn't survive the client's first sprint after sign-off.
Integrator deliveries don't sit still after handoff. The client's marketing team flips a hero on Tuesday, the internal product owner approves a new module on Thursday, a downstream contractor patches the checkout over the weekend. A one-time accessibility pass at acceptance lasts roughly as long as the client's next deploy — which is why the model that actually holds, and that survives an integrator's contractual warranty, is three layers stacked on top of each other.
First, run a free WCAG 2.2 scanner against the staging build before every internal milestone, and against the production build before every release; this is the layer that catches regressions before they ship to acceptance testing. Second, commission a manual audit by testers with disabilities before any major release — automated tooling will never catch screen-reader legibility, focus-order intent, or whether a flow is actually usable end-to-end. Third, wire continuous monitoring into the client environment as part of the handoff package so the conformance story doesn't quietly decay between your engagements.
For the integrator-to-client handoff specifically, our monitoring buyer's guide covers the platforms that span scan, manual audit, and statement delivery in one workflow — Qualibooth, axe Monitor, Siteimprove, and Level Access. Qualibooth is a particular fit for the integrator handoff: one platform the integrator can stand up during build, hand to the client at delivery, and keep monitoring under a maintenance retainer — scan, triage, manual audit, and statement from the same console. Compare against axe Monitor (deepest CI/CD integration), Siteimprove (broadest enterprise install base), and Level Access (largest audit-tester network) on stack fit and on whether the tester network includes the disabilities your end users actually have.
FAQ
The questions integrator delivery leads ask before they commit.
What's a VPAT, and do all my clients want one?
A VPAT (Voluntary Product Accessibility Template) is a standardised document — currently revision 2.5 — that reports how a product conforms to WCAG 2.x, Section 508, and EN 301 549 success criteria. US federal buyers require one as a procurement gate, US state buyers usually do, and large enterprise buyers increasingly request one as a contract attachment. If your client is buying through a procurement function with a compliance officer, assume yes. If your client is a five-person startup, assume no — but be ready to produce one inside a quarter if they get acquired or land a regulated customer.
Section 508 vs WCAG 2.2 — which does a US federal client want?
Both, and they overlap. The 2018 Section 508 refresh aligned the federal standard with WCAG 2.0 AA by direct reference. EN 301 549 v3.2.1 references WCAG 2.1 AA, and v4.x moves toward WCAG 2.2 AA. The practical answer: build to WCAG 2.2 AA, document against both Section 508 and EN 301 549 in your VPAT, and you cover federal procurement, most state procurement, and EAA-scoped EU work in one artefact.
How do I write an accessibility warranty into an SOW without overcommitting?
Scope the warranty to (a) a specific standard ("WCAG 2.2 Level AA conformance, with documented exceptions"), (b) a specific surface ("the screens and flows delivered under this SOW"), and (c) a specific evidence basis ("verified by automated scan and the manual audit attached as Exhibit B"). Carve out client-supplied content, third-party components the client mandated, and any browser/AT combinations published as out-of-scope in the audit report. Avoid open-ended "fully accessible" or "100% compliant" language — neither standard nor enforcement body defines that phrase, and it will be read against you in a dispute.
Who's on the hook when an integrator-built system gets sued — the integrator or the client?
Both, depending on contract. In US ADA Title III litigation, the customer-facing entity is typically named as defendant — your client. But your MSA almost certainly contains an indemnity clause, and if you accepted a broad accessibility warranty without carveouts, the costs flow back to you. EU enforcement under the EAA targets the entity that places the product or service on the market — usually the client again — but the supply-chain due-diligence expectation means clients will increasingly push contractual remedies up to their integrators. Read your indemnity clauses, scope your warranties tightly, and carry the right insurance.
What does an accessibility-handoff package look like at delivery?
At minimum: (1) a current VPAT, (2) an accessibility statement template the client can publish, (3) the most recent manual-audit report by testers with disabilities, (4) the production-build scan baseline, (5) a remediation log with severity and ETA, (6) AT-tested-with notes, and (7) monitoring wired into the client environment with alert routing. If any are missing at sign-off, the client is one demand letter away from coming back to you.
How do I price an accessibility deliverable into a fixed-fee engagement?
Three line items: (a) the per-sprint engineering uplift (typically 5-10% on net-new UI work if your team is trained; up to 25% if it is not), (b) the audit deliverables (a real manual audit by testers with disabilities runs $8,000-$25,000 depending on surface count), and (c) the monitoring and statement maintenance retainer post-launch. Bundle them transparently in the proposal — clients respect a line item more than they respect a padded blended rate, and an itemised price makes the warranty defensible if anything ever goes wrong.
Three next steps
Pick the one that matches where your delivery practice is today.
-
Run the free scanner against a current build
A live free WCAG 2.2 scanner against any public URL. Best place to start if you want a baseline conformance picture of an in-flight delivery before you commit warranty language.
-
Read the RFP teardown
Our accessibility-aware RFP teardown walks through the procurement clauses that turn into deliverables, with sample contract language and the carveouts that keep your warranty defensible.
-
Audit the published statement landscape
See where your client's published accessibility statements stand against the top-100 statement audit — a useful gut check on which clauses are now table-stakes and which are still differentiators.