VPAT 2.X: The Evolution of the Accessibility Conformance Report | Part Three: Section 508

This post adapted from the article, “VPAT 2.X, The Evolution of the Accessibility Conformance Report,” originally published in the November 2019 issue of Mealey’s™ Litigation Report: Cyber Tech & E-Commerce. Mealey’s is a subscription-based information provider and a division of LexisNexis. This article has been updated to reflect the release of VPAT Version 2.4.  For an overview of the overall goals of the VPAT updates, refer to Part One of the series.  

VPAT 2.4: Section 508 Edition

The VPAT 2.3 508 Edition template is generally required by purchasers who fall under Section 508 of the U.S. Rehabilitation Act of 1973, as amended ((29 U.S.C. § 794 (d)) (Section 508).⁴   This primarily applies to federal agencies but can extend to other entities with contractual ties to the federal government. The 508 edition differs from the WCAG edition in the following areas:

Applicable Standards/Guidelines

The VPAT 2.4 Section 508 Edition has two accessibility guidelines, Web Content Accessibility Guidelines 2.0 and the Revised Section 508 standards published January 18, 2017 and corrected January 22, 2018.

Web Content Accessibility Guidelines 2.0

The Web Content Accessibility Guidelines 2.0 is the same as in the WCAG edition. The template does not allow for the Web Content Accessibility Guidelines 2.1 standard as Section 508 specifically points by reference to the 2.0 standard:

2. BROAD APPLICATION OF WEB CONTENT ACCESSIBILITY GUIDELINES 2.0

The Revised 508 Standards and 255 Guidelines incorporate by reference the Web Content Accessibility Guidelines (WCAG) 2.0, a globally-recognized and technologically-neutral set of accessibility guidelines for Web content.⁵

As WCAG 2.0 Level AA is mandated in legislation, you will note that the template comes pre-filled with both Level A and Level AA marked as ‘Yes.’ Vendors who cannot claim substantial WCAG 2.0 Level A/AA are ineligible to bid on most federal procurements.

Revised Section 508 standards published January 18, 2017 and corrected January 22, 2018

The revised Section 508 standards are mapped to the WCAG 2.0 Level A and Level AA standards where applicable. It should be noted that the WCAG is not sufficient to attest to all aspects of Information and Communication Technology as defined in legislation. As such, the VPAT 508 Edition has retained the Section 508 section that complements the WCAG success criteria. As such, the standards/guidelines section will also have the “Revised Section 508 standards published January 18, 2017 and corrected January 22, 2018” requirement marked to ‘Yes.’ As with the WCAG 2.0 Level A/AA requirement, vendors who do not substantially meet the revised Section 508 standards are ineligible to bid on most federal procurements.

This report covers the degree of conformance for the following accessibility standard/guidelines (Table 3)

Table 3. Example of Standards/Guideline Table from Section 508 Edition

Web Content Accessibility Guideline Success Criteria

The next major sections of the VPAT 2.3 508 Edition are the WCAG Success Criteria sections. Like the WCAG edition, the 508 editions contain the three success criteria levels:

• Table 1: Success Criteria, Level A
• Table 2: Success Criteria, Level AA
• Table 3: Success Criteria, Level AAA

Building on the WCAG Edition, the VPAT 2.3 508 Edition has extended the three columns to include references and requirements of Section 508.

Criteria:

The criteria column has been extended to include specific references back to associated Revised Section 508 requirements. The goal of including these specific references is to ensure the evaluator is aware that they are responsible for reporting on all aspects of the products which includes more than just the core tool.

• 501 (Web)(Software)⁶ – Web-based products that run in a browser must be reported on in this section. The “web software” is generally the core application. It should be noted that software products that run directly in the operating system have a special section, Chapter 5: Software, for documenting compliance; however, there is a provision in the Conformance Level that provides for conformance reporting. Chapter 5: Software will be covered in a subsequent section.Further complicating this section, the following requirements are exempt for non-web software:

2. Non-Web software shall not be required to conform to the following four Success Criteria in WCAG 2.0: 2.4.1 Bypass Blocks; 2.4.5 Multiple Ways; 3.2.3 Consistent Navigation; and 3.2.4 Consistent Identification.¹⁰

2.4.1 Bypass Blocks (Level A)

Also applies to:

Revised Section 508

• 501 (Web)(Software) – Does not apply to non-web software
• 2 (Authoring Tool)
• 3 (Support Docs) – Does not apply to non-web docs
• 2 (Authoring Tool)⁷ – Authoring tools are a special category of software that are used to create content and defined as:
  • Authoring Tool: any software, or collection of software components, that can be used by authors, alone or collaboratively, to create or modify content for use by others, including other authors.⁸

Examples include:

• Word processors
• Presentation creation tools
• Video editing tools
• Software used to develop software
• Web content management systems (CMS)
• Collaboration software
• Wikis, and
• Conferencing/meeting software with an authoring tool in its feature set.

• 3 (Support Docs) – Historically, vendors have neglected to evaluate supporting product documentation for accessibility. This can include manuals, study guides, training, et cetera. In an effort to ensure vendors are aware of the requirement to make the entire product accessible, the criterial column explicitly mentions Support Docs.602.3 Electronic Support Documentation. Documentation in electronic format, including Web-based self-service support, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).⁹

