Introducing VPAT^® 2.0, the More Stringent Accessibility Reporting Tool Required for Government IT Procurement

Accessibility reporting requirements for government IT just got tighter—Here’s how VPAT^® 2.0 affects vendors, purchasers, and people with disabilities.
*NOTE: The Information Technology Industry Council has released subsequent minor VPAT revisions, available on the ITIC VPAT^® web page. Read more about the VPAT^® 2.4 updates. Last updated: 4/30/2021

Where there’s government, there’s technology. And where’s there’s government technology, there’s a requirement to be accessible to people with disabilities.

For 20 years, United States federal government agencies and federally funded programs have been required to make information and communication technology (ICT) products and services they procure, develop, maintain, and use accessible to people with disabilities.  This includes a wide variety of products such as websites, photocopiers, fax machines, word processing applications, and more.[1]

In fiscal year 2017, the federal government sector spent $81 billion on information technology.[2]

A growing number of companies—from startups to industry giants—are aiming for a piece of that government technology budget.  That means it’s critically important that both sides of the government procurement relationship understand what accessibility means, how accessibility compliance is determined, and how to both relay and understand the accessibility standing of any given product or service.

Recently, the Voluntary Product Accessibility Template® (VPAT®), a primary communication tool for vendors to describe the accessibility compliance of their offerings, has gotten an upgrade.[3] This upgrade will help vendors more clearly communicate how well their products and services meet accessibility requirements, help purchasers more easily ascertain accessibility compliance, and encourage ongoing development of technology that allows people of all abilities to more fully participate in their government, education, and communities.

This article will cover:

• What is a VPAT^®?
• The Original VPAT^®: Overall Structure
• Limitations of the Original VPAT^®
• The Updated VPAT^®: Additional Content Requirements and Alignment to New Standards
• A Walkthrough of Critical VPAT^® 2.0 Sections for Vendors
• Limitations of VPAT^® 2.0

What is a VPAT^®?

