Section 508 Refresh: How WCAG Impacts Federal Website Accessibility Requirements

Section 508 and WCAG: What’s Changed for Federal Government Website Accessibility Requirements?

This article on Section 508 and WCAG 2.0 reprinted, with updates and modifications, from the February 2017 issue of Mealey’s™ Litigation Report: Cyber Tech & E-Commerce. It was originally published as “Making Technology Accessible To People With Disabilities: Section 508 Refresh Incorporates Internationally Recognized WCAG Standards.” Mealey’s is a subscription-based information provider and a division of LexisNexis. Copyright ©2017 by Hiram Kuykendall. Responses welcome.

Download the PDF.

U.S. Access Board Updates ICT Standards and Guidelines

On January 18, 2017, the United States Access Board, also known as the Architectural and Transportation Barriers Compliance Board, updated two acts related to making technology accessible to people with disabilities. The first modification is to the Electronic and Information Technology Accessibility Standards within Section 508 of the Rehabilitation Act of 1973. Section 508 stipulates requirements on how federally funded entities develop, procure, maintain, or otherwise use information technology. The second modification is to the Telecommunications Act Accessibility Guidelines within Section 255 of the Communications Act of 1934. This Act broadly applies to telecommunications products and services and to manufacturers of telecommunication equipment. Together, the updates to these Acts constitute updated Information and Communication Technology (ICT) Standards and Guidelines. Updates can be found in the 2 Federal Register, Volume 82, No. 11, Page 5790.

The impetus for the action was a desire to “refresh” the nearly 20-year-old, static accessibility standards within each act, adopting a more modern and internationally recognized standard. It was determined that the Web Content Accessibility Guidelines (WCAG) 2.0 was best suited to fulfill this requirement.

What follows is a summary of the Section 508 references to the WCAG. Section 255 falls under the purview of the Federal Communications Commission (FCC), which will subsequently publish regulations.

• Regulation: Section 508 of the Rehabilitation Act of 1973
• Affected: Federal Acquisition Regulatory Council (FAR Council), Federal agencies, entities with a monetary or contractual connection with Federal funds or programs
• Effective Date: March 20, 2017
• Compliance Begin Date: January 18, 2018

How Updated Section 508 Accessibility Standards Map to WCAG 2.0

Section 508 Revision Broadly Applies WCAG as Accessibility Standard

Section 508 has moved from gauging accessibility based on a rigid set of static rules to measuring accessibility compliance against the more principle-based Web Content Accessibility Guidelines (WCAG) 2.0 AA standard. While WCAG contains both rigid and principle-based criteria, it is widely believed this principle-based approach is flexible enough to cover existing and yet-to-be-developed technologies.

WCAG RIGID RULE EXAMPLE

WCAG Criterion 1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 (with exceptions).

The color of intended perceivable content must have sufficient contrast with the predominant background color to be perceivable by someone who is color blind or has low vision. For example, the body text of a document must have a 4.5:1 contrast with the background on which the text is printed or displayed. Since this rule can be mathematically evaluated, it is one of the easiest and most rigid of the WCAG rules and yields concrete pass/fail results.

WCAG PRINCIPLE EXAMPLE

WCAG Criterion 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)

In short, this criterion requires developers of applications, documents, videos, mobile applications, etc. to adhere to the standards associated with each. This covers two likely scenarios:

1. Robust Standards. First, it is assumed that any new technological development standard will have accessibility provisions that ensure that assistive technologies can perceive, parse and utilize the new product. This puts the burden of including accessibility at the standards governance level.
2. Graceful Enhancements. It is a fact that developers can create applications that do not follow the standards yet are perceivable and usable in current versions of assistive technologies such as screen readers. However, as assistive technologies, browsers, etc. better implement standards, it is possible and likely that the erroneous technique will fail at a future time. It is therefore an accessibility failure for a developer to implement code that does not strictly adhere to official guidelines of the technology. As an example, the Word Wide Web Consortium (W3C) publishes HTML standards and provides validators that detect incorrect web coding practices. It is therefore an accessibility failure not to adhere to the W3C HTML specifications when creating web pages, even if there is no immediate impact to accessibility.

Includes Exceptions for Non-Web Content and Software

Section 508 explicitly sets WCAG Level AA by reference as the base level of accessibility conformance with exceptions. This is a significant deviation from the previous version that explicitly outlined criteria within the act and further provides flexibility by referencing the WCAG standard as opposed to directly incorporating the principles into the act.

NON-WEB CONTENT

E205 Electronic Content: E205.4 Accessibility Standard. Electronic content shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).

EXCEPTION: Non-Web documents shall not be required to conform to the following four WCAG 2.0 Success Criteria: 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification.