As with the software category, Supporting Docs contains WCAG exceptions.

2. Non-Web software shall not be required to conform to the following four Success Criteria in WCAG 2.0: 2.4.1 Bypass Blocks; 2.4.5 Multiple Ways; 3.2.3 Consistent Navigation; and 3.2.4 Consistent Identification.¹⁰

2.4.1 Bypass Blocks (Level A)

Also applies to:

Revised Section 508

• 501 (Web)(Software) – Does not apply to non-web software
• 2 (Authoring Tool)
• 3 (Support Docs) – Does not apply to non-web docs

Conformance Level

To a degree, the Conformance Level reiterates the requirements in the Criteria column. Vendors are asked to provide conformance levels for each possible product component: Supports, Partially Supports, Does Not Support, Not Applicable, Not Evaluated

• Web – Aligns with 501 (Web). Once again, this is the primary web-based application.
• Electronic Docs – Aligns with 504.2 (Authoring Tool).
• Software – Aligns with 501 (Software). As previously stated, software refers to applications that run directly in the operating system and are independent of a web browser.
• Authoring Tool – Aligns with 504.2 (Authoring Tool)

Remarks and Explanations

As mentioned in the VPAT WCAG Edition, the Remarks and Explanation section is where the evaluator can affirm the Supports declaration, document the degree to which a Success Criteria fails for Partially Supports / Does Not Support and can optionally provide alternative methods of access (accommodations). Table 4 shows an example.

The Section 508 Edition takes the Remarks and Explanations section one step further by providing the evaluator the ability to comment on each of the associated Conformance Levels:

• Web:
• Electronic Docs:
• Software:
• Authoring Tool:

Table 4. Success Criteria Table from Section 508 Edition

Chapter 3: Functional Performance Criteria (FPC)

Chapter 3 Functional Performance Criteria (FPC)¹¹ section (Table 5) exists for the documentation of accessibility features that fall outside of the other sections within the VPAT. To clarify, the outcome-based provisions shown in Table 5 apply when applicable technical requirements (i.e., Chapters 4 and 5) do not address one or more features of the product or service, technology standards/guidelines do not exist, or the technical standard cannot be met.

301 General

301.1 Scope. The requirements of Chapter 3 shall apply to ICT where required by 508 Chapter 2 (Scoping Requirements), 255 Chapter 2 (Scoping Requirements), and where otherwise referenced in any other chapter of the Revised 508 Standards or Revised 255 Guidelines.

As an example, C101.2 Equivalent Facilitation specifically states that Chapter 3 is to be used to document alternative designs or technology that result in substantially equivalent or greater accessibility:

E101.2 Equivalent Facilitation. The use of an alternative design or technology that results in substantially equivalent or greater accessibility and usability by individuals with disabilities than would be provided by conformance to one or more of the requirements in Chapters 4 and 5 of the Revised 508 Standards is permitted. The functional performance criteria in Chapter 3 shall be used to determine whether substantially equivalent or greater accessibility and usability is provided to individuals with disabilities.

Table 5. Example of Chapter 3: Functional Performance Criteria (FPC)¹¹ Table – VPAT 2.3 Section 508 Edition

Chapter 4: Hardware

