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

E. 2010 and 2011 ANPRMs: Significant Issues

In this section, the Board collectively reviews the principle issues from the 2010 ANPRM and 2011 ANPRM in consolidated fashion.

1. Evolving Approach to Covered Electronic Content

Nearly two decades have passed since promulgation of the existing 508 Standards. Since that time, the types of—and uses for—electronic documents and other content have grown tremendously. This growth, coupled with the fact that the existing standards do not clearly spell out the scope of covered electronic content, led to inconsistencies in accessibility of electronic data and information across federal agencies. One of the goals of this rulemaking is thus to provide updated standards for electronic content that clearly delineate the accessibility requirements applicable to electronic content.

In the 2010 ANPRM, the Board proposed that, when federal agencies communicate using electronic content, that content would be required to comply with the revised 508 Standards when “(a) an official communication by the agency or a representative of the agency to federal employees which contains information necessary for them to perform their job functions; or (b) an official communication by an agency or a representative of the agency to a member of the public, which is necessary for them to conduct official business with the agency as defined by the agency’s mission.” Many commenters disagreed with this approach because, in their view, all agency communications would fall into one of the two categories, and therefore no content would be exempt. In addition, commenters feared that our approach would require each employee to be capable of creating accessible content for all of his or her own individual communications. According to the commenters, this, in turn, would require costly training without necessarily resulting in greater accessibility.

We responded to these concerns in the 2011 ANPRM by proposing that electronic content need be made accessible only if it both communicated official agency business to a federal employee or a member of the public and fell into one of nine specified categories: (1) content that is public facing; (2) content that is broadly disseminated throughout an agency, including templates; (3) letters adjudicating any cause within the agency’s jurisdiction; (4) internal or external program and policy announcements; (5) notices of benefits, program eligibility, and employment opportunities and decisions; (6) forms, questionnaires, and surveys; (7) emergency notifications; (8) formal acknowledgements and receipts; and (9) educational and training materials. This included all formats of official communications by agencies, including Web pages, postings on social media, and email. Our intent was to clarify what information and data would be required to be accessible without placing an undue burden on government communications and operations.

Commenters to the 2011 ANPRM generally supported this approach. However, one commenter expressed concern that limiting coverage of electronic content to certain specific categories could lead to a non-inclusive work environment for employees and that agencies would make accessible only that content covered by the 508 Standards to the exclusion of anything else. Some commenters recommended that the Board associate templates with forms in one category and differentiate that category from the category containing questionnaires and surveys. Several commenters—including federal agencies—found the language in the provision on content that was “broadly disseminated” to be vague and overbroad, and requested that this provision be either revised or withdrawn.

Another key issue addressed in the Board’s advance notices of proposed rulemaking was the scope of exceptions to covered content. In the 2010 ANPRM, the Board proposed an exception for content stored solely for archival purposes or retained solely to preserve the exact image of the original hard copy. We retained that exception in the 2011 ANPRM, but added a second exception for “works in progress and drafts that are not public facing and that are intended for limited internal distribution.”

Commenters to the 2011 ANPRM raised many questions as to how those exceptions would apply. For example, some commenters expressed confusion about the exception for archival materials. Many commenters viewed “archival” as referring to content preserved in agencies’ internal information technology content management systems, rather than public records preservation generally, and asked us to clarify what the Board meant by the term. Other commenters expressed concern that otherwise accessible materials might be rendered inaccessible during the archiving process.

In addition to making significant revisions in the 2011 ANPRM to covered content under the proposed 508 Standards, the Board also amended our approach to content subject to the 255 Guidelines. We proposed that “electronic content integral to the use of ICT” covered by the 255 Guidelines must conform to Level A and Level AA Success Criteria and Conformance Requirements specified for Web pages in WCAG 2.0, as incorporated by reference in C102 (Referenced Standards). The Board received no comments on this provision in the 2011 ANPRM.

In this proposed rule, the Board clarifies areas of confusion and makes various other changes to the scope of covered electronic content. We discuss our approach in further detail in Section V.A (Major Issues – Electronic Content), Section VI.B (Section-by-Section Analysis – 508 Standards: Application and Scoping - E205), and Section VI.C (Section-by-Section Analysis – Technical Requirements - C203).

