Our VPAT requests are through the roof in 2025 so we put together a chronological order of steps that new clients can expect when they need an independently issued ACR.
Note: The terms VPAT and ACR are used interchangeably. The difference is the VPAT (Voluntary Product Accessibility Template) is the template we fill in to create an ACR (Accessibility Conformance Report).
Table of Contents
Initial Client Engagement
When a client approaches us about VPAT services, the process typically begins with a consultation to understand their specific needs. During this meeting, we discuss:
- Their product or service
- Which VPAT edition they need (WCAG, 508, EU, or INT)
- Which version of WCAG they need to conform with (typically 2.1 AA)
- Their timeline and any procurement deadlines
For example, a recent client needed an ACR for their web application to submit for a university procurement opportunity. The client opted for the WCAG edition of the VPAT and used WCAG 2.1 AA for the technical standard.
Scoping
After the initial consultation, we will scope the web app to determine what screens/pages should be included in scope and calculate a price quote for the client.
In the initial call, the client gave us a brief demo of the web app which helped us become familiar with it and understand the different functions and capabilities it had.
During the demo, the client provided us with relevant information such as:
- Primary user flows
- Personas / different experiences based on roles
- Primary environments (i.e., mainly desktop or both desktop and mobile)
Proposal
After the initial client call, we just need a test account to access the web app, scope, and create a proposal. If everything’s straightforward, we may not even need a client Zoom call to create a proposal – we’ll just ask questions if we need help understanding something.
Our proposal provides a cost and timeline that reflects the amount of work necessary to complete the audit and issue the ACR.
Conducting the Audit
The audit is the most technical phase of the process and involves a systematic evaluation of the web application against the technical standard, in this illustration WCAG 2.1 AA.
Here are the methodologies we employ when auditing:
- Screen reader testing (using NVDA, JAWS, or VoiceOver)
- Keyboard navigation testing
- Visual inspection
- Code inspection
- Browser zoom testing (200% and 400%)
- Color contrast analysis
- Automated scan as a secondary check
For a typical web app with 15-25 unique screens, this phase takes approximately 1-2 weeks. Depending on our current queue, we can make a VPAT request a rush order and half that time.
Delivering the Audit Report
Once the audit is complete, we deliver a comprehensive report that includes:
- All identified accessibility issues
- Steps to reproduce each issue
- Associated WCAG success criteria
- Recommendations for fixing each issue
- Screenshots or video clips for visual context
The audit report becomes the foundation for both remediation efforts and the eventual ACR.
Remediation Phase
This is where our process is different than some other digital accessibility companies. Instead of immediately issuing an ACR that documents all the accessibility issues found, we give our clients the option to pause the ACR issuance so the client’s development team to make fixes.
However, we still need to validate the fixes before we, in effect, clear the issues as conformant on the ACR.
- Client begins remediation using our recommendations
- We recommend starting with 15-20 issues (about 10-20% of the total) for the first batch
- Client completes fixes and notifies us they’re ready for validation
- Our technical team reviews the changes and either validates or comments on what to do for issues that need more work
For clients using our Accessibility Tracker software, this process is streamlined as developers can mark issues as fixed and notify us directly within the platform.
Validation of Fixes
As the client makes fixes, our technical team validates each one to ensure it actually resolves the accessibility issue:
- We check each fix using the same testing methodologies from the audit
- If the fix is correct, we mark it as validated
- If issues remain, we provide additional guidance
- The process continues iteratively until all issues are fixed or the client decides they’ve done all they can
This validation phase validation phase usually requires 5-15 hours of technical support.
Creating the ACR
Once remediation is complete (or the client has made all the fixes they’re able to), we begin filling in the VPAT to create the ACR. Here’s what we do:
- Fill in the administrative details section
- Complete the accessibility table for each WCAG success criterion
- Indicate the appropriate conformance level for each criterion:
- Supports
- Partially Supports
- Does Not Support
- Not Applicable
- Add detailed remarks and explanations for any “Partially Supports” or “Does Not Support” entries
- Conduct a quality check of the final document
The cost for completing the WCAG edition of the VPAT is typically $550, plus the cost of the audit.
Delivery
And now we’re finished. We deliver the ACR to the client and they can in turn provide this to procurement agents so they can have the best chance of winning the contract and having their product or service purchased.
Summary
The VPAT process from initial engagement to final ACR delivery typically takes 4-8 weeks, depending on the scope of the web application and how quickly the client can implement fixes. While a fair amount of effort goes into auditing and/or validating, the resulting documentation is quite valuable for clients.
If you need help with creating an ACR for your web application, we’d be happy to help. Our approach ensures you have the opportunity to make improvements before your final documentation is issued, resulting in a stronger position during procurement evaluations.
Just send us a message and we’ll be right with you.