As the name implies, the Web Content Accessibility Guidelines was originally intended to broadly cover web content. It is widely believed that the principles within the guidelines are flexible enough to cover non-web technologies such as documents (PDF, Microsoft Word) and non-web based software. After much deliberation, the refresh excludes the following from non-web technologies and asks the reader to replace “web page” with the term “document” or “software.” The language expressly states that the WCAG, with provisions, is appropriate and will be the governing standard for non-web ICT.

• WCAG Criterion 2.4.1 Bypass Blocks. Websites and web applications must provide a way to allow the user to jump over sections of repeating features or content. For example, a web page must allow the user to jump over the header section to the main content, bypassing menus and other sitewide features. Adding a skip link or “skip to main” link at the top of a web page to bypass these sitewide features and directly access the main content meets these criteria; however, there is no similar need in document or non-web technologies.
• WCAG Criterion 2.4.5 Multiple Ways. Websites must allow the user to have multiple ways to locate content within a site. Having a sitewide search feature or site map are two ways to meet these criteria. The recommended criteria to meet this requirement do not align well with non-web ICT and were believed to be unachievable.
• WCAG Criterion 3.2.3 Consistent Navigation. Users of assistive technology will learn the general layout of a website. Changing the layout, therefore, slows down the user and increases cognitive load. Non-web ICT is believed not to have such dramatic changes and is therefore exempt from this criterion.
• WCAG Criterion 3.2.4 Consistent Identification. Identical features should be consistent. For example, two submit buttons implementing the same action will fail accessibility checks if the labels are “go” in one instance and “find” in another.

SOFTWARE

E207 Software: E207.2 WCAG Conformance. User interface components, as well as the content of platforms and applications, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).

EXCEPTION: 1. Software that is assistive technology and that supports the accessibility services of the platform shall not be required to conform to E207.2

Making all aspects of the actual assistive technologies (screen reads, screen magnifiers, etc.) used to interact with ICT is not necessary. As such, an exception for the actual assistive technology tools was granted.

EXCEPTION: 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.

This is a similar provision to that found above in E205.4, Electronic Content, in that accessible non-web software also does necessarily have to conform to general web based structures.

EXCEPTION: 3. Non-Web software shall not be required to conform to Conformance Requirement 3 Complete Processes in WCAG 2.0.

Below is the referenced WCAG reference to complete process.

Conformance Requirements—3. Complete processes: When a Web page is one of a series of Web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all Web pages in the process conform at the specified level or better. (Conformance is not possible at a particular level if any page in the process does not conform at that level or better.)Example: An online store has a series of pages that are used to select and purchase products. All pages in the series from start to finish (checkout) conform in order for any page that is part of the process to conform.

Our “Accessibility in the News” feature links to to digital accessibility articles each week.
You may be interested in these issues linking to media coverage of government website accessibility happenings.

Scope Covers Public-Facing Content and Official Communications

The scope of Section 508 covers content, hardware, and software. While each section has specific guidelines, E205 Electronic Content specifically outlines all public-facing content plus nine types of agency official communication that must now comply with the WCAG guidelines. This includes web-based information dissemination as well as document-based.

E205.2 Public Facing. Electronic content that is public facing shall conform to the accessibility requirements specified in E205.4.E205.3 Agency Official Communication.

Electronic content that is not public facing shall conform to the accessibility requirements specified in E205.4 when such content constitutes official business and is communicated by an agency through one or more of the following:

1. An emergency notification;
2. An initial or final decision adjudicating an administrative claim or proceeding;
3. An internal or external program or policy announcement;
4. A notice of benefits, program eligibility, employment opportunity, or personnel action;
5. A formal acknowledgement of receipt;
6. A survey questionnaire;
7. A template or form;
8. Educational or training materials; or
9. Intranet content designed as a Web page.

EXCEPTION: Records maintained by the National Archives and Records Administration (NARA) pursuant to Federal recordkeeping statutes shall not be required to conform to the Revised 508 Standards unless public facing.

Includes “Safe Harbor” Items and Product Discontinuation Exceptions

E202 General Exceptions provides a “safe harbor” provision that allows the continued use of non-compliant ICT after the compliance begin date, January 18, 2018, provided there are no functional alterations. “Alteration” is defined as “a change to existing ICT that affects interoperability, the user interface, or access to information or data.” After the compliance date, updates may be made to non-compliant ICT; however, updates may require that an entire function be brought into compliance. The key is the scope of the individual functional changes. For example, a single word spelling correction on a non-compliant page could be updated and only the affected paragraph would need to meet the Section 508 criteria. The key is that each “functional” change is evaluated independently and acted upon accordingly.