2. Treatment of WCAG 2.0

The Access Board and the World Wide Web Consortium (W3C)—the leading international standards organization for the World Wide Web—share a rich history of collaboration on guidelines for website accessibility. The existing 508 Standards and WCAG 1.0 were under development around the same time period in the late 1990s; WCAG 1.0 was finalized in May 1999, and the existing 508 Standards shortly thereafter in December 2000. The existing 508 Standards, § 1194.22—which addresses “Web-based Intranet and Internet Information and Applications”—has two endnotes, the first of which notes the Board’s view that eleven out of our sixteen provisions of the standards are consistent with Web Content Accessibility Guidelines (WCAG) 1.0 Priority 1 Checkpoints. The remaining five provisions in that section do not have close analogs to WCAG 1.0 Priority 1 checkpoints, but they strongly influenced the development of the next iteration of WCAG, WCAG 2.0.

As part of the 508 Standards refresh, the Advisory Committee recommended—and the Access Board agreed—that closer harmonization with WCAG 2.0 was necessary to promote greater accessibility. Consequently, in the 2010 ANPRM, the Board proposed to include most Level A and Level AA WCAG 2.0 Success Criteria. However, rather than using the text of relevant portions of WCAG 2.0 verbatim, the Board restated those Success Criteria in mandatory language thought to be better suited for a regulatory environment. Comments to the 2010 ANPRM identified three major problems with that approach. First, many expressed concern that rephrasing WCAG 2.0’s Success Criteria would introduce discrepancies in, and fragmentation of, the 508 Standards. Second, other commenters feared that rephrasing of success criteria, rather than incorporating WCAG 2.0 by reference, would make dynamic linkages in the online version of WCAG 2.0 to important supplementary information less available to the reader. These commenters emphasized the usefulness of the online in-context hypertext links to robust guidance materials as aids for understanding and applying the WCAG 2.0 Success Criteria. Lastly, commenters found our division of provisions (including the many rephrased WCAG Success Criteria) into those respectively oriented towards either documents or software to be somewhat arbitrary and counterproductive.

In response to these comments, the Access Board substantially revised the approach to WCAG 2.0 in the 2011 ANPRM. We proposed to require all covered content to conform to WCAG 2.0, which would be incorporated by reference in the proposed 508 Standards.

Commenters generally voiced strong support for the Board’s decision to incorporate by reference WCAG 2.0 and apply it to all types of covered ICT, rather than simply seeking harmonization between WCAG 2.0 and the proposed rule. While commenters expressed concern as to how closely WCAG 2.0 would apply to some types of content, they generally supported the concept of expanding the application of WCAG 2.0 to all types of Web and non-Web ICT. A few commenters, including representatives of the software industry, also suggested that the rule allow for compliance with any subsequent and, as yet unpublished, revisions to WCAG 2.0 by the W3C.

Some commenters, on the other hand, requested that the Board return to its previous approach in the 2010 ANPRM, rather than incorporate WCAG 2.0 by reference. Most of these commenters believed that this approach would make the Board’s rule easier to use because the necessary text would be contained in a single document. Some of these commenters also asserted that the structure of WCAG 2.0 is confusing and makes it difficult to separate the normative and non-normative portions.

In this NPRM, the Board is retaining the Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 for all ICT subject to Sections 508 and 255, including documents and software. The Board also proposes, as in the 2011 ANPRM, to incorporate WCAG 2.0 by reference, rather than restating its requirements in the proposed rule. Incorporating the WCAG Success Criteria verbatim in the rule would be unhelpful because they are best understood within the context of the original source materials. WCAG 2.0 incorporates context-sensitive hypertext links to supporting advisory materials. The two core linked resources are Understanding WCAG 2.0 and Techniques for WCAG 2.0. The first provides background information, including discussion of the intention behind each of the success criteria. The second provides model sample code for conformance. The linked expository of documents, which is publicly available online free of charge, comprise a rich and informative source of detailed technical assistance and are updated regularly by standing working committees. These linked resources are not themselves requirements and agencies adopting WCAG 2.0 are not bound by them.

