
If, like many of our clients, you’re an educational institution that relies on federal funding, or a healthcare insurance provider that participates in programs such as the ACA Marketplace, then you’re probably familiar with the accessibility requirements that go along with working with the federal government. There’s Section 508, which requires websites to provide comparable access to electronic information and data to people with disabilities, as well as Section 1557, the civil rights provision of the Affordable Care Act of 2010, which prohibits discrimination based on disability. There’s also a good chance you’ll need to detail your accessibility compliance by submitting an Accessibility Conformance Report (ACR).
You may be wondering, where do I even start putting that together? The good news is there’s a template for that! Enter the Voluntary Product Accessibility Template, or VPAT to its friends. The template comes in a variety of flavors, but for websites you’ll most likely want to use the one with the most recently updated version of the Web Content Accessibility Guidelines (WCAG): VPAT 2.5 WCAG.

A few quick notes on what a VPAT isn’t: It’s not a legal document or official certification. It’s also not a pass/fail test–it simply helps detail a site’s level of accessibility compliance. Finally, completing a VPAT shouldn’t be just a one-time task; you’ll want to ensure it is still accurate as your site changes over time.
So what is the VPAT, exactly? It outlines the guidelines required for each level of accessibility, from minimum (A), to common (AA), to extremely thorough (AAA), and includes useful links to the WCAG, with information on each guideline as well as how to meet it. After testing, each guideline is rated as “Supports,” “Partially Supports,” “Does Not Support,” or “Not Applicable.” Once everything has been filled out, signed, and dated, your VPAT becomes an ACR, much like a caterpillar becomes a butterfly.
Of course, the above makes it sound much more simple than it actually is. In reality, even with the WCAG links, a lot of the guidelines can be difficult to interpret without a background in accessibility. For example, “Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard,” seems like it would be pretty straightforward, but do you know which keys are commonly used for things like toggling a checkbox? Or what keyboard trapping is? To get a complete view of how accessible your site really is, you’ll want it evaluated by an expert. Automated testing tools can be a good start, but they’re not going to give you the full picture and may even provide inaccurate information.
To make things easier for you, when we at Clique Studios conduct VPATs, we provide a detailed checklist of what needs to be fixed and how to fix it. Even if you don’t need an ACR, having a completed VPAT is a great way to identify any issues your site might have and help ensure that it can be used by anyone. Which is pretty important, and may be worth the extra helping hand. Our line is always open, and we’re happy to chat through it with you. Off you go!
A standard audit is an internal diagnostic tool used to identify and fix bugs. In contrast, a VPAT (Voluntary Product Accessibility Template) is a standardized reporting framework intended for external stakeholders. While an audit tells your developers what to fix, the resulting Accessibility Conformance Report (ACR) tells a procurement officer or a federal agency exactly how your site performs against specific legal criteria like Section 508.
While many regulations still point to WCAG 2.0 or 2.1, WCAG 2.2 is the most current standard and includes critical updates for mobile accessibility and users with cognitive disabilities. By using the VPAT 2.5 (which covers WCAG 2.2), you "future-proof" your compliance. It demonstrates to federal partners that your institution is proactive rather than reactive regarding digital inclusion.
In short: No. Accessibility overlays, scripts that attempt to "fix" a site on the fly, do not change the underlying source code and often interfere with screen readers. Because a VPAT requires an honest assessment of the site's native code, an overlay cannot be used to claim "Support" for WCAG criteria. True compliance, as required for an ACR, must be built into the front-end architecture.
The most common mistake is a lack of detail in the "Remarks and Explanations" column. Simply marking a criteria as "Supports" without explaining how it supports it, or marking "Partially Supports" without detailing the specific exceptions, can make the document appear unreliable to auditors. A high-quality ACR provides technical context that proves a human expert actually tested the functionality.
While not always legally mandated by Section 508 for the private sector, many B2B companies and healthcare providers find that a VPAT is a competitive advantage. Large corporate clients and state agencies often require an ACR during the RFP (Request for Proposal) process. Having one ready shows that your platform is inclusive, reducing the "legal friction" for potential partners to sign a contract with you.