The Web Content Accessibility Guidelines were never designed to address hardware. As the name implies, the focus of the WCAG has always been web content and has extended over time to include web techniques that promote an accessible experience. As such, the VPAT 508 Edition has explicitly included a hardware section (Table 6).

Table 6. Example Chapter 4 – Hardware¹² Table of VPAT 2.3: Section 508 Edition
Notes:

Chapter 5: Software

Chapter 5: Software¹³ allows for the attestation of non-web software. It complements the previously mentioned Table 1: Success Criteria, Level A, and Table 2: Success Criteria, Level AA. This section exists primarily to ensure proper testing. Web-based applications have the advantage of leveraging the accessibility layers of the browser. This gives them an inherent advantage when coding for accessibility. Applications that exist within the operating system (OS) have to instantiate their own connections to the accessibility layers. As such, the Section 508 edition requires an additional attestation to ensure that OS-based application is perceivable and usable by people reliant on assistive technologies.

Chapter 6: Support Documentation and Services

And finally, Chapter 6: Support Documentation and Services¹⁴ explicitly extends the WCAG Success Criteria and asks the evaluator to attest to both 602 Support Documentation¹⁵ and 603¹⁶ Support Services.

602 Support Documentation

This section attempts to ensure that all documentation is accessible and attempts to provide reasonable accommodations for documents that are not compliant.

602.1 General. Documentation that supports the use of ICT shall conform to 602.

602.2 Accessibility and Compatibility Features. Documentation shall list and explain how to use the accessibility and compatibility features required by Chapters 4 and 5. Documentation shall include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.

602.3 Electronic Support Documentation. Documentation in electronic format, including Web-based self-service support, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).

602.4 Alternate Formats for Non-Electronic Support Documentation. Where support documentation is only provided in non-electronic formats, alternate formats usable by individuals with disabilities shall be provided upon request.

603 Support Services

This section attempts to categorize services that are frequently omitted but are essential for product’s operations. As indicated in the guidelines below, operations such as help desks, call centers, and points of contact are frequently inaccessible to a wide range of disabilities.

603.1 General. ICT support services including, but not limited to, help desks, call centers, training services, and automated self-service technical support, shall conform to 603.

603.2 Information on Accessibility and Compatibility Features. ICT support services shall include information on the accessibility and compatibility features required by 602.2.

603.3 Accommodation of Communication Needs. Support services shall be provided directly to the user or through a referral to a point of contact. Such ICT support services shall accommodate the communication needs of individuals with disabilities.

Note: Download the full article for tables and examples of variations across each VPAT version (Accessible PDF format).
Read next: In the series final installment, Hiram outlines the elements of the VPAT 2.3 EU and VPAT 2.3 INT versions.

About the author

Hiram Kuykendall, Chief Technology Officer is the chief technology officer for Microassist, an Austin, Texas-based learning, development, and accessibility consulting firm. He has more than 22 years of experience in custom application development and over 12 years of accessibility remediation for custom application development, eLearning, and instructor-led training. In addition, Hiram advocates through public speaking and volunteer work specifically focused on the technical aspects of web accessibility. Hiram can be reached at [email protected].

Learn more about Accessibility Solutions

VPAT Evaluation and Authoring Services: The Voluntary Product Accessibility Template®, or VPAT®, is a tool provided by the accessibility policy and standard organization, ITI. The VPAT is used to document how well a product conforms with Section 508 accessibility standards. Many federal, state, and local government and institutions of higher education use or are required to use a VPAT to assess commercial IT products and services with features that support accessibility.

Recommended articles

VPAT 2.X, The Evolution of the Accessibility Conformance Report | Part One: An Overview

Revisit part one of this series on recent updates to the VPAT® process, including an overview of the consistent elements across the multiple versions used globally.

“Website Accessibility: The Legal Landscape” from The Banking Law Journal

An in-depth look at key legal cases and website accessibility litigation decisions, the reasoning behind each decision among the different courts, an introduction to website accessibility standards, and a checklist for litigation-wary organizations who want to minimize their risk. (Co-authored by Hiram Kuykendall, with Paul Trahan and Nathan Damweber, attorneys at Norton Rose Fulbright US LLP)

Related Posts

What Could The Results Of The November Election Mean For People With Disabilities?

As Election Year Progresses What Does Voting Accessibility Look Like For November?

What Does New Presidential Administration Mean For People With Disabilities?