The Board cannot accept the suggestion of software industry representatives that the proposed rule permit compliance with any follow-on versions of WCAG 2.0. Federal agencies cannot “dynamically” incorporate by reference future editions of consensus standards.¹ Such action is legally prohibited since it would, among other things, unlawfully delegate the government’s regulatory authority to standards development organizations, as well as bypass rulemaking requirements (which would typically include a public notice‐and‐comment period). Federal agencies are required to identify the particular version of consensus standards incorporated by reference in a regulation. When an updated edition of a consensus standard is published, the agency must revise its regulation if it seeks to incorporate any of the new material. Nevertheless, the Access Board plans to remain abreast of updates to voluntary consensus standards bearing on ICT, and will consider incorporating them into future rulemakings, as appropriate.

We discuss incorporation of WCAG 2.0 in further detail below in Section V.B (Major Issues – WCAG 2.0 Incorporation by Reference), Section VI.B (Section-by-Section Analysis – 508 Standards: Application and Scoping – E205 and E207.2), and Section VI.C (Section-by-Section Analysis – 255 Guidelines: Application and Scoping - C203 and C205.2).

3. Relationship between Functional Performance Criteria and Technical Provisions

Over the years, agencies and other stakeholders had expressed confusion concerning the interaction between the technical requirements and functional performance criteria in the existing 508 Standards. To address this confusion, in the 2010 ANPRM, the Board proposed language to clarify that ICT may be deemed accessible if satisfying all applicable technical requirements, irrespective of whether the functional performance criteria had been met. In other words, the Board proposed that the technical requirements took precedence over the functional performance criteria in the sense that agencies should look first to applicable technical provisions, and only turn to the functional performance criteria when such requirements did not fully address the technology at issue. Commenters objected to this approach, citing the concern that ICT procurements satisfying only the technical requirements would not necessarily ensure sufficient access to individuals with disabilities.

We responded to this concern by proposing in the 2011 ANPRM that ICT be required to conform to the functional performance criteria in every case, even when technical provisions were met. We also proposed to use the functional performance criteria (as did the 2010 ANPRM) to evaluate equivalent facilitation. That is, a covered entity would have the option of applying the concept of equivalent facilitation in order to achieve conformance with the intent of the technical requirements, provided that the alternative afforded individuals with disabilities substantially equivalent or greater accessibility and usability than would result from compliance with the technical requirements.

Some commenters, such as those representing federal agencies, the disability community, and other interested parties applauded this approach. Other commenters representing industry objected, noting that functional performance criteria are subjective and cannot be tested objectively. Industry commenters stated that they could not guarantee that the functional performance criteria had been met unless they controlled all the components of the end-to-end solution.

In this NPRM, the Board is not proposing that the functional performance criteria apply in every case. However, the Board does propose application of the functional performance criteria (with some modifications) to determine equivalent facilitation (E101.2 and C101.2), and to assess accessibility when technical provisions do not address one or more features of ICT. The Board discusses this issue in further detail below in Section V.C (Major Issues - Functional Performance Criteria), Section VI.B (Section-by-Section Analysis - 508 Standards: Application and Scoping - E203 and E204), and Section VI.C (Section-by-Section Analysis – 255 Guidelines: Application and Scoping - C202).

4. Coverage of Real-Time Text

As noted previously, the existing 508 Standards and 255 Guidelines were promulgated nearly fifteen years ago. At that time, TTYs were the most commonly available text-based system for communicating within a voice communication system. Since then, technology has greatly advanced to the point where, in addition to TTYs, multiple text-based means of communication are available in the marketplace. One such emerging means of communication is real-time text technology. RTT technology provides the ability to communicate using text messages that are transmitted in near real-time as each character is typed, rather than as a block of text after the entire message is completed. RTT is important as an equivalent alternative to voice communications for persons who are deaf, or who have limited hearing or speech impairments. It allows the recipient to read the sender’s text as soon as it is entered, thus making RTT more conversational and interactive, in a manner similar to a telephone conversation. This also makes RTT particularly useful in an emergency situation when speed and accuracy of a message—or even a partial message—are critical.²

