36 CFR Part 1194 - Proposed Information and Communication Technology (ICT) Standards and Guidelines NPRM - Preamble

B. WCAG 2.0 Incorporation by Reference

As noted above, the Board proposes in this NPRM to incorporate by reference WCAG 2.0. In the following sections, the Board discusses the rationale for, and certain issues related to, incorporation of this consensus standard.

1. Rationale for Incorporation by Reference

We have four principal reasons for incorporation by reference of WCAG 2.0. They are as follows:

First, our approach is consistent with that taken by other international standards organizations dealing with this issue. Standards developed in Australia, New Zealand, and Canada already directly reference WCAG 2.0. Moreover, WCAG 2.0 serves as the basis for Web accessibility standards in Germany (under “BITV 2”), France (under “RGAA 2.2.1”) and Japan (under “JIS X 83141”) and has so far generated eight formal authorized translations. In addition, the European Commission references WCAG 2.0 in EN 301 549.

Second, incorporation by reference of WCAG 2.0 is consistent with section 12(d) of the National Technology Transfer and Advancement Act of 1995 (15 U.S.C. 272 note), as well as Office of Management and Budget (OMB) Circular A-119, Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities (1998), which direct agencies to use voluntary consensus standards in lieu of government-unique standards except where inconsistent with law or otherwise impractical. See http://www.whitehouse.gov/omb/circulars_a119.⁴

Third, our approach is consistent with that being taken by another federal agency addressing a similar topic, namely the Department of Transportation’s recent final rule addressing, among other things, the accessibility of air carrier and ticket agent websites. See Nondiscrimination on the Basis of Disability in Air Travel, 78 FR 67882 (Nov. 12, 2013).

Fourth, incorporation of WCAG 2.0 directly serves the best interests of Americans with disabilities because it will help accelerate the spread of Web accessibility. The accessibility of the Web is essential to enable the participation of individuals with disabilities in today’s information society.

2. Justification for Applying WCAG 2.0 to Non-Web ICT

The Access Board is proposing to require not only Web content to conform to the Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0—an approach with which commenters to the 2010 and 2011 ANPRMs unanimously agreed—but also software and non-Web documents. Several commenters to the 2011 ANRPM were critical of this approach, and questioned the propriety of applying WCAG 2.0 to non-Web ICT. For the reasons noted below, the Board believes that applying WCAG 2.0 outside the web browser environment not only ensures greater accessibility for persons with disabilities, but also minimizes the incremental burden on regulated entities by simplifying compliance through incorporation of a technologically-neutral consensus standard.

Because WCAG 2.0 was written to be technology neutral, the language and phrasing of the Success Criteria can be applied to any technology found on the Web. Since most file types are found on the Web and much software is now Web-enabled, it is reasonable to utilize WCAG 2.0 to evaluate off-line documents and software interfaces with straightforward substitution of terms to address this new application. This approach has the potential to significantly simplify accessibility conformance and assessment.

We find support for our approach from two other sources, namely the European Commission’s Standardization Mandate M 376 (M376) of March 2012 and the World Wide Web Consortium’s WCAG2ICT Task Force (“Task Force”). The W3C formed the Task Force in June 2012 in part to address reservations, expressed by some of the commenters to our 2011 ANPRM, about applying the criteria for accessible Web content to off-line documents and software. W3C invited participation from subject-matter experts from around the world, including representatives of federal agencies and others who had concerns with our approach. The Task Force’s final consensus report provides guidance concerning application of WCAG 2.0 to non-Web ICT, specifically non-Web documents and software. See W3C Web Accessibility Initiative, WSC Working Group Note - Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (Sept. 5, 2013), available at http://www.w3.org/TR/wcag2ict/.

The Task Force analyzed each of the WCAG 2.0 Success Criteria to determine their suitability for application to non-Web content. There are thirty-eight Level A and Level AA Success Criteria in WCAG 2.0. The Task Force found that the majority of Success Criteria from WCAG 2.0 can be applied to non-Web documents and software with no, or only minimal, changes. Specifically, twenty-six Success Criteria do not include any Web-related terms and, therefore, can be applied directly as written and as described in the “Intent” sections of the most current version of “Understanding WCAG 2.0.” Thirteen of these twenty-six can be applied without any additional notes. The other thirteen also can be applied as written, but the Task Force provided additional informative notes in its report for the sake of clarity.

Of the remaining twelve Success Criteria, the Task Force found that eight of them can be applied as written when certain Web-specific terms or phrases like “Web page” are replaced with non-Web terms or phrases like “non-Web documents and software.” Additional notes are provided in the Task Force report to assist in the application of these Success Criteria to non-Web ICT. One example is Success Criterion 2.4.5 Multiple Ways. The Task Force noted that, when applied to the non-Web environment, this criterion requires that there be more than one way to locate a document (or software program) within a set of documents or programs. For mobile devices, this criterion could be satisfied by an operating system that makes files locatable by directory and search functions—features that are nearly ubiquitous among mobile operating systems in use today.

