The five major issues addressed in this NPRM are: (a) scope of covered electronic content; (b) incorporation by reference of WCAG 2.0; (c) relationship between functional performance criteria and technical requirements; (d) coverage of real-time text; and (e) interoperability requirements for assistive technology. Each of these areas is discussed below.

A. Electronic Content

In this NPRM, the Board aims to bring needed clarity to the scope of electronic content subject to accessibility requirements in the 508 Standards. Based on the language of the Rehabilitation Act, § 1194.1 of the existing standards speaks of federal agencies ensuring that federal employees and members of the public with disabilities have comparable “access to and the use of [electronic] information and data.” Given its breadth, federal agencies have—not altogether surprisingly—had difficulty applying this mandate. The existing requirement does not adequately address what is meant by comparable access to information and data. Consequently, there has been confusion over whether and how such electronic content must be made accessible. Agencies have been reluctant to apply the existing 508 Standards to electronic information and data, except for Web pages.

The proposed rule would address these deficiencies in the existing 508 Standards by clearly delineating the scope of covered electronic content, as well as specifying concrete, testable, technical requirements to ensure the accessibility of such content. The Board proposes that all covered electronic content would be required to conform to WCAG 2.0 Level A and Level AA Success Criteria and Conformance Requirements specified for Web pages or, where applicable, ISO 14289-1 (PDF/UA-1).

Covered electronic content would, under the proposed rule, include two discrete groups of content. First, the Board proposes in E205.2 that all public-facing content—which encompasses electronic information and data made available by agencies to members of the general public—must satisfy applicable accessibility requirements in the proposed rule (i.e., WCAG 2.0 Level A and Level AA Success Criteria or PDF/UA-1). This would include, for example, agency websites (and documents posted thereon), blog posts, and social media sites. Coverage of this broad category of agency-sponsored content is important because persons with disabilities should have equal access to electronic information and data made available to the public generally. This is an essential right established by the Rehabilitation Act.3

The central principle underlying the accessibility requirement for public-facing content is the notion that federal agencies must ensure equal access to electronic information that they themselves directly make available to the general public by posting on a public fora. So, for example, if a federal agency posts a PDF version of a recent settlement agreement on its website as part of a press release, that document would need to comply with PDF/UA-1. Or, if an agency posts a video created by an advocacy organization on the agency’s website (or, alternatively, on a social media site hosted by a third party), the agency would also be required to ensure that that electronic information complied with accessibility requirements in proposed E205.2 for public-facing content. On the other hand, if a federal agency is the plaintiff in a lawsuit and serves an electronic version of a legal brief on a corporate defendant, the agency’s legal brief would not be considered public-facing content even if the corporation subsequently posts a copy of the agency’s document on its own website.

Second, with respect to electronic content that is not public facing, the Board aims to limit the scope of covered content to eight discrete categories of agency official communications that are most likely to affect a significant number of federal employees or the general public. Proposed E205.3 would require an agency’s non-public facing electronic content to meet the accessibility requirements in the proposed rule (i.e., WCAG 2.0 Level A and Level AA Success Criteria or PDF/UA-1) when such content (a) constitutes agency official business, and (b) falls within one or more of eight categories of communication. Coverage would extend to all forms of content constituting official communications by agencies, including Web pages, postings on social media, emails, and electronic documents. The Board believes that this approach strikes an appropriate balance in ensuring the accessibility of essential electronic content for persons with disabilities, while also tempering agency compliance obligations. This approach also compliments the requirements of sections 501 and 504 of the Rehabilitation Act, which require agencies to provide reasonable accommodations as necessary to address the disability-related needs of employees and the public respectively.

Specifically, proposed E205.3 sets forth the following eight categories of non-public facing agency official communications that must satisfy the accessibility requirements in the proposed 508 Standards: (1) emergency notifications (e.g., an evacuation announcement in response to fires or other emergencies); (2) initial or final decisions adjudicating administrative claims or proceedings; (3) internal or external program or policy announcements (i.e., information promulgated by an agency relating to programs it offers or policy areas it deals with); (4) notices of benefits, program eligibility, employment opportunities or personnel actions; (5) formal acknowledgements or receipts (i.e., official replies by an agency that recognize the receipt of a communication); (6) questionnaires or surveys; (7) templates or forms; and (8) educational or training materials.