The Advisory Committee examined real-time text technology and recommended that the Board update the 508 Standards and 255 Guidelines to include specifications for RTT. More specifically, the Advisory Committee recommended that, when hardware or software provides real-time voice conversation functionality, it must provide at least one means of RTT communication. See TEITAC Report, Part 6, Subpt. C, Rec. 6-A. With respect to interoperability (i.e., operating outside a closed network), the Committee had two recommendations. First, the Advisory Committee recommended use of the TIA 825-A (Baudot) standard when ICT interfaces with the publicly switched telephone network (PSTN). Second, when ICT interoperated with VoIP products or systems using Session Initiation Protocol (SIP), the Advisory Committee did not recommend a specific standard, noting that there were several possible standards at that time (April 2008), such as RFC 4103, TIA 1001, and MSRP (RFC 4975). Id.

In keeping with the Advisory Committee’s recommendation, the Board proposed in the 2010 ANPRM, to require ICT providing real-time voice communication to support RTT functionality. The Board also proposed prescriptive standards for RTT (e.g., transmission delay, error rates), as well as interoperability requirements. For interoperability with PSTN, the Board proposed (as did the Advisory Committee) use of the TIA 825-A (Baudot) standard. For ICT interoperating with VoIP products or systems using SIP, the Board did not propose a specific standard; instead, the Board proposed that such products or systems support transmission of RTT conforming to a “commonly used cross-manufacturer, non-proprietary standard.” The Board considered referencing RFC 4103, but elected not to do so because, at that time, it was not thought to be a referenceable standard.

Commenters responding to the RTT-related proposals in the 2010 ANPRM generally supported RTT, but offered mixed views on the Board’s proposed technical specifications. Commenters representing people with disabilities strongly supported inclusion of RTT functionality requirements in the proposed rule. They emphasized, among other things, that RTT represented a major advance by allowing persons with hearing- or speech-related disabilities to communicate through real-time text on mainstream devices, rather than having to use special and expensive devices (such as TTYs). They were critical, however, of the Board’s decision not to incorporate a specific VoIP-related interoperability standard. Commenters representing people with disabilities (and also academia) urged the Board to adopt RFC 4103 for RTT interoperating with VoIP using SIP, and provided information to support its use as a referenceable standard. Commenters from industry, on the other hand, encouraged the Board to take a cautious approach to RTT. They believed that, while RTT technology held promise as a major improvement in text communication (particularly in emergency situations), it was not sufficiently mature at that time to warrant adoption of a particular interoperability standard—including RFC 4103—for Internet-based calls. Commenters also objected to the proposed character and transmission delay rates as being overly prescriptive, thus potentially restricting the development of future technologies. (No commenters took issue with the Board’s proposal to incorporate TIA 825-A as the standard for interoperability with PSTN.)

Based on these comments, in the 2011 ANPRM, the Board proposed to retain the references to the TIA 825-A standard for TTY signals on the PSTN, and to add a requirement for conformance with the RFC 4103 standard for VoIP products or systems using SIP. We did not retain the provisions specifying character and transmission delay rates. Overall, commenters largely supported the Board’s revisions to RTT-related requirements in the 2011 ANPRM. However, several commenters representing industry and a local government agency asserted that RTT was not sufficiently mature or deployed widely enough to be useful. Some commenters also identified other standards aside from RFC 4103 that were currently in use (e.g., XMPP and XEP-0301) and could serve to facilitate RTT for Internet-based calls.

In this NPRM, the Board proposes to require that, where ICT provides real-time, two-way voice communication, such ICT must also support RTT functionality. Proposed 410.6 would require features capable of text generation to be compatible with real-time voice communication used on a network. ICT would be required to interoperate 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. The Board believes that RTT is sufficiently mature as a technology (and has sufficiently proliferated in the current ICT marketplace) to warrant coverage in the proposed rule. For example, real-time instant messaging programs—such as Yahoo!®Messenger and AOL Instant Messenger’s “Real-Time IM” —have, in the past, used proprietary protocols that were very similar to SIP.