Another example is Success Criterion 3.2.3 Consistent Navigation. For this criterion, the Task Force noted that application to the non-Web environment would require consistency among navigational elements when such elements were repeated within sets of documents or software programs. To be conformant, navigational elements would be required to occur in the same relative order each time they are presented. It is unlikely that authors would provide navigation elements for a set of related documents and then present them differently from document to document, thereby defeating their purpose.

The Task Force’s report also notes that applying the success criteria in WCAG 2.0 to non-Web ICT with closed functionality proves problematic when a success criterion assumes the presence of assistive technologies, since closed functionality—by definition—does not allow attachment or use of assistive technology. This might occur, for example, when an eBook allows assistive technologies to access all of the user interface controls of the eBook program (open functionality), but does not allow such technologies to access the actual content of books (closed functionality). The Task Force identified 14 success criteria for which compliance might prove challenging for developers of ICT products with closed functionality. We propose to resolve this issue by exempting ICT with closed functionality from certain WCAG 2.0 Success Criteria, in conjunction with the addition of requirements specific to such products in Chapter 402, Closed Functionality.

By incorporating WCAG 2.0 by reference, the proposed standards would provide a single set of requirements for websites, documents, and software. WCAG 2.0 addresses new technologies and is responsive to the fact that the characteristics of products (e.g., native browser behavior and plug-ins and applets) have converged over time. Today, there are fewer distinctions among product categories, and some are outdated. For example, modern smartphones include: software applications and operating systems, Web-based intranet and Internet information and applications, and video and multimedia products. Additionally, smartphones are portable computers, telecommunications products, and self-contained closed products. New requirements in WCAG 2.0 also address gaps in the existing 508 Standards. Examples include: a requirement for a logical reading order, the ability to resize text, and the ability to turn off background audio that might interfere with comprehension and screen reading software.

3. Comparison of WCAG 2.0 to Existing 508 Standards

While the WCAG 2.0 Success Criteria build on the heritage of the existing 508 Standards, they are generally more explicit than the standards. Careful attention was given during their development to ensure that the Success Criteria are written as objectively testable requirements. In addition, unlike the existing 508 Standards, WCAG 2.0 is written in a technologically neutral fashion, which makes it directly applicable to a wide range of content types and formats.

For example, operability of ICT through keyboards (or alternate keyboard devices) is often critical to accessibility. Persons who are blind or who have limited vision often use screen readers to navigate Web pages using only the keyboard. Keyboard operability is also essential for many individuals with motor impairments who use alternate keyboards, or input devices that act as keyboard emulators when accessing ICT because they find mouse pointing to be cumbersome or impossible. Keyboard emulators include voice recognition software, sip-and-puff software, and on-screen keyboards. The existing 508 Standards envision keyboard operability from both software and Web-based information or applications, but such requirements were not necessarily explicit. Section 1194.21(a) expressly mandates that, when software is designed to run on a keyboard, all product functions must generally be executable through a keyboard. With respect to Web-based information and applications, the 508 Standards are not so explicit. At the time these standards were promulgated, Web pages created with HyperText Markup Language (HTML®) were always keyboard operable. Therefore, an express requirement for keyboard operability by Web pages was unnecessary. The existing 508 Standards expressly require keyboard operability for Web pages that require applets and plug-ins to interpret page content since keyboard operation in these contexts was not ubiquitous. See 36 CFR 1194.22(m). Collectively, the existing 508 Standards thus address keyboard operability both within and outside the Web environment, but do so in a variety of ways.

Over the years, however, Web technologies have become more complex. Use of keyboards is often secondary to mouse or touch-only interfaces. Success Criterion 2.1.1 requires all functionality to be operable through a keyboard interface. Section 1194.21(a) of the existing 508 Standards requires that “[w]hen software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.” This current wording is phrased as an input requirement based on output, and it leaves “discerned textually” as an undefined term. These are both flaws that may create accessibility gaps in application. For example, an operating system feature like “mouse keys” (where the keyboard cursor keys are used to steer the mouse pointer) satisfies this provision on its face, even though that feature is of no use to someone who cannot see the screen and relies on screen reading software. Success Criterion 2.1.1, on the other hand, while longer, only references input and uses no special jargon. This success criterion reads: “All functionality of the content [must be] operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.”