Additional “Safe Harbor” Exceptions:

E202.3 National Security Systems. The Revised 508 Standards do not apply to ICT operated by agencies as part of a national security system, as defined by 40 U.S.C. 11103(a).

E202.4 Federal Contracts. ICT acquired by a contractor incidental to a contract shall not be required to conform to the Revised 508 Standards.

E202.5 ICT Functions Located in Maintenance or Monitoring Spaces. Where status indicators and operable parts for ICT functions are located in spaces that are frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment, such status indicators and operable parts shall not be required to conform to the Revised 508 Standards.E202.6 Undue Burden or Fundamental Alteration. Where an agency determines in accordance with E202.5 that conformance to requirements in the Revised 508 Standards would impose an undue burden or would result in a fundamental alteration in the nature of the ICT, conformance shall be required only to the extent that it does not impose an undue burden, or result in a fundamental alteration in the nature of the ICT.

E202.6.1 Basis for a Determination of Undue Burden. In determining whether conformance to requirements in the Revised 508 Standards would impose an undue burden on the agency, the agency shall consider the extent to which conformance would impose significant difficulty or expense considering the agency resources available to the program or component for which the ICT is to be procured, developed, maintained, or used.E202.6.2 Required Documentation. The responsible agency official shall document in writing the basis for determining that conformance to requirements in the Revised 508 Standards constitute an undue burden on the agency, or would result in a fundamental alteration in the nature of the ICT. The documentation shall include an explanation of why and to what extent compliance with applicable requirements would create an undue burden or result in a fundamental alteration in the nature of the ICT.E202.6.3 Alternative Means. Where conformance to one or more requirements in the Revised 508 Standards imposes an undue burden or a fundamental alteration in the nature of the ICT, the agency shall provide individuals with disabilities access to and use of information and data by an alternative means that meets identified needs.

E202.7 Best Meets. Where ICT conforming to one or more requirements in the Revised 508 Standards is not commercially available, the agency shall procure the ICT that best meets the Revised 508 Standards consistent with the agency’s business needs.

E202.7.1 Required Documentation. The responsible agency official shall document in writing: (a) The non-availability of conforming ICT, including a description of market research performed and which provisions cannot be met, and (b) the basis for determining that the ICT to be procured best meets the requirements in the Revised 508 Standards consistent with the agency’s business needs.E202.7.2 Alternative Means. Where ICT that fully conforms to the Revised 508 Standards is not commercially available, the agency shall provide individuals with disabilities access to and use of information and data by an alternative means that meets identified needs.

In addition to the “Safe Harbor” exceptions, C201.4 explicitly provides an exception allowing an organization to discontinue a product regardless of the net accessibility impact to the product line.

C201.4 Prohibited Reduction of Accessibility, Usability, and Compatibility. No change shall be undertaken that decreases, or has the effect of decreasing, the net accessibility, usability, or compatibility of telecommunications equipment or customer premises equipment.EXCEPTION: Discontinuation of a product shall not be prohibited.

Allows Conforming Alternate Versions

The WCAG acknowledges that occasionally, better experiences can be provided by creating alternate versions of the content or technology. The Access Board went on to cite three examples:

1. When an emerging technology is used on a web page, but the new technology cannot be designed in a way that allows assistive technologies to access all the information needed to present the content to the user (e.g., virtual reality or computer-simulated reality)
2. When it is not possible to modify some content on a web page because the website owner is legally prohibited from modifying the web content
3. To provide the best experience for users with certain types of disabilities by tailoring a web page specifically to accommodate those disabilities.

While these instances should be rare, the WCAG makes provisions for an event that

1. conforms at the designated level, and
2. provides all of the same information and functionality in the same human language, and
3. is as up to date as the non-conforming content, and
4. for which at least one of the following is true:
   1. the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism, or
   2. the non-conforming version can only be reached from the conforming version, or
   3. the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version

The WCAG standard also specifies that if the content on the primary page is updated, that automated or procedural mechanisms be in place to ensure the alternate version is kept in sync. Keeping alternate versions up-to-date has been a significant challenge and proved to be problematic.

Improves Definition of Assistive Needs Categories

Historically, the categories of assistive consideration were generically described as: Vision, Hearing, Mobility, and Cognitive. Section 302 Functional Performance Criteria rightly breaks the categories into more granular categories that better facilitate functionality, design, and testing considerations. It also notably adds Speech, which does not neatly fit into the original four categories.

VISION

302.1 Without Vision. Where a visual mode of operation is provided, ICT shall provide at least one mode of operation that does not require user vision.302.2 With Limited Vision. Where a visual mode of operation is provided, ICT shall provide at least one mode of operation that enables users to make use of limited vision.