Where federal agencies provide their employees with smartphones or similar technology, this NPRM would require such ICT to have the potential to communicate using RTT. The Board does not, however, thereby intend to require that all phone users (with or without disabilities) communicate using RTT in all circumstances. Similar to several other proposed accessibility features in the proposed rule, RTT must only be enabled and used when needed to ensure comparable access and use of ICT by persons with hearing disabilities. For example, federal managers will need to make clear that, when deaf or hard-of-hearing employees with agency-provided smartphones use RTT, coworkers without disabilities using agency smartphones will also need the RTT feature on their respective phones enabled. Such an approach ensures that communications among deaf and hearing coworkers are equally effective as voice conversations among employees who do not have hearing impairments. Employees who do not need to communicate using RTT would otherwise be able to disable or ignore this feature.

The Board does not suggest that other forms of electronic communication—text or email, for example—would not be used by deaf employees and their colleagues. However, RTT offers many of the same benefits as voice communication. For example, a deaf attorney may need to seek the advice of his supervisor or colleagues during a break in a sensitive negotiation. Given the urgency and time-sensitive nature of the communications between employees, the deaf employee may request that his colleagues make themselves available during the negotiation by enabling RTT on their phones.

The Board did not consider proposing that agencies be permitted to provide RTT-enabled phones to employees only upon request. We did not consider this approach for two significant reasons. First, making accessible ICT available only upon request would run counter to Section 508’s basic premise that information and data must be accessible to all employees without special treatment or the necessity for individualized treatment. Permitting issuance of RTT-enabled smartphones only when requested or deemed needed would be no different than permitting agencies to procure inaccessible ICT, such as a copy machine, where they have not identified a need for the accessible features among current staff. Second, while a proposal permitting agencies to issue non-RTT smartphones absent a special request for RTT features might modestly reduce an agency’s ICT costs (to the extent, if any, that the purchase cost of RTT-enabled smartphones exceeds the cost of smartphones without this feature) and allow agencies to take user preferences regarding RTT into account, such an alternative would erode the proposed rule’s benefits because employees with disabilities who need RTT would not be able to communicate with coworkers who are using government-issued, non-RTT smartphones.

Question 1. To realize the full potential benefits of the Section 508 proposal to require RTT functionality wherever an ICT product provides real-time, two-way voice communication, federal managers would need to direct their employees to keep the RTT features on their phones enabled when needed to accommodate employees with disabilities who use RTT, and federal employees would need to follow such directives. How would keeping RTT enabled on an “as needed” basis affect federal employees’ use of texting? For example, would it cause them to substitute texting with other methods of communication? How can the Board analyze and quantify such effects?

Question 2. The benefits of the RTT proposal under Section 255 are dependent upon the extent RTT features would be enabled and used by the public. The public would not be required to use or keep the RTT features on their phones enabled. Is there available information regarding the extent the public would use RTT features if they were available on their phones? Would use of RTT be different for people with and without disabilities?

In terms of RTT standards, the Board is proposing to require that ICT interoperating with VoIP products using SIP must support the transmission of RTT that conforms to RFC 4103 (RTP Payload for Text Conversion (2005)). In the Major Issues section, the Board also seeks comment on whether additional standards for real-time text, which are in the process of being finalized (such as XEP-0301), should be referenced. See Section V.D, Question 8. We discuss RTT-related issues in further detail below in Section V.D (Major Issues – Real-Time Text), and Section VI.D (Section-by-Section Analysis – Technical Requirements and Functional Performance Criteria – section 410.6).

5. Interoperability Requirements for Assistive Technology

Assistive technology (AT) is hardware or software used to increase, maintain, or improve the functional capabilities of individuals with disabilities. Examples of assistive technology commonly used with computers include: screen readers, screen magnification software, specialized keyboards, refreshable braille displays, and voice recognition software. Assistive technology provides access beyond that offered by so-called “mainstream” hardware or software.