A VPAT^® is a report attesting to the accessibility of an information and communication technology (ICT) product or service.[4]  Accessibility is required by Section 508 of the U.S. Rehabilitation Act of 1973, as amended ((29 U.S.C. § 794 (d)) (Section 508).[5]  The report benefits federal procurement officials and is required for almost all federal solicitations.  It was created and is now maintained by the Information Technology Industry Council (ITI) a trade association that represents companies from the information and communications technology industry.  The VPAT^® has become a mainstay of federal purchasers and has been adopted by state government, local government, non-profits, and even private sector procurement departments that include accessibility requirements in solicitations.

Editor’s Note:
To see how Section 508 aligns with the Web Content Accessibility Guidelines 2.0, see Hiram’s article, Section 508 Refresh: How WCAG Impacts Federal Website Accessibility Requirements

In the federal government, the term “information and communication technologies” refers to a broad category of products.  Many state governments adopted the same approach but have varying names: electronic and information resources (EIR), electronic and information technology (EIT), etc.

Below are the most commonly cited categories of products:

• Software used on public-facing agency websites
• Software used by employees in the performance of their work
• Services to develop websites used by employees or the public
• Externally hosted websites or services used by the public or agency employees
• Copiers and fax machines
• Telephone systems
• Interactive voice response systems
• Smart phones
• Tablets
• Software
• Digital documents
• Services accessed through ICT

As you will note, ICT applies to not only digital products such as websites, but also physical devices such as copiers.  This product definition must remain consistent with Section 508 which originated the product and services requirements for VPAT^® reporting.[6]

VPAT^® 1.3 was replaced by VPAT^® 2.0 as the standard reporting procurement document in January 2018.  What follows is a comparison of the two versions.

[Back to Content Outline]

VPAT^® Primer – What is a VPAT? (With Video)

The Original VPAT^®: Overall Structure

The original VPAT^® 1.3 report is a simple three-column layout centered around the following legacy 508 sections:

• Section 1194.21 Software Applications and Operating Systems
• Section 1194.22 Web-based Internet Information and Applications
• Section 1194.23 Telecommunications Products
• Section 1194.24 Video and Multi-media Products
• Section 1194.25 Self-Contained, Closed Products
• Section 1194.26 Desktop and Portable Computers
• Section 1194.31 Functional Performance Criteria
• Section 1194.41 Information, Documentation and Support

The basic layout within each section has three parts:

• Criteria,
• Supporting Features, and
• Remarks and Explanations.

As implied, “Criteria” specifies the testable accessibility condition.

“Supporting Features” should contain one of four responses:

• Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
• Supports with Exceptions: Some functionality of the product does not meet the criterion.
• Does Not Support: The majority of product functionality does not meet the criterion.
• Not Applicable: The criterion is not relevant to the product.

And lastly, “Remarks and Explanations” should contain any commentary by the vendor further detailing how the criteria is either met or not met (Table 1).

[Back to Content Outline]

Limitations of the Original VPAT^®

There have been several challenges for purchasers in interpreting a VPAT^®, namely vagueness, complexity of the response, the opportunities for inaccuracy, and the absence of information about how accessibility compliance was determined.

Vague Language

Many organizations do not have the background or understanding of how to evaluate or report on accessibility.  This resulted in many vendors using vague language in an attempt to satisfy the VPAT^® submission requirement but not fully attesting to the accessibility of the product (Example: “There is nothing inherent in the {product} that would prevent a user from accessing the feature.”).

Complexity of Response

Many products have limitations that can be compensated for by the addition of other products and services.  A phone system is a prime example of how a piece, such as a handset, may not be usable by someone who is blind and cannot perceive the visual line indicators, but can be accommodated with an alternate accessible product such as an application that runs on a desktop and headset.  In this case, the purchaser must read and understand the implications of the response.  This may entail the need to review and adjust the procurement specifications and cost projections of the accommodation (Example: “For users who cannot see displays, satisfaction of this requirement can be achieved by using the telephone in conjunction with {another product}”).

Inaccuracy

One of the primary complaints by purchasers is the inaccuracy of the VPAT^®.  Whether the vendor simply lacked an understanding of accessibility or rushed to get a VPAT^® together for a solicitation, the result does not accurately reflect the product’s accessibility.

Lack of Compliance Validation Information

While not required in VPAT^® 1.3, very few responses discussed how accessibility was verified.  Using the prescribed format, a vendor could simply give an opinion as to the perceivability and usability of their product and not describe how they ensured that product met the requirement.

[Back to Content Outline]

The Updated VPAT^®: Additional Content Requirements and Alignment to New Standards

On October 4, 2017, ITI published VPAT^® 2.0.  This change was in keeping with the then-newly updated ICT accessibility standards within Section 508. [7]  The Section 508 refresh provided an opportunity for ITI to align the VPAT^® with the explicitly required accessibility standard, Web Content Accessibility Guidelines (WCAG) ISO/IEC 40500:2012.[8]  This also afforded ITI an opportunity to broaden VPAT^® appeal by including the European ICT public sector procurement standard, EN 301 549.

As of January 2018, VPAT^® 2.0 is the official document that should be required on all federal solicitations; however, few companies at the time of this writing have officially published a new version.

Taking a closer look at the VPAT^® 2.0 reveals many improvements that tighten the reporting requirements.

[Back to Content Outline]

A Walkthrough of Critical VPAT^® 2.0 Sections for Vendors

In the first section of the new VPAT^®, the vendor is asked to provide some basic information:

• Name of Product/Version
• Product Description
• Date
• Contact Information
• Notes
• Evaluation Methods Used
• Applicable Standards/Guidelines
• Terms
• Tables for Each Standard or Guideline

A key portion of this section is the “Notes” field.  The VPAT^® instructions provide guidance on this field, which includes:

• Additional information about the product version that the document references
• Any revisions to the document
• Links to any related documents
• Additional information describing the product
• Additional information about what the document does or does not cover
• Information suggested by the WCAG 2.0 Conformance Claim, at http://www.w3.org/TR/WCAG20/#conformance-claims
• Information needed to satisfy ISO/IEC 17050-1:2004, Supplier’s Declaration of Conformity

While there appears to be no pass/fail component to the notes, there are technical disclosures cited in the example.  For instance, WCAG 2.0: Conformance Claims suggests listing the web content technologies relied upon.[9], [10].  So, a vendor would need to outline content that calls out technical specifications such as HTML, but may call out the use of videos, audio, and other content assets that have significant accessibility implications.

The next key addition is the field, “Evaluation Method Used.”  The VPAT^® provides the following suggestions as responses:

• Testing is based on general product knowledge
• Similar to another evaluated product
• Testing with assistive technologies
• Published test method (provide name, publisher, URL link)
• Vendor proprietary test method
• Other test method

This presents a purchaser with the first significant glance of how accessible a product is.  For example, when attesting to the accessibility of digital products such as a website, many vendors rely on automated accessibility testing.  Because this type of testing only catches between 30% to 40% of accessibility errors, a VPAT^® that does not purport to have a combination of manual and automated testing could be suspect.

Example of an Insufficient Evaluation Method:  Test with WAVE Toolbar by WebAIM
Example of a more Sufficient Evaluation Method:  Manual testing with the JAWS screen reader on Windows and automated testing via the WAVE Toolbar by WebAIM

The next key field is “Applicable Standards/Guidelines.”  It explicitly asks the level of conformance reporting.  As noted in Table 2, WCAG 2.0 asks the vendor to state which sections have been included.  For most products, the purchaser will be looking for WCAG Level A or Level AA.  Level AAA is a highly specialized category and is not required for most organizations at this time.  A report in which the vendor claims conformance to Level AAA raises a red flag indicating that the vendor either does not fully understand the requirements or has a highly specialized product.

The new VPAT^® does allow vendors to specify conformance to the previous Section 508 standards, before its 2017 update.  This allows the vendor to include documentation using the older VPAT^® 1.3 standard. The vendor may also apply the European EN 201 549 standards.  NOTE:  The older Section 508 and EN 201 549 is not required and is so stated in the VPAT^® instructions:

If not completing a set of Standards such as Section 508 or EN 301 549, then remove the breakdown information and answer only for the WCAG criteria.

The next major area is the WCAG 2.0 Report (Table 3).  Each conformance level—Level A, Level AA, Level AAA—is broken into a standalone section.  Like the VPAT^® 1.3 template, each section has a Criteria, Conformance Level, and Remarks and Explanations section.

Within the “Criteria” column, both the older Section 508 standards and the EN 201 549 are mapped to the WCAG requirement.  This is to reduce ambiguity for the vendor when mapping these older standards to WCAG.

Within “Conformance Level,” ITI breaks down the components that could conceivably make up a product.  It is the vendors responsibility to use one of the following conformance levels on all components that apply:

• Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
• Supports with Exceptions: Some functionality of the product does not meet the criterion.
• Does Not Support: The majority of product functionality does not meet the criterion.
• Not Applicable: The criterion is not relevant to the product.
• Not Evaluated: The product has not been evaluated against the criterion. This can be used only in WCAG 2.0 Level AAA.

The instructions for the final column, “Remarks and Explanations,” attempt to further tighten reporting with the following suggestions:

• When the conformance level is “Supports with Exceptions” or “Does Not Support,” the remarks should identify:
  1. The functions or features with issues
  2. How they do not fully support
• If the criterion does not apply, explain why.
• If an accessible alternative accommodation is available, describe it. This is key to responding to this section.  A failure without a secondary alternative (accommodation) may at the discretion of the purchaser disqualify the product from consideration.

This is an attempt to address the shortfalls noted in the VPAT^® 1.3 section.  Clearly the intent is to provide less opportunity for vague or creative responses that avoid answering whether the product meets guidelines.

The next major field is the 2017 Section 508 Report (Table 4).  There is still value in addressing older Section 508 requirements since the older Section 508 has sections that cover hardware (WCAG, to which the updated Section 508 more closely aligns, focuses primarily on content).

The next field, “EN 301 549 Report,” is a European standard and has some interesting additions.  Vendors with European concerns may choose to incorporate this section.

The final area is “Legal Disclaimer.”  While the area is vaguely described, we believe vendors will produce good faith language that states that an effort has been made to accurately and completely describe the accessibility of the product, but that there may be minor technical flaws that will not impede the use of the product or service by a person with vision, hearing or mobility challenges.  These disclaimers usually contain a clearly stated commitment to ensuring equal access for all users and a summary of the overall level of compliance with accessible technology standards.  Key to this section is a wide belief that 100% accessibility is not achievable as there are a myriad of technical failures that would not hinder the use of the product but would violate the WCAG 2.0.

Example of Technical Failure: A web page may contain objects with duplicate ids.  While this does not necessarily affect a user, it does violate WCAG 4.1.1. Parsing as a technical failure.  Therefore, a product could not claim 100% compliance even though the technical error may not impact users with or without disabilities.

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.  (Level A)

[Back to Content Outline]

Limitations of VPAT^® 2.0

It is important to note that the VPAT^® is not a certification of compliance nor is it intended to be a pass/fail tool.  While VPAT^® 2.0 offers a purchaser significantly greater insight into the degree to which a product will be perceivable and usable by a person with vision, hearing, mobility, or cognitive challenges, completing the form only attests to the degree to which it complies with the noted standards.  The purchaser must evaluate the response and determine if the product as stated meets the accessibility needs of the organization.

For example, there are a few WCAG criteria that are stringent and may be difficult for a vendor to meet or remediate for Level AA compliance.  The WCAG Success Criterion 1.2.5 Audio Description (Prerecorded) requires that visual content displayed in a video must be verbally described.  For example, a video that has an introductory slide that states the presenter name, title and credentials but lacks a narrator verbally describing the information aloud, fails this criterion as a person who is blind would not be able to perceive the information displayed on the screen.  This is similar to missing alternative text that describes a graphic on a web page or e-book.  Vendors who are not in compliance with this requirement have failed a WCAG requirement but may still be considered by the purchaser.

We first addressed limitations of the previous VPAT^® in 2016 in VPAT^®s and Section 508 Accessibility Compliance, before Section 508 had been revised. There, we talked about the risks of inaccurate VPAT^® reporting and how to determine that reporting risk. Those sections can still provide value to vendors and purchasers wanting to ensure they are on track for providing accessible technologies to their end users. 

[Back to Content Outline]

Conclusion

In closing, the VPAT^® 2.0 will be a powerful tool that allows vendors and purchasers to have more meaningful and direct conversations during the procurement process.  While this will directly benefit both purchaser and vendor, the result is intended to promote and procure the development of products that reduce or eliminate barriers to employment and self sufficiency for people with vision, hearing, mobility, and cognitive challenges.

This article on VPAT^® 2.0 reprinted, with updates and modifications, from the February 2018 issue of Mealey’s™ Litigation Report: Cyber Tech & E-Commerce. It was originally published as “Introducing VPAT^® 2.0, The More Stringent Accessibility Reporting Tool Required For Federal Procurement.” Mealey’s is a subscription-based information provider and a division of LexisNexis. Copyright © 2018 by Hiram Kuykendall. Responses welcome.

Microassist Helps Vendors and Purchasers Ensure Accessible ICT

Microassist is a recognized leader in creating accessible products for federal and state agencies, corporations, and higher education environments on desktop, tablet, and mobile devices. Microassist delivers products that can strictly adhere to Section 508 of the U.S. Rehabilitation Act and Texas Administrative Codes TAC 206 and TAC 213, helping you ensure that your ICT products and services are in compliance.

More VPAT Resources for Technology Vendors and Suppliers

• VPAT Primer: What is a VPAT?
• Navigating VPAT Requirements for Vendors (Webinar Recording)

Read more about our Accessibility IT Services contract with the State of Texas Department of Information Resources (DIR), or contact us directly for more information on

• VPAT^® completion
• VPAT^® interpretation
• Accessibility remediation for existing digital platforms and materials

NAICS: 541512, 541511, 541611, and 611420.
D&B: 788754885 | Cage Code: 7SRF5
TX HUB: #56092 | SBA Profile: P2163270

Endnotes

[1].    Section508.gov: Is it ICT?  Determine if a product is Information and Communication Technology (ICT), https://www.section508.gov/content/is-it-ict

[2].    GovTech Navigator: 2017 Government IT Spending, http://www.govtech.com/navigator/numbers/2017-government-it-spending_54.html

[3].    ITI VPAT^® home page,  https://www.itic.org/policy/accessibility/vpat

[4].    A download of the Voluntary Product Accessibility Template® (VPAT®) Version 2.0, is available in Microsoft Word format here: https://www.itic.org/dotAsset/d432b9da-3696-47fe-a521-7d0458d48202.doc

[5].    Section 508 home page, https://www.section508.gov/

[6].    Section508.gov: Is it ICT?

[7].    United States Access Board: Information and Communication Technology (ICT) Final Standards and Guidelines, https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule

[8].    Web Content Accessibility Guidelines (WCAG) 2.0, https://www.w3.org/TR/WCAG20/

[9].    Web Content Accessibility Guidelines (WCAG) 2.0: Conformance Claims,  https://www.w3.org/TR/WCAG20/#conformance-claims

[10].   Web Content Accessibility Guidelines (WCAG) 2.0: Definition of technology as it pertains to web content,  https://www.w3.org/TR/WCAG20/#technologydef

Photo by Sebastian Pichler on Unsplash | “Voluntary Product Accessibility Template” and “VPAT” are Federally Registered Service Marks of the Information Technology Industry Council (ITI).

Related Posts

VPAT: What Technology Vendors Need to Know

Why Every Product Needs a VPAT

Find Your Perfect Match: Tips for Selecting the Right VPAT Vendor Partner