302.3 Without Perception of Color. Where a visual mode of operation is provided, ICT shall provide at least one visual mode of operation that does not require user perception of color.

HEARING

302.4 Without Hearing. Where an audible mode of operation is provided, ICT shall provide at least one mode of operation that does not require user hearing.302.5 With Limited Hearing. Where an audible mode of operation is provided, ICT shall provide at least one mode of operation that enables users to make use of limited hearing.

SPEECH

302.6 Without Speech. Where speech is used for input, control, or operation, ICT shall provide at least one mode of operation that does not require user speech.

MOBILITY

302.7 With Limited Manipulation. Where a manual mode of operation is provided, ICT shall provide at least one mode of operation that does not require fine motor control or simultaneous manual operations.

302.8 With Limited Reach and Strength. Where a manual mode of operation is provided, ICT shall provide at least one mode of operation that is operable with limited reach and limited strength.

COGNITIVE

302.9 With Limited Language, Cognitive, and Learning Abilities. ICT shall provide features making its use by individuals with limited cognitive, language, and learning abilities simpler and easier.

Specifies That Authoring Tools Must Support Accessibility

Many content authoring tools prevent users from changing predetermined formatting and structural elements. This limitation can be imposed for a variety of reasons, including enforcing an organizational branding style guide or approved website layout. Section 504.2 explicitly disallows authoring tools from preventing a content editor from making changes required to make content perceivable.

504.2 Content Creation or Editing. Authoring tools shall provide a mode of operation to create or edit content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) for all supported features and, as applicable, to file formats supported by the authoring tool. Authoring tools shall permit authors the option of overriding information required for accessibility.

EXCEPTION: Authoring tools shall not be required to conform to 504.2 when used to directly edit plain text source code.

You may have noticed that recent versions of products such as Adobe Acrobat and Microsoft Office (Word, Outlook, PowerPoint, etc.) have incorporated accessibility checking features based on WCAG 2.0. This may have been in preparation for 504.3, which explicitly requires prompts as to WCAG 2.0 compliance.

504.3 Prompts. Authoring tools shall provide a mode of operation that prompts authors to create content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) for supported features and, as applicable, to file formats supported by the authoring tool.

And finally, Section 508 recognizes that content authors will likely follow the template or pattern presented to them. As such, provision 504.4 explicitly requires accessible starting templates as the first step toward creating accessible documents.

504.4 Templates. Where templates are provided, templates allowing content creation that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) shall be provided for a range of template uses for supported features and, as applicable, to file formats supported by the authoring tool.

Applies to Support Documentation

Support documentation and software frequently do not undergo the same level of scrutiny as the main product. 602.3 explicitly includes these support features and level of WCAG compliance.

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

A Note on Technical Specifications

There are many technical specifications such as Closed Functionality, Standard Connections, Operable Parts, etc. that are extensive and do not lend themselves easily to a WCAG summary. For instance, “Closed functionality” refers to ICT that has limited functionality by design or choice, which limits or prevents a user from adding assistive technology. There are many considerations, for example, related to providing accessibility for a copier display. These considerations can include attaching assistive technology, speech enablement technology, interface specifications, etc., which span different sections and interpretations of the WCAG.

Summary of Section 508 Revisions

The Section 508 refresh has moved the Act from a rigid set of technical guidelines to one based on principles and technical standards by referencing the WCAG 2.0 standard. The WCAG has further been broadly interpreted to cover content, web-based software and non-web-based software with noted exceptions. By citing the WCAG by reference, the revised Section 508 becomes a living document that will evolve as new and existing technologies become available. This inclusion is widely viewed as a welcome change and further establishes the WCAG as a recognized worldwide standard.

Additional Accessibility Information

For other Microassist commentary and curated news on accessibility in government, consider

• The Berkeley Web Accessibility Ruling
• VPATs and Section 508 Accessibility Compliance
• Accessible Web Design: Governments Tackle It, Businesses Pressed to Do the Same
• Blind Website Users Drive Online Accessibility; Federal Guidance at Risk

Microassist Accessibility Services

Outlining a host of accessibility-related services, Microassist Accessibility Services: Barrier-Free Digital Development, provides background on Microassist expertise and the various offerings available for digital content and platforms. Services cover accessible e-learning development, accessible website and application development, and audit and remediation services.

Related Posts

TASSCC 2024: Is Accessibility an Obligation or Opportunity?

What Do Technological Advances Like AI And Driverless Cars Mean For People With Disabilities?

With Paralympics Wrapping Up How Does The Rest Of The Sports World Shape Up When It Comes To Accessibility?