Compatibility with assistive technology is a foundational concept common to the existing 508 Standards and 255 Guidelines. ICT and assistive technologies must generally work together to provide users with necessary interface functions and features. The existing 508 Standards include general requirements for ICT to be compatible with assistive technology. Section 1194.21(b) requires that applications not disrupt or disable activated features of other products that are identified as accessibility features where those features are developed and documented according to industry standards. Additionally, this section requires that applications not disrupt or disable activated features of any operating systems that are identified as accessibility features. Section 1194.21(b) is directed only to applications, and does not require assistive technology to be compatible with other assistive technology. Section 1194.21(d), moreover, obligates mainstream software to provide “sufficient information” about its user interface elements to assistive technology.

The existing 255 Guidelines, though taking a slightly different tact, also require mainstream products to be compatible with assistive technologies. Under these guidelines, telecommunications equipment must be compatible with “peripheral devices and specialized premises equipment commonly used by individuals with disabilities to achieve accessibility.” 36 CFR 1193.51. Compatibility is specified by provisions requiring: external access to controls and information needed for product operation, connection points for external audio processing devices, compatibility of controls with prosthetic devices, and TTY connectability and compatibility.

The existing 508 Standards and 255 Guidelines are, however, equally silent concerning whether (or how) their requirements apply to assistive technology. That is, while these standards and guidelines require ICT to interoperate with assistive technology, they do not directly regulate assistive technology. Over the years, this silence in the 508 Standards has led to confusion. We have thus viewed coverage of assistive technology as a key issue throughout the process of updating the 508 Standards and 255 Guidelines.

The Advisory Committee, when addressing assistive technology, offered several perspectives. First, to improve ICT-AT compatibility, the committee recommended updated—and more comprehensive—technical standards that require mainstream computer operating systems and software with user interfaces to “expose” (i.e., make available at the underlying program level) accessibility information that facilitates use of assistive technology. For example, screen reading and voice recognition software may be used to emulate, respectively, the physical click of a mouse button or the keystrokes from a hardware keyboard. These ICT interoperability requirements were carefully crafted among the various stakeholders on the committee, as well as harmonized with an international consensus standard for software accessibility (ISO 9241-171 Ergonomics of human-system interaction - Part 171: Guidance on software accessibility (2008)). See TEITAC Report, Part 6, Subpt. C, Recs. 3-V & 3-U. Second, the committee debated—though could not reach consensus on—a recommendation obligating assistive technology to use (as applicable) the standardized set of accessibility information provided by mainstream operating systems and software, rather than taking customized approaches. See TEITAC Report, Part 7, Subpt. C, Rec. 3-VV.

In the 2010 and 2011 ANPRMs, which drew heavily from the TEITAC Report, the Board took similar approaches to assistive technology. These ANPRMs largely adopted the committee’s recommended set of updated technical standards governing the program-level accessibility information mainstream operating systems and software must make available to assistive technology. The Board also proposed to require assistive technology to use this accessibility information to achieve interoperability. Commenters generally applauded the Board’s proposed refresh of the interoperability requirements for mainstream operating systems and software, and viewed these requirements as a big step forward. Assistive technology vendors and trade organizations, however, uniformly objected to the imposition of requirements on assistive technology. They expressed a need to be wholly unconstrained to best serve consumers. They also expressed concern that accessibility services varied widely from platform to platform, and were often insufficient to support necessary features of their assistive technology products. All other commenter groups—including individuals with disabilities and the mainstream IT industry—advocated maintaining the minimal requirements for assistive technology included in the ANPRMs.

In this NPRM, the Board proposes to retain, with minimal changes, the technical interoperability requirements for mainstream operating systems and software from the prior ANPRMs. The Board also found commenters’ arguments for inclusion of minimal requirements for assistive technology to be compelling. Accordingly, the Board has also retained the proposal requiring assistive technology to use the basic set of accessibility information provided by operating systems and software to achieve interoperability. We discuss these issues in further detail below in Section V.E (Major Issues – Assistive Technology), and Section VI.D (Section-by-Section Analysis – Functional Performance Criteria and Technical Requirements – 502 and 401).

6. Modifications to the Functional Performance Criterion for Limited Vision

