Attachment 10 - Acquisition Guidance on the Voluntary Product Accessibility Template (VPAT).pdf

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)

HHS OS Accessibility Program 508HelpDesk@HHS.gov Revised August 2021

➔ 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)

HHS OS Accessibility Program 508HelpDesk@HHS.gov Revised August 2021

➔ 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.