The Access Board has created a comprehensive table comparing WCAG 2.0 Level A and AA Success Criteria to the corresponding requirements in the existing 508 Standards. The table can be found on our website at www.access-board.gov/wcag2-508. In this table, the Board has identified WCAG 2.0 success criteria as either “substantially equivalent” or “new” relative to the existing 508 Standards. Identification of a WCAG 2.0 success criterion as “new” indicates that it has no corresponding provision in the existing 508 Standards; rather, it addresses a deficiency with the existing 508 Standards as identified by the developers of WCAG. In most cases, agencies with Section 508 compliance testing processes have adapted their procedures to address these accessibility concerns.

In sum, there are 38 WCAG 2.0 Level A and AA Success Criteria. After careful comparison of these success criteria to the existing 508 Standards, the Access Board deems 22 success criteria to be substantially equivalent in substance to our existing standards. The Board estimates that agencies with content that meets this group of existing 508 Standards will incur no or minimal costs by virtue of incorporation of WCAG 2.0 into our proposed rule. For the remaining 16 success criteria the Board deems to be new, it is anticipated that agencies would, to a greater or lesser extent (depending on the content and criteria at issue), incur some costs when implementing WCAG 2.0.

Question 6. The Board seeks comment on the extent that the proposed incorporation of WCAG 2.0 Level A and Level AA Success Criteria would result in new costs or benefits. We have characterized the majority of success criteria as “substantially equivalent” to requirements under the existing 508 Standards and 255 Guidelines and request comment as to the accuracy of this characterization.

4. Proposed Updates to Other Web-Specific Provisions in Existing 508 Standards

Along with the incorporation by reference of WCAG 2.0, the Board also proposes to update six provisions in the existing 508 Standards related to Web content to account for technological changes or their respective obsolescence. These six provisions for which the Board proposes deletion or replacement are as follows:

We propose to replace § 1194.21(g) of the existing 508 Standards, which prohibits applications from overriding user-selected contrast and color selections and other individual display attributes, with a new section 503.2 User Preferences. As with § 1194.21(g), this proposed provision requires applications to permit user preferences from platform settings for display settings. However, proposed 503.2 also provides an exception for applications—such as Web software—that are designed to be isolated from their operating systems. By design, Web applications (such as, for example, software used to create interactive multimedia content) are isolated from the operating system (i.e., “sand boxed”) for security reasons. An expectation that certain platform settings (e.g., font preferences) apply globally to all documents found on the Web is not practical.

We propose to delete § 1194.22(d) of the existing 508 Standards, which requires that Web documents be organized so they are readable without requiring an associated style sheet. Cascading style sheets (CSS) are now well supported by assistive technology and, consequently, this provision is unnecessary. For example, contemporary techniques using CSS to selectively hide irrelevant content from all users also selectively hides irrelevant content from users of assistive technology.

We propose to delete § 1194.22(k) of the existing 508 Standards, which permits text-only Web pages under certain circumstances, because incorporation of WCAG 2.0 success criteria renders this provision obsolete. While WCAG 2.0 does permit “conforming alternate versions,” text-only pages could not provide equivalent information or functionality for all but the most trivial Web content. The WCAG requirement for a conforming alternate version significantly exceeds the expectations for text only pages.

Question 7. A Web page can conform to WCAG 2.0 either by satisfying all success criteria under one of the levels of conformance or by providing a conforming alternate version. WCAG 2.0 always permits the use of conforming alternate versions. Are there any concerns that unrestricted use of conforming alternate versions of Web pages may lead to the unnecessary development of separate Web sites or unequal services for individuals with disabilities? Should the Board restrict the use of conforming alternate versions beyond the explicit requirements of WCAG 2.0? The Board requests that responses be provided in the context of the WCAG definition for conforming alternate versions (http://w3.org/TR/WCAG20/#conforming-alternate-versiondef). Commenters should review the guidance material as to why conforming alternate versions are permitted (http://w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-whypermit-head).

We propose to delete § 1194.22(l) of the existing 508 Standards, which applies when pages utilize scripting languages to display content or to create interface elements and requires the scripted information to be identified with functional text that can be read by assistive technology. Because WCAG 2.0 is technology neutral, inclusion of a separate provision applicable to scripting languages would be redundant; the same requirements that apply to HTML and other Web technologies also apply to scripting languages.

We propose to delete § 1194.22(m) of the existing 508 Standards, which applies when a Web page needs an applet, plug-in, or other application present on the client system to interpret page content and requires that such page provide a link to a plug-in or applet that complies with other referenced standards (in § 1194.21) relating to software applications. Because WCAG 2.0 applies directly to applets, plug-ins, and Web applications, § 1194.22(m) is redundant.

Lastly, the Board proposes to delete § 1194.24(e) of the existing 508 Standards, which requires that the non-permanent display or presentation of alternate text presentation or audio descriptions be user-selectable. Section 1194.24(e) essentially duplicates requirements for video and multimedia products already set forth in other provision in the same section (i.e., subsections (c) and (d)). The provision for user selectable closed captions and audio description restates existing practice, so it is unnecessary.