In order to ensure that ICT meets the needs of a wider range of users, the Board proposed in the 2010 ANPRM to revise the functional performance criterion for limited vision. The existing criterion specifies that ICT providing a visual mode of operation must furnish at least one accessible mode that accommodates visual acuity up to 20/70. The Board proposed to increase the covered acuity range to 20/200 (or a field of vision less than 20 degrees)—which is a common legal definition of blindness—to afford more individuals with disabilities the option of a visual mode of operation. Organizations representing persons with disabilities disagreed with the visual acuity proposed requirement, stating that it did not sufficiently address the needs of users with severe low vision. Industry groups suggested that the proposed visual acuity criterion contradicted several technical requirements. These commenters also indicated that our approach did not address features that could improve accessibility for persons with low vision, and were critical of the limitation that only one feature had to be provided for each mode of operation.

In response to these comments, in the 2011 ANPRM, the Access Board dispensed with specified measurements of visual acuity and relied instead on a functional approach reflective of the needs of users with low vision. We proposed that, when ICT provides a visual mode of operation, it must also provide at least one mode of operation that magnifies, one mode that reduces the field of vision, and one mode that allows user control of contrast. These modes would need to be supplied directly in the same ICT or through compatible assistive technology. Commenters to the 2011 ANPRM strongly approved of our approach to functional performance criteria for limited vision.

Accordingly, the Board proposes to retain this approach to functional performance criteria for limited vision in this propose rule. We discuss the issue in further detail in Section VI.B (Section-by-Section Analysis – Section 508 Application and Scoping - E203), Section VI.C (Section-by-Section Analysis – 255 Guidelines Application and Scoping - C201.3), and Section VI.D (Section-by-Section Analysis – Functional Performance Criteria and Technical Requirements – 302.2).

7. Definition and Coverage of Technology with “Closed Functionality”

In its TEITAC Report, the Advisory Committee recommended that the Board make a nomenclature change to “closed functionality” from the existing term “self-contained, closed products“ to better reflect a regulatory approach to ICT based on functionality, rather than type of product. The Advisory Committee observed that, due to technological changes since the promulgation of the existing standards and guidelines, some formerly “closed” product types were now open, while some formerly open product types were now closed—frequently by policy, rather than technological constraint. See TEITAC Report, Part 4, section 4.2. It suggested that when the functionality of a technology product is closed for any reason, including policy or technical limitations, then such product should be treated as having closed functionality.

In the 2010 ANPRM, the Board followed the Advisory Committee’s recommendation and proposed to substitute the term “closed functionality” for “self-contained, closed products,” as used in the existing 508 Standards. See 36 CFR 1194.4. While both terms refer to ICT with characteristics that limit its functionality, the term “closed functionality”—in the Board’s view—better describes situations where the ICT is locked down by policy, rather than design. This may occur, for example, when an agency provides computers with core configurations that cannot be changed or adjusted by a user. We proposed permitting ICT to have closed functionality; however, such ICT still would need to be accessible to and usable by individuals with disabilities without assistive technology. Commenters did not object to the new terminology of “closed functionality” but asked for more detail and clarity in the applicable standards.

In the 2011 ANPRM, the Access Board proposed specific requirements for ICT with closed functionality to ensure accessibility to individuals with disabilities, which included a provision requiring ICT with closed functionality to be speech-output enabled. The term “speech-output enabled” means that the ICT can transmit speech output. These proposed requirements were derived from the Americans with Disabilities Act and Architectural Barriers Act Accessibility Guidelines (ADA and ABA Accessibility Guidelines), 36 CFR Part 1191, Appendix D, section 707.5 Speech Output.

Commenters to the 2011 ANPRM generally supported our proposed requirement for “closed functionality,” and the Board proposes to retain it in this proposed rule. We discuss the issue further in detail below in Section VI.D (Section-by-Section Analysis – Functional Performance Criteria and Technical Requirements - section 402).

8. Revisions to Exceptions under 508 Standards

In the 2010 ANPRM, the Board reorganized the exceptions in the existing 508 Standards and recommended deleting three others that were unnecessary or had led to confusion. The three exceptions proposed for deletion were: § 1194.3(c) (assistive technology at federal employees’ workstations); § 1194.3(d) (access to agency-owned ICT in public locations); and § 1194.3(f) (ICT equipment in maintenance spaces or closets). By proposing deletion of these three exceptions, the Board intended only administrative changes to clarify the 508 Standards; there was no intent to narrow their scope or application.