By limiting the scope of covered electronic content to these proposed eight categories of official communications, the Board intends to encourage agencies to do more to ensure that individuals with disabilities have comparable access to, and use of, electronic information and data. The Board does not intend this proposed approach to disturb or override the independent legal obligations of agencies—whether arising under sections 501 or 504 of the Rehabilitation Act or other statutes—to provide accessible communications as a reasonable accommodation or other required accommodations. For example, draft electronic documents exchanged by federal employees as part of an agency working group would not be covered by proposed E205.3, but might still be required to be accessible by Section 501 when needed by a federal employee with a disability to perform his or her job.

Question 4. Are the eight proposed categories of non-public facing content sufficiently clear? Do they ensure a sufficient level of accessibility without imposing an unnecessary burden on agencies? If not, the Board encourages commenters to suggest revisions to these categories that would improve clarity or strike a more appropriate balance.

Notably absent from the proposed eight categories of non-public facing content is a type of content—namely, content “broadly disseminated throughout an agency”—that was included in the 2011 ANPRM. Several federal agencies and other commenters found this language to be vague and overbroad, and called for its revision or withdrawal. The Board acknowledges that the “broadly disseminated” category could, in practice, prove challenging to apply and lead to inconsistent implementation across agencies that the proposed 508 Standards are designed to address. Accordingly, the Board has not included “broadly disseminated” content as a category in the proposed rule. The Board nonetheless welcomes comment on this issue, and may include a “widely disseminated”-style category in the final rule should there prove to be a workable definition or metric to assess compliance.

Question 5. Should a category for “widely disseminated” electronic content be included among the categories of non-public facing official communications by agencies that must meet the accessibility requirements in the 508 Standards? Why or why not? If such a category were to be included in the final rule, what metrics might be used to determine whether a communication is broadly disseminated throughout an agency?

Lastly, with respect to exceptions, the Board proposes in this NPRM an exception in E205.3 for non-public facing records maintained by the National Archives and Records Administration (NARA) for archival purposes under federal recordkeeping requirements. As proposed, such content—even if otherwise meeting the conditions in proposed E205.3 for electronic content that must be made accessible (i.e., non-public facing agency official communications that fall within one or more of the eight enumerated categories)—would not be required to comply with the proposed 508 Standards so long as it remained non-public facing. The Board anticipates that the only content covered by this exception would be non-public facing archival materials administered or maintained by NARA in compliance with federal recordkeeping requirements, such as the Federal Records Act (codified at 44 U.S.C. Chapters 21, 29 and 33). It bears noting that NARA is not generally responsible for remediating inaccessible materials submitted to NARA by other agencies unless such materials are made publicly available by, for example, being posted on NARA’s website.

Though the 2011 ANPRM included an express exception for draft materials, no such exception is included in either proposed E205.2 (Public Facing) or E205.3 (Agency Official Communications) for two main reasons. First, public-facing content—such as that covered by proposed E205.2—should be equally accessible to all members of the public regardless of whether it is in draft or final form. For example, a draft policy published for comment on an agency website should be accessible so that all affected individuals may provide feedback. Secondly, drafts, by their very nature, would typically fall outside the scope of the eight categories of content constituting agency official communications subject to proposed E205.3. Only final electronic documents that are ready for distribution would qualify as the type of content identified in proposed categories 1 through 8 of this provision. For example, a draft memorandum by an agency component announcing a new telework policy would not constitute a “policy announcement” (Category 3) subject to proposed E205.3 until it is finalized and ready to be transmitted to its intended audience of component employees.

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

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.

C. Functional Performance Criteria

The functional performance criteria are outcome-based provisions that address barriers to using ICT by individuals with certain disabilities, such as those related to vision, hearing, color blindness, speech, and manual dexterity. Both the existing 508 Standards and 255 Guidelines provide functional performance criteria. However, the existing 508 Standards do not expressly define the relationship between its functional performance criteria and technical requirements. To address this gap, the Board proposes to clarify when application of the functional performance criteria in the 508 Standards is required. (We are not proposing to change the application of the functional performance criteria in the 255 Guidelines.) The Board also proposes, in this NPRM, to update several functional performance criteria in Chapter 3 to refine some criteria and to make editorial changes necessitated by revisions elsewhere in the proposed rule.

1. Application of Functional Performance Criteria: 508 Standards

Section 1194.31 of the existing 508 Standards, which sets forth six specific functional performance criteria, does not specify when federal agencies and other covered entities should or must apply these criteria. As described in the preamble to the final rule for the existing standards:

This section [1194.31] provides functional performance criteria for overall product evaluation and for technologies or components for which there is no specific requirement under other sections. These criteria are also intended to ensure that the individual accessible components work together to create an accessible product. (65 FR 80519 (Dec. 21, 2000))

Over the ensuing years, some have raised questions about application of the functional performance criteria in the existing 508 Standards. The General Services Administration’s IT Accessibility and Workforce (GSA/ITAW)—which is the federal government’s principal coordinator for Section 508 implementation—provides the following information in a “Q &A” format concerning application of the functional performance criteria:

How should an agency proceed in identifying “applicable" technical provisions in Subparts B [technical provisions], C [functional performance criteria], and D [information, documentation, and support] of the Access Board’s standards to ensure acquired products provide comparable access?

Agencies should first look to the provisions in Subpart B [technical provisions] to determine if there are specific technical provisions that apply to the [ICT] need they are seeking to satisfy.

If there are applicable provisions in Subpart B [technical provisions] that fully address the product or service being procured, then the agency need not look to Subpart C [functional performance criteria]. Acquired products that meet the specific technical provisions set forth in Subpart B [technical provisions] will also meet the broader functional performance criteria in Subpart C [functional performance criteria].

If an agency’s procurement needs are not fully addressed by Subpart B [technical provisions], then the agency must look to Subpart C [functional performance criteria] for applicable functional performance requirements.5

The GSA/ITAW’s Q&A document also suggests that the functional performance criteria in the existing 508 Standards be used to evaluate ICT products for equivalent facilitation. Id.

As recounted previously, the Board’s approach to specifying requirements for application of the functional performance criteria has evolved over the course of this rulemaking. The Advisory Committee recommended that the Board clarify the relationship between the functional performance criteria and the technical provisions in the 508 Standards, but did not reach consensus on how to address this issue. In the 2010 ANPRM, the Board proposed to use the approach suggested in the GSA/ITAW’s Q&A document—namely, that agencies first look to the technical provisions in the 508 Standards to determine whether there were specific provisions that applied to the ICT being procured. If there were technical provisions that fully addressed the ICT being procured, then the agency would not need to apply the functional performance criteria. Application of the functional performance criteria would thus only be required under the following two circumstances: when the agency’s procurement needs were not fully addressed by technical provisions in the 508 Standards, or when evaluating ICT for equivalent facilitation. This proposal was intended to reflect current agency practice.

Concerns expressed by commenters led the Board to propose redefining the relationship between the functional performance criteria and the technical provisions in the 508 Standards. In the 2011 ANPRM, the Board proposed that ICT would be required to conform to the functional performance criteria, even when the technical provisions were met. This proposal, too, received mixed reviews from commenters. While some commenters supported this approach, industry groups objected to it as unworkable. They viewed the functional performance criteria as overly subjective and not subject to objective testing. As one commenter from the IT industry noted: “[A] supplier cannot guarantee that the functional performance criteria have been met unless the supplier controls all the components of the end-to-end solution.”

In this NPRM, the Board heeds the concerns of industry groups and effectively returns to our original proposal whereby the functional performance criteria in the 508 Standards apply only in two specific circumstances—when there are “gaps” in the technical requirements and when evaluating equivalent facilitation. Specifically, agencies would be required to apply the functional criteria as follows. First, where the proposed requirements in Chapter 4 for hardware and Chapter 5 for software do not address one or more of the features of ICT, sections E204.1 and C202.1 would require the features that are not addressed in those chapters to conform to the functional performance criteria in Chapter 3. This is consistent with the GSA/ITAW’s recommended approach under the existing 508 Standards. It is also consistent with §§ 1193.21 and 1193.41 of the existing 255 Guidelines. Second, section E101.2 proposes to require the functional performance criteria to be used when evaluating ICT for equivalent facilitation. This is consistent with the GSA/ITAW’s recommended approach under the existing 508 Standards.

With respect to the 255 Guidelines, neither the Advisory Committee (in its TEITAC Report) nor the Board (in the 2010 and 2011 ANPRMs) previously proposed any changes to the manner in which telecommunications equipment manufacturers must apply the functional performance criteria. Likewise, the Board proposes no changes in this NPRM. See Section VI.D (Section-by-Section Analysis – Functional Performance Criteria and Technical Requirements - C201.3 and C202).

2. Updates to Functional Performance Criteria: 508 Standards and 255 Guidelines

As noted above, the Board is also proposing in this NPRM to update several functional performance criteria in Chapter 3 (located in Appendix C – Technical Requirements)—which applies to both the 508 Standards and the 255 Guidelines—by refining some criteria and making editorial changes necessitated by revisions elsewhere in the proposed rule. We highlight below several of the principle revisions to the functional performance criteria proposed in this NPRM. In addition, Table 3, which follows at the end of this section, provides a detailed comparison of the functional performance criteria in the existing 508 Standards (§ 1194.31), 255 Guidelines (1193.41), and the proposed rule (section 302).

First, while the functional performance criteria in proposed 302 no longer reference assistive technology, this amounts to an editorial change only. The existing 508 Standards and 255 Guidelines allow certain functional performance criteria to be satisfied either directly or indirectly through support for assistive technology. (See, e.g., existing 508 Standards §§ 1194.31(a) – (e)). The functional performance criteria in the proposed rule do not provide for compliance through support for assistive technology because other proposed revisions to the 508 Standards (E203.1) and 255 Guidelines (C201.3) would impose a general requirement that agencies and telecommunications equipment manufacturers respectively ensure that all functionality of ICT is accessible to and usable by individuals with disabilities, either directly or by supporting the use of assistive technology.

Second, as discussed in Section IV.E.6, the Board proposes to revise the criteria for users with limited vision in section 302.2. The existing 508 Standards require at least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 to be provided in audio and enlarged print output working together or independently. The existing 255 Guidelines are similar, except that they define users with limited vision as users possessing visual acuity that ranges between 20/70 and 20/200. The proposed rule would require at least one mode of operation that magnifies, one mode that reduces the field of vision required, and one mode that allows user control of contrast where a visual mode of operation is provided. The proposed rule does not refer to visual acuity since comments in response to proposals in the 2010 and 2011 ANPRMs recommended that the criteria should address features that would improve accessibility for users with limited vision instead of using visual acuity as a measure of limited vision.

Third, there are two functional performance provisions in the existing 255 Guidelines that are not found in the functional performance criteria for existing 508 Standards: operations without time-dependent controls (255 Guidelines § 1193.41(g)) and operations with limited cognitive skills (255 Guidelines §1193.41(i)). There is a technical provision in the existing 508 Standards that corresponds to 255 Guidelines § 1193.41(g) requiring the operation of ICT without time-dependent controls (508 Standards §1194.22(p)). This is addressed in the proposed rule in WCAG 2.0 Success Criteria 2.2.1 Timing Adjustable and 2.2.2 Pause, Stop and Hide. We propose to incorporate by reference WCAG 2.0 Success Criteria in proposed E207.2 and C205.2.

