DEPARTMENT OF HEALTH & HUMAN SERVICES
OFFICE OF THE SECRETARY ACCESSIBILITY PROGRAM
Acquisition Guidance on the Voluntary Product Accessibility
Template (VPAT
®
) and Accessibility Conformance Report (ACR)
➔ Purpose of a VPAT
®
The legal requirement is to procure the most accessible digital product(s) to meet the business
need(s). Therefore, it is important to have some form of measurement to determine the
accessibility of digital products prior to purchase.
The Information Technology Industry Council (ITIC) is the creator of the VPAT
®
. The VPAT
®
(current version) is a tool that was developed to ensure that digital products are conformant with
Section 508 (an amendment to the Rehabilitation Act of 1973). This law requires that the federal
government develops, procures, funds, maintains, or uses information and communications
technology (ICT) that is accessible to all people with disabilities, not just federal government
employees.
The outcome of a completed VPAT
®
is an Accessibility Conformance Report (ACR). An ACR
is used as a measurement to identify conformance to Section 508 standards of ICT prior to HHS
developing, procuring, funding, maintaining, or using a particular version. As a result, a
continuous assessment is needed for each iteration and/or instance.
In some cases, HHS will consider an ACR or checklist from another federal agency. These must
be reviewed and approved by the HHS and OS Accessibility Program prior to acceptance.
For vendors:
• Some type of conformance report (ACR, HHS checklist, etc.) is required for digital
product(s) to be considered for acquisition into the HHS IT Enterprise.
o HHS authorizes an HHS compliance checklist can be submitted in lieu of an
ACR, as both forms of documentation map to the Web Content Accessibility
Guidelines (WCAG).
• Technical guidance informs what and how HHS is assessing ICT conformance risk and
risk to the HHS IT Enterprise.
For program teams:
• An ACR is necessary to assess and evaluate the conformance risk level the digital
product(s) poses to the HHS IT Enterprise.
• A completed HHS checklist is the preferred template for measuring conformance.
• The proposed digital product(s) is considered high risk when the ACR conformance level
indicates a result of “does not support.” In these instances, the digital product(s) may
need to be reconsidered for procurement.
• Where deficiencies exist:
o Can the vendor correct all deficiencies (ideal outcome) that reduces risk and
meets HHS’ accessibility requirements?
o If not, assess whether modifications or enhancements can be completed by the
development team to meet HHS’ accessibility requirements.
o Prepare an action plan to address any deficiencies identified in the ACR.
The HHS and OS Accessibility Program is available to support both vendor and program team
efforts through consultation, collaboration, and direct involvement.
Acquisition Guidance on the Voluntary Product Accessibility Template
(VPAT
®
) and Accessibility Conformance Report (ACR)
➔ Importance of an ACR to HHS
Program teams need to request a conformance measurement method (ACR, HHS checklist, etc.)
for acquisition and procurement teams to thoroughly vet and validate that the information
vendors provide about digital product(s) is accurate. An ACR states the conformance of the ICT.
The ACR enhances the ability for decision-makers to plan major IT investments and was
developed for the federal government to assess risk of non-conformance during the acquisition
process. Establishing a template for vendors to complete allows a consistent format to convey
the vendor’s perceived level of conformance.
According to the HHS Acquisition Regulations (HHSAR), HHS is required to ensure that all
ICT, whether it be hardware, desktop software, web applications, mobile content, electronic
documents, or other ICT, are accessible to anyone with a disability. A technical evaluation panel
(TEP) is responsible for choosing the most accessible product based on the evidence provided
(ACR, HHS checklist, etc.). All HHS stakeholders involved in the acquisition, procurement, and
selection process should possess the technical expertise to evaluate ACR responses or engage the
HHS and OS Accessibility Program to assist.
➔ Best Practices for Interpreting an ACR
Program, acquisition, and procurement teams alike must be able to identify sufficient evidence to
support the following key elements when reviewing an ACR:
• Did the vendor measure the Section 508 standards against the version being procured?
• Is the content provided within the ACR complete?
• Based on applicable criteria results, does the digital product(s) meet the business need(s)
of the procurement?
• Are features (both “supported” and “not supported”) explicitly named?
• For items that are “partially supported” or “not supported,” are alternative means to meet
conformance requirements identified?
• Has a timeline been established for bringing “partially supported” and “not supported”
items into full conformance?
• What test methodology was used to conduct conformance testing?
• What accessibility credentials are held by the assessor?
➔ Vendor Reporting
It is the responsibility of the vendor to ensure responses on an ACR, or in a checklist, accurately
reflect the accessibility state of the proposed digital product(s) and that the documentation is
completed in its entirety.
When reporting results in a VPAT
®
or checklist against one of the WCAG success criteria, it is
imperative to provide accurate and complete information so the TEP can make an informed
decision. Reporting information to address accessibility from multiple perspectives include:
• How was the test for keyboard accessibility conducted?
• How was the test for visual focus conducted?
• Are adequate text descriptions provided for images?
• Are structural elements identified through appropriate markup?
• Does the content reading and navigation order follow a logical sequence?
Collectively, these technical elements—among other factors—will be evaluated across all
submissions to determine the digital product(s) that best meets the project’s business need(s).
Acquisition Guidance on the Voluntary Product Accessibility Template
(VPAT
®
) and Accessibility Conformance Report (ACR)
➔ Testing Methods
A vendor must decide on a testing approach and identify the method in conformance
documentation. The table below outlines three testing methodologies:
Testing
Type
Method Description
Pros and Cons
Automated
(Not
Sufficient)
A method that utilizes a normative
(rule-based) tool that identifies failures
within a sub-set of standards.
Automated scans alone are not
sufficient to provide reliable results.
Automated testing provides users with a
high-level indication of whether the
most basic (i.e., low-hanging fruit)
accessibility coding of features are or
are not conformant.
• High dependency on
technology, low dependency on
output interpretation.
• Automated tests cannot apply
human subjectivity; therefore,
can only test for a small number
of the total requirements.
• Tools that conduct automated
scans often leave major gaps in
validating conformance.
Manual
(Minimally
Sufficient)
A method that engages a qualified
individual to follow a testing process
that inspects code and supplements
findings with the outputs of assistive
technology (AT).
Lends itself to a human deciding
whether the intended message is
properly conveyed.
While the testing time is longer with
this method than automated, it does not
have to be a lengthy process.
• More thorough content
evaluation by accessibility
SMEs to ensure conformance
with standards.
• High dependency on human
investigation, low or no
dependency on tool output.
• Doesn’t apply AT to support
code findings or provide data
on user experience among
different browsers and
applications.
Hybrid
(Preferred)
A method that combines the practices
performed in automated and manual
testing to verify accessibility standards
are met.
Incorporates user experience by
including people with disabilities within
the testing process who use AT to
validate results.
Provides the most comprehensive
customer and user experience of the
content.
• Process enables the most well-
rounded results.
• High dependency on
technology, high dependency of
human interaction.
• AT and tools are used in
conjunction with manual
inspection to validate the user
experience.
Note: AT is not a testing tool on its own and does not suffice in any testing methodology as an
interpretation of accessibility. Moreover, multiple ATs exist for different disabilities and no two
products provide an identical user experience.