First, with respect to § 1194.3(c), which provides that assistive technology need not be supplied at all federal employees’ workstations, the Board proposed its deletion because, in essence, it provided an exception where none was needed, and thus led to confusion. There is no general rule in the existing 508 Standards that agencies provide assistive technology at all employee workstations; rather, these standards merely require compatibility with assistive technology when ICT is not directly accessible.

Second, the Board proposed deletion of § 1194.3(d) because it conveys the impression that the 508 Standards govern the locations where ICT must be made available to the public. The 508 Standards do not, in any way, control where ICT is located. Therefore, the exception was unnecessary.

Third, the Board proposed to delete the exception in 1194.3(f) for ICT equipment located in maintenance spaces or closets frequented only by service personnel for “maintenance, repair, and occasional monitoring of equipment.” We reasoned that, since maintenance spaces or closets are already exempted from accessibility requirements under section F203.6 of the Architectural Barriers Act (ABA) Standards, there was no need for a similar exception in the 508 Standards.

Commenters’ views on the proposed deletion of these three exceptions were mixed. On the one hand, most commenters supported removal of the exceptions pertaining to employee workstations and public availability of agency-owned ICT. On the other hand, however, many commenters objected to our proposed removal of the exception for ICT located in maintenance spaces since there are still many functions—particularly with respect to maintenance, repair, and monitoring—that, in the commenters’ view, could only be performed in maintenance spaces. In response to these comments, the Board has retained the exception for maintenance spaces in this NPRM, but proposes to limit its application to situations in which the controls for ICT functions are located in spaces that are frequented only by service personnel. This is consistent with the ADA and ABA Accessibility Guidelines, which exempt such spaces from accessibility requirements. However, where the functions of ICT located in maintenance spaces can be controlled remotely, this exception would not apply to such remote functions. These remote functions would still need to comply with applicable 508 Standards.

Lastly, in the 2010 ANPRM, the Access Board proposed to revise and relocate the exception in § 1194.3(b), which exempts ICT acquired by a contractor that is “incidental to a contract” from compliance with 508 Standards. Specifically, the Board proposed deleting the phrase “incidental to a contract” and relocating the exception to a new section relating to federal contracts. We did so in an effort to streamline and clarify the text of this exception. Commenters criticized this approach as confusing, particularly since the phrase “incidental to a contract” is a well-established term within the federal procurement community—a group that would likely be significantly impacted by the provision. Consequently, in the 2011 ANPRM, the Board proposed to restore the exception in § 1194.3(b) to its original language. We retain this approach in this NRPM, and thereby propose to exempt ICT acquired by a federal contractor that is “incidental to a contract” from compliance with the 508 Standards.

We discuss exception issues in further detail below in Section VI.B (Section-by-Section - 508 Standards: Application and Scoping - E202.3 and E202.4).

9. Broadening of Documentation Requirement for Undue Burden Exception

Section 1194.2 (a)(2) of the existing 508 Standards requires agencies to provide supporting documentation when determining that procurement of a compliant product would impose an undue burden. In the 2010 ANPRM, the Access Board proposed to broaden the undue burden documentation requirement so that it applied not only to ICT procurement, but also to other situations in which the 508 Standards applied—namely, the development, maintenance, or use of ICT. We did not receive any comments directly related to this approach, but did receive a few comments requesting clarification of the factors to be addressed in the determination of undue burden. In the 2011 ANPRM, the Board retained the broadened scope of the undue burden documentation requirement, but clarified the factors to be applied in the undue burden calculus. We proposed that an agency would be required to consider the extent to which conformance would impose significant difficulty or expense in light of the resources available to the program or component for which the ICT is being procured, developed, maintained or used. Commenters generally supported this approach.

In this NPRM, in proposed E202.5.2, the Board retains the undue burden documentation requirement as proposed in the 2011 ANPRM. This proposed provision is discussed in detail below in Section VI.B (Section-by-Section Analysis - 508 Standards: Application and Scoping - E202.5.2).