Fourth, the Board proposes not to include a functional performance criteria relating to limited cognitive skills. The existing 255 Guidelines provide a criterion for at least one mode of operation that minimizes cognitive skills required of the user (§ 1193.41(i)), while the existing 508 Standards have no parallel provision. Such a criterion has not been included in the proposed rule on the advice of the Advisory Committee, which recommended deletion of this criteria pending future research. (See Section VI.C (Section-by-Section Analysis - Application and Scoping).

Table 3 below provides a provision-by-provision summary of how the proposed rule would revise the existing functional performance criteria by comparing the criteria in proposed 302 (in the left-hand column of the table) to its counterparts in existing 508 Standards § 1194.31 (in the middle column of the table) and existing 255 Guidelines §1193.41 (in the right-hand column of the table).

Table 3 - Comparison of the Functional Performance Criteria in the NPRM and Existing 508 Standards and 255 Guidelines
Proposed Sections E207.2 and C205.2 (incorporating WCAG 2.0 by reference) and 302Existing 508 StandardsExisting 255 Guidelines
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.

§ 1194.31 (a) At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who or blind or visually impaired shall be provided.

§ 1193.41 (a) Operable without vision. Provide at least one mode 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 magnifies, one mode that that reduces the field of vision required, and one mode that allows user control of contrast. § 1194.31 (b) At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 shall be provided in audio and enlarged print output working together or independently, or support for assistive technology used by people who or visually impaired shall be provided § 1193.41 (b) Operable with low vision and limited or no hearing. Provide at least one mode that permits operation by users with visual acuity between 20/70 and 20/200, without relying on audio output.
302.3 Without Perception of Color. Where a visual mode of operation is provided, ICT shall provide at least one mode of operation that does not require user perception of color. No criteria for users without perception of color. § 1193.41 (c) Operable with little or no color perception. Provide at least one mode that does not require user color perception.
302.4 Without Hearing. Where an auditory mode of operation is provided, ICT shall provide at least one mode of operation that does not require user hearing. § 1194.31 (c) At least one mode of operation and information retrieval that does not require user hearing shall be provided, or support for assistive technology used by people who are deaf or hard of hearing shall be provided. § 1193.41 (d) Operable without hearing. Provide at least one mode that does not require user auditory perception.
302.5 With Limited Hearing. Where an auditory mode of operation is provided, ICT shall provide at least one mode of operation that improves clarity, one mode that reduces background noise, and one mode that allows user control of volume. § 1194.31 (d) Where audio information is important for the use of a product, at least one mode of operation and information retrieval shall be provided in an enhanced auditory fashion, or support for assistive hearing devices shall be provided. Operable with low vision and limited or no hearing. Provide at least one mode that permits operation by users with visual acuity between 20/70 and 20/200, without relying on audio output.
302.6 Without Speech. Where a spoken mode of operation is provided, ICT shall provide at least one mode of operation that does not require user speech. § 1194.31 (e) At least one mode of operation and information retrieval that does not require user speech shall be provided, or support for assistive technology used by people with disabilities shall be provided. § 1193.41 (h) Operable without speech. Provide at least one mode that does not require user speech.
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 operation of more than one control at the same time. § 1194.31 (f) At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength shall be provided. § 1193.41 (e) Operable with limited manual dexterity. Provide at least one mode that does not require user fine motor control or simultaneous actions.
302.8 With Limited Reach or 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. § 1193.41 (f) Operable with limited reach and strength. Provide at least one mode that is operable with user limited reach and strength.
WCAG 2.2.1 Timing Adjustable: For each time limit that is set by the content, at least one of the following is true: (Level A)
  • Turn off: The user is allowed to turn off the time limit before encountering it; or
  • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and the user is allowed to extend the time limit at least ten times; or
  • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  • 20 Hour Exception: The time limit is longer than 20 hours.
§ 1194.22 (p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. § 1193.41 (g) Operable without time-dependent controls. Provide at least one mode that does not require a response time. Alternatively, a response time may be required if it can be by-passed or adjusted by the user over a wide range.
WCAG 2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true: (Level A)
  • Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
  • Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
§ 1194.22 (h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user. § 1193.43 (c) Access to moving text. Provide moving text in at least one static presentation mode at the option of the user.
No corresponding provisions. No corresponding provisions. § 1193.41 (i) Operable with limited cognitive skills. Provide at least one mode that minimizes the cognitive, memory, language, and learning skills required of the user.

D. Real-Time Text

In this NPRM, the Board proposes to require that ICT support RTT functionality whenever such ICT also provides real-time, two-way voice communication. This proposal represents a significant shift in approach for both the 508 Standards and the 255 Guidelines to better align with current technology. The existing 508 Standards and 255 Guidelines were published over a decade ago. At the time, TTYs were the most commonly available text-based system for communicating within a voice communication system. Since then, technology has greatly advanced. There are now, in addition to TTYs, multiple text-based means of communication available in the marketplace. This proposed revision will update the standards to reflect changes in telecommunications technology.

Section 410.6 of the proposed rule would require ICT with real-time voice communication features to also support communication through real-time text. Such ICT would be required to support RTT either within its own closed system or outside a network. For example, a closed communication system, such as within a federal agency, would be required to interoperate with either the publicly switched telephone network (PSTN) or Voice over Internet Protocol (VoIP) products or systems to support the transmission of real-time text. When ICT interoperates with VoIP products or systems using Session Initiation Protocol (SIP), the Board proposes to require the transmission of real-time text to conform to the Internet Engineering Task Force’s RFC 4103 standard for RTP Payload for Text Conversation. Where ICT interoperates with the PSTN, real-time text would be required to conform to the Telecommunications Industry Association’s TIA 825-A standard for TTY signals at the PSTN interface (also known as Baudot). RFC 4103 and TIA 825-A are final standards proposed for incorporation by reference in 508 Chapter 1 and 255 Chapter 1 (see sections E102 and C102, respectively).

Commenters to the 2011 ANPRM noted that other standards aside from RFC 4103—such as XMPP and XEP-0301—were currently in use and could be referenced as specifications for ICT interoperability with VoIP using SIP. XEP-0301 is one of several pending standards developed for use in the Extensible Messaging and Presence Protocol (XMPP). XMPP is a set of open technologies for instant messaging, multi-party chat, voice and video calls, collaboration, and generalized routing of XML data. XMPP was originally developed in the Jabber open-source community to provide an open, secure, spam-free, decentralized alternative to closed instant messaging services. XMPP differs from SIP, which is an application layer protocol used to establish, modify, and terminate multimedia sessions such as VoIP calls. Currently, both the XMPP and the SIP protocol are used in the marketplace. At this time, however, only the standard supporting the transmission of RTT over SIP (RFC 4103) is final. The standard supporting RTT over XMPP (XEP-0301) is not yet finalized.

XEP-0301, In-Band Real-time Text, is a specification for real-time text transmitted in-band over an XMPP network. It is used for text messaging. As of the date of this publication, according to the XMPP Standards Foundation, the XEP-0301 standard is under review and not yet final. XEP-0301 has many advantages: it allows transmission of real-time text with minimal delays; it supports message editing in real-time; and, it has reliable real-time text delivery. It can be used for multiple users and allows alternate optional presentations of real-time text, including split screen or other layouts. The standard also allows use within gateways to interoperate with other real-time text protocols, including RFC 4103. It allows immediate conversational text through mobile phone text messaging and mainstream instant messaging. For more information on the benefits of XEP-0301, see http://www.realjabber.org/xep/xep-0301.html.

Yet despite its potential benefits, the Board cannot incorporate XEP-0301 until it becomes a final standard. However, should the XEP-0301 standard be finalized before publication of the final rule, the Board plans to incorporate it by reference as an alternative technology to support transmission of RTT when interoperating with VoIP products or systems using XMPP. RFC 4103 would, in any event, be retained for ICT interoperating with VoIP products or systems using SIP technology.

Question 8. If the XEP-0301 standard is finalized, the Board is considering incorporating it by reference as an alternative standard for XMPP networks. We seek comment on the benefits, costs, and possible drawbacks associated with referencing this standard in addition to the RFC 4103 standard.

The European standard, EN 301 549 would allow the use of multiple standards for RTT. As discussed in 4.6, Harmonization with European Activities above, EN 301 549 lists several standards for RTT, as well as an unspecified “common specification” for RTT. The common specification must indicate a method for indicating loss of corruption of characters. The Board seeks comment on whether other standards should be incorporated by reference. The other standards are:

  • ITU-T v.18, Recommendation ITU-T V.18 (2000) “Operational and interworking requirements for DCEs operating in the text telephone mode” (see EN 301 549 6.3.3(a)). This Recommendation specifies features to be incorporated in data carrier equipment intended for use in, or communicating with, text telephones primarily used by people who are deaf or hard of hearing.
  • IP Multimedia Sub-System (IMS) protocols specified in TS 126 114, TS 122 173, and TS 134 229 (see EN 301 549 6.3.3(c)). ETSI TS 126 114, Universal Mobile Telecommunications System (which was referenced in the EAAC Report and Recommendation noted previously in Section IV.F.2) supports a “total communication” approach by establishing a minimum set of codecs and transport protocols that must be supported by all elements in the IMS system for video, real-time text, audio, and high definition (HD) audio. As noted previously, the Board decided not to require standards for video, audio, or HD audio in this proposed rule beyond the technical requirements set forth in proposed 410 (ICT with Two-Way Voice Communication). Both the ETSI TS 122 173 and ETSI TS 134 229 standards are still under development, and, therefore, cannot be referenced at this time.

Question 9. Are there sufficient net benefits to be derived from requiring ITU-T v.18 that the Board should reference it in addition to TIA 825-A (2003)? We are requesting that telecommunication equipment manufacturers, in particular, provide any data regarding potential costs related to complying with this standard. Are there suggestions for other standards which would result in the same level of accessibility?

Question 10. Are there net benefits to be derived from requiring more standards addressing multimedia than what we propose? The Board is requesting that telecommunication equipment manufacturers, in particular, provide any data regarding potential costs related to complying with the standards in EN 301 549 6.3.3(c). Are there suggestions for other standards which would result in the same level of accessibility?

Question 11. Is ETSI TS 122 173 or ETSI TS 134 229 sufficiently significant that the Board should consider referencing either standard when it becomes final?

E. Assistive Technology

Based on the work of the Advisory Committee and feedback from commenters, the Board proposes in this NPRM to directly cover some, but not all, aspects of assistive technology (AT). All stakeholders agreed that improving ICT-AT interoperability was critically important, but offered differing perspectives on how to make this happen. There was general consensus on some proposals (e.g., requirements for mainstream ICT), but not for others (e.g., requirements for, and status of, AT). In this NPRM, the Board proposes to revise its existing 508 Standards and 255 Guidelines by: (a) updating the existing requirements for mainstream ICT software products—namely, platforms, operating systems, and applications—to interoperate with assistive technology based on consensus standards; (b) adding a new requirement for AT with a user interface to interoperate with mainstream platforms and industry standard accessibility services; and (c) clarifying that assistive technology is generally exempted from compliance with otherwise applicable technical requirements for hardware (Chapter 4) and software (Chapter 5). Each of these areas are discussed briefly below.

With respect to the ICT side of the ICT-AT interoperability equation, the Board proposes a set of updated technical requirements for platforms and applications that will result in improved interoperation. This proposal received strong support from industry stakeholders who lauded it as an important improvement from the existing requirements because it was comprehensive, testable, and harmonized with international consensus standards for software accessibility. Proposed 502 contains three main subsections. Proposed 502.2 Documented Accessibility Features largely tracks § 1194.21(b) of the existing 508 Standards, and was strongly recommended by the Advisory Committee. Proposed 502.3 (Platform) Accessibility Services incorporates much of existing 508 Standards §§ 1194.21(b), (c), (d), and (f), but proposed 502.3.1 through 502.3.9 provide significantly greater detail. Lastly, in 502.4 Platform Accessibility Features, the Board proposes to require that platforms provide specific accessibility features common to most platforms. This provision is being proposed in response to concerns raised by consumers and the assistive technology industry that the Board was not being sufficiently proactive in spelling out the accessibility features that are well-established best practices. This proposal is based on requirements in the ANSI/HFES 200.2 Human Factors Engineering of Software User Interfaces standard, and represents current industry practice.

Second, to address the role of the AT in ICT-AT interoperability, the Board proposes modest requirements for assistive technology. Proposed 503.3 Alternate User Interfaces would require assistive technology to use the basic set of platform accessibility information provided by operating systems and software (i.e., platform accessibility information provided under proposed 502.2) to aid interoperability, and, thereby, decrease the need for customized approaches. In other words, software providing an alternative user interface would need to support the platform for which it is designed. Commenters outside the AT industry voiced strong support for this proposal; these views convinced the Board that this modest shift in approach from the existing requirements would better ensure ICT-AT interoperability. Because it is sometimes ambiguous whether a software product is serving as assistive technology, this proposed provision speaks in terms of “alternate user interface[s] that function[] as assistive technology.” Proposed 503.3 is the only manner in which the Board is proposing to directly impose requirements on assistive technology; in all other respects, provisions aiding interoperability are directed at platforms, operating systems, and other types of applications.

Third, to provide clarification sought by a number of commenters, the Board proposes to expressly exempt assistive technology from compliance with technical requirements generally applicable to hardware (Chapter 4) and software (Chapter 5). Commenters had expressed concern that, if assistive technology was treated as ICT for all purposes, some assistive technology would not be able to fulfill its intended function. For example, an individual with low muscle tone may find that a specialized, flat membrane keyboard best serves his or her needs; however, such a keyboard would not satisfy the requirements of Chapter 4 because, among other things, it does not have tactilely discernable separation between keys (proposed 407.3). Accordingly, proposed 401.1 provides an exception for hardware that is assistive technology, and a similar exception is proposed for assistive technology software (501.1 – Exception 2).