Your customers' accessibility deadlines are now your sales cycle.
Public agencies, universities, and health systems are writing WCAG into their contracts. Their procurement teams ask first for an Accessibility Conformance Report and then for proof that it's accurate. We help you answer both, then build accessibility into the product so the next answer is easier.
Procurement reads your ACR before it sees your demo
The Justice Department's Title II rule covers web content and mobile apps that a public entity provides through contracts and licenses, and HHS's Section 504 rule does the same for organizations that receive HHS funding, including most hospitals and health systems. Those customers can't meet their dates if your product doesn't. So the requirement flows down to you: an accessibility section in the RFP, a request for a VPAT®-based Accessibility Conformance Report, contract clauses that name a WCAG version, and sometimes a hands-on test by the customer's own accessibility team.
An ACR that claims more than the product delivers is worse than an honest one with gaps. A reviewer who tests even one workflow will find the difference, and the deal stalls on trust rather than on the gap itself. We write ACRs from audit evidence, describe partial support specifically, and pair the report with a remediation roadmap you can share.
From procurement question to credible answer
| They ask for | A credible answer | How we help |
|---|---|---|
| A VPAT® or ACR | A report on the current VPAT® 2.5Rev template, for the version being sold, with remarks that explain every partial or unsupported entry | Audit first, then write the ACR from the findings |
| Section 508 conformance | The 508 edition, tested against WCAG 2.0 Level AA plus the functional performance criteria and support documentation sections | Audit and ACR in the 508 edition |
| WCAG 2.1 or 2.2 AA | Results against the version in the contract, with the newer 2.2 criteria shown separately | One audit, reported against both versions |
| A remediation plan | Each known gap with its fix, an owner, and a target release | A roadmap built from the findings register |
| An accessibility questionnaire | Answers that match the ACR and the product, written once and reused | A reviewed answer bank your sales engineers can maintain |
| Proof it stays fixed | Automated checks in CI, manual regression testing each release, and an updated ACR for major versions | CI gates and training, plus Baclion Watch |
Standards your buyers will cite
is the current version of ITI's VPAT (Voluntary Product Accessibility Template), released April 2025 in 508, EU, WCAG and INT editions
Information Technology Industry Council (ITI), VPATis incorporated by reference in the revised Section 508 standards for federal ICT (final rule issued January 18, 2017; compliance required from January 18, 2018)
U.S. Access Board, Information and Communication Technology: Revised 508 Standards and 255 Guidelinesis the technical standard in the Justice Department's ADA Title II web and mobile app rule, published April 24, 2024
U.S. Department of Justice, Final Rule, 89 FR 31320 (FR Doc. 2024-07758)is the ADA Title II web and mobile app compliance date for state and local governments with a total population of 50,000 or more
U.S. Department of Justice, Interim Final Rule, 91 FR 20902 (FR Doc. 2026-07663)Building it into the product instead of bolting it on
Audit the design system
Barriers in a SaaS product repeat because they live in shared components: the combobox, the modal, the data grid, the date picker. We audit the component library first, so one fix clears every screen that uses it.
Fix the components
Our engineers ship fixes as reviewed pull requests in your stack and document the expected keyboard and screen reader behavior alongside each component.
Gate the pipeline
We add axe-core and component-level tests to CI so known failures can't return. In Deque's own 2021 study, automated axe testing found 57% of issues by volume, so we pair the gate with a short manual checklist for each release.
Keep the ACR current
Each major release gets a regression test and, when conformance changes, an updated ACR, so sales always sends a report that matches the product.
Onboarding that AI agents can finish, too
AI agents can now read product pages and attempt a signup or a first task on someone's behalf. Google's web.dev guidance describes 3 ways agents perceive a website: screenshots, raw HTML, and the accessibility tree. The accessibility tree is the same structure a screen reader uses, so a signup form with real labels, buttons built from <button> elements, and clear error messages works better for both.
Our Agent-Readiness Audit walks your trial signup, onboarding, and first key task the way an agent would, and checks the labels, roles, and structured data each step depends on. Most of the fixes are accessibility fixes you would want anyway. Newer proposals, such as WebMCP, are worth watching; WebMCP is currently a Draft Community Group Report, not a standard, so we don't recommend building your roadmap around it yet.
Questions from product and sales teams
Can we write our own VPAT?
You can, and many vendors do. The risk is that a self-assessment without assistive-technology testing tends to overstate support, and experienced reviewers notice. We can review an ACR your team wrote, test the claims that matter most, and suggest corrections.
How long does an ACR stay valid?
An ACR describes a specific product version. When you ship changes that affect conformance, the report should change too. We suggest reviewing it with each major release and at least once a year.
Which VPAT edition should we use?
Use the edition your buyers ask for. US federal buyers expect the 508 edition and EU buyers the EU edition, which is based on EN 301 549. Many state, local, and education buyers accept the WCAG edition, and the INT edition covers all three in one document.
Do you test mobile apps as well as the web app?
Yes. Our Mobile App Accessibility service tests iOS with VoiceOver and Android with TalkBack, and we can write a separate ACR for each app when your buyers ask for one.
Keep reading
Tell us what your website needs to do.
Send a link and a sentence about your deadline. You will hear back from a person within one business day, usually with a short list of questions and a proposed scope.