Is a VPAT voluntary for your product?

What is a VPAT?

If you are working in the digital space, you may have heard references to a VPAT and wondered whether you need one. The answer to that question depends on what kind of digital experience you are producing as well as who your intended customers are.

VPAT stands for Voluntary Product Accessibility Template. It is a standardized template for businesses and organizations to report on the accessibility conformance of their software products or services. In theory, this standardization makes it possible for readers to understand a product’s accessibility features along with the standards that it does not (yet) meet.

How is a VPAT different from an accessibility statement?

It’s common these days to see an Accessibility Statement in website footers. The purpose of such a statement is to communicate an organization’s commitment to providing an accessible digital experience. In most cases, accessibility statements will cite a target accessibility standard such as WCAG 2.1 Level AA and most will provide an email address or phone number for users with disabilities to offer feedback or request additional help.

While some accessibility statements go into more detail as to a website’s current level of compliance, most do not. And even if a website will acknowledge that it falls short of its target, accessibility statements rarely provide much detail as to the current compliance gaps.

VPATs need to go into much more detail. It can’t just claim that a product passes or fails WCAG (or Section 508). The exact information included in a VPAT differs based on the accessibility standard being measured, but all VPATs should include the following:

• Detailed description of the testing methods and tools used to produce the assessment
• Conformance level of the application for each of the relevant accessibility criteria (e.g. guidelines in WCAG) at one of four statuses:
  • Supports: the application fully meets the criteria with no errors or issues
  • Partially supports: the application meets some of the criteria with some exceptions (bugs or issues)
  • Does not support: on balance, the application does not meet the criteria
  • Not applicable: the criterion isn’t relevant to the application. For example, if an app does not include video content, any criteria related to captioning are not relevant.
• When a product only partially supports a specific accessibility criterion, the report should provide details about the exceptions.
• When a product fails a specific accessibility guideline, the report should describe how it does not support the criterion.

Why should you get a VPAT?

Procurement!

Despite the name, VPATs are not necessarily voluntary. Under Section 508 of the Rehabilitation Act, the federal government is required to maintain accessibility standards for software and other IT products it provides and uses. In most cases, businesses or organizations selling to the federal government (or in many cases to state or local governments) must produce a VPAT as part of the procurement process in order to disclose the accessibility status of their application. Organizations that are federally funded will also usually require a VPAT as part of their own procurement processes as well.

But VPATs are not just useful for the federal government. Under the Americans with Disabilities Act (ADA), state and local government bodies as well as many private businesses must also ensure that their websites, applications and other digital experiences are accessible to users and customers with disabilities. And they face the same challenges in purchasing and procuring software, applications and digital services. Sharing information about your product’s accessibility in a standardized and precise format is useful to customers, partners, and other users who need to know the actual state of accessibility. In fact, Access Armada makes use of publicly available VPATs to evaluate and recommend accessible third party software.

Who doesn’t need a VPAT

As we noted above, VPATs are required as part of the federal procurement process and can be useful (but voluntary) in other scenarios. Websites and consumer apps are required to be accessible to all users under the ADA, but a VPAT is often unnecessary (and can potentially be overkill). Our general recommendation is that B2B providers may find it beneficial to produce a VPAT for digital experiences such as:

• Third-party widgets or embeds meant to be included in other organizations’ websites including (but not limited to):
  • Forms
  • Chat systems
  • Video players
  • Maps
• Software and applications for internal use by employees
• Services used by job applicants

How to produce a VPAT?

As we noted above, a VPAT isn’t necessarily meant to certify that an organization is fully in compliance with accessibility standards. The purpose of a VPAT is to accurately represent the current state of accessibility in detail in order to allow the procuring organization (or customer) to understand what it is purchasing. You don’t want to include inaccurate information that could create legal issues for you down the line if inaccurate. If you have accessibility expertise in house, you may be able to produce your own VPAT. But as a matter of risk management, it usually makes sense to bring in an impartial outside firm to evaluate and document your product’s accessibility on the VPAT.

Of course, your customers on balance would prefer to purchase more accessible software. While accuracy is key, it’s better to make your product as accessible as possible before producing a report. We recommend that you schedule a sequence of accessibility audits or assessments before finalizing a VPAT. The initial audit can provide you a roadmap of accessibility issues requiring remediation. The second assessment would verify which issues have been fixed and serve as the raw material for the VPAT’s conformance report.

How Access Armada creates VPATs

Access Armada regularly produces VPATs as the capstone to a thorough audit process. We work closely with your organization to determine the proper scope for assessing your site, application or service. All audits document all accessibility issues including reproduction steps, level of severity, screenshots or screen captures of the testing, and recommendations for remediation. Typically organizations will work to address issues before having the application retested and a final status report documented in the VPAT template.

Contact us to get more information on creating a VPAT for your organization.