Overall, we received 162 comments in response to the NPRM, including written comments submitted to the online docket (https://www.regulations.gov/docket?D=ATBCB-2015-0002) and oral statements at three public hearings. In addition to comments received on the major issues discussed in the preceding section, commenters also expressed views on a variety of other matters related to the proposed rule. The Access Board’s response to significant comments on these other matters are discussed below on a chapter-by-chapter basis following the organization of the final rule. Also addressed below are requirements in the final rule that have been substantively revised from the proposed rule. Provisions in the final rule that neither received significant comment nor materially changed from the proposed rule are not discussed in this preamble.

A. 508 Chapter 1: Application and Administration

Chapter 1 of the Revised 508 Standards contains a general section that defines equivalent facilitation, addresses application of referenced standards, and provides definitions of terms used in the Standards. In the final rule, the provisions expressly incorporating the ten referenced standards into the Revised 508 Standards have been relocated from proposed E102 to a new Chapter 7, which provides a centralized IBR section pursuant to regulations issued by the Office of the Federal Register (OFR) that govern incorporations by reference in the Federal Register. This reorganization of IBR provisions is discussed at greater length in Section IV.I (Summary of Comments and Responses on Other Aspects of the Proposed Rule – Chapter 7: Referenced Standards). We have also made minor changes to 508 Chapter 1 in response to comments to improve clarity, accuracy, and ease of use. These changes are described below.

E101.3 Conventional Industry Tolerances

The NPRM proposed this section in the interests of being explicit about dimensions. We did not receive any comments on this provision but have decided, for the purpose of clarity and consistency with the Board’s other rulemakings, to add “with specific minimum or maximum end points” to E101.3 in the final rule.

E102 Referenced Standards

This section has been significantly reorganized and revised in the final rule. The general statements in the first two sentences regarding the application of referenced standards remain essentially unchanged from the proposed rule. However, the subsequent provisions in the proposed rule that expressly IBR the ten referenced standards into the Revised 508 Standards (i.e., proposed E102.2 – E102.10) have been moved in the final rule to a centralized IBR section – new Chapter 7. This reorganization of IBR provisions was made to comply with OFR regulations that govern incorporations by reference. See 1 CFR part 51. Comments related to proposed incorporations by reference into the Revised 508 Standards are discussed below in Section IV.I (Summary of Comments and Responses on Other Aspects of the Proposed Rule – Chapter 7: Referenced Standards).

E103.4 Defined Terms

We identified seven comments regarding proposed E103.4. These commenters asked the Board to clarify the definitions of (or provide examples for) the following terms: “authoring tool,” “application,” “document,” “operable part,” “platform software,” “public facing,” and “software.” Two commenters, an ICT company and an industry trade association requested the Access Board to fully align the definition of “authoring tool” to the definition in EN 301 549.

After review of the comments, we have determined that we would be providing clearer information by including more terms, and we therefore added definitions for “document,” “non-Web document,” “non-Web software,” and “Web page” to the list of defined terms in E103.4 in the final rule. The definitions provided for these terms closely track the definitions used in WCAG 2.0 and EN 301 549. For similar reasons of completeness, we also added the terms “software tools” and “variable message signs.” Additionally, based on commenter concerns, we amended the definitions of “software” and “operable part” in the final rule. The definition of “software” clarifies the term by giving the examples of applications, non-Web software, and platform software. The definition of “operable part” now makes clear that the term applies to physical parts (hardware). Finally, the Board added definitions for “alteration” and “existing ICT,” which are new terms used in the safe harbor provision applicable to existing 508-covered ICT (E202.2). Additional discussion of these new terms appears below in section IV.C (508 Chapter 2: Scoping Requirements in the discussion of the safe harbor provision at E202.2).

In response to the requests to align the definition for “authoring tool” to EN 301 549, the Board regards the two definitions as being equivalent, but has decided to retain the definition from the proposed rule due to editorial consideration. The main difference between the approach taken in the proposed rule and that of EN 301 549 is that the EN 301 549 definition for “authoring tools” includes three notes containing advisory guidance. Our practice is to provide advisory guidance in supplemental materials.

B. 508 Chapter 2: Scoping Requirements

508 Chapter 2 addresses application and scoping of the Revised 508 Standards, including exceptions. We have made multiple significant changes to this chapter. We added a ninth category to E205.3, official agency communications that are non-public-facing electronic covered content, and clarified the application of WCAG 2.0 to non-Web documents and software. We made corresponding changes to E205.4 and E207.2, including adding E205.4.1 and E207.3, which specify the word substitution necessary to apply WCAG 2.0 to non-Web content. These changes are discussed above in Section III.B. (Major Issues – Application of WCAG 2.0 to Non-Web ICT). In addition, we made editorial changes for consistency and clarity. These editorial changes and the responses to other comments received are discussed below.

E202 General Exceptions

In response to some agencies’ concerns regarding the time and resources that might be needed to remediate existing (legacy) ICT, the Board has incorporated a “safe harbor” provision into the Revised 508 Standards (E202.2). Under this provision, legacy ICT that complies with the existing 508 Standards and has not been altered after the compliance date (i.e., one year after publication of the final rule) need not be modified or upgraded to conform to the Revised 508 Standards. However, when existing ICT is altered after the compliance, such alterations must comply with the Revised 508 Standards. Application of the safe harbor provision will allow Federal agencies to focus their ICT accessibility efforts primarily on new ICT.

This safe harbor provision applies on an “element-by-element” basis in that each component or portion of existing ICT is assessed separately. In specifying “components or portions” of existing ICT, the safe harbor provision independently exempts those aspects of ICT that comply with the existing 508 Standards from mandatory upgrade or modification after the final rule takes effect. This means, for example, that if two paragraphs of text are changed on an agency Web page, only the altered paragraphs are required to comply with the Revised 508 Standards; the rest of the Web page can remain “as is” so long as otherwise compliant with the existing 508 Standards.

Additionally, to further clarify the specific circumstances under which existing ICT must be made to comply with the Revised 508 Standards, the Board has added definitions for “alteration” and “existing ICT” in E103.4. “Existing ICT” is defined as ICT that has been procured, maintained or used on or before the compliance date (which is one year after publication of the final rule). The Access Board has intentionally omitted the term “developed” from this definition because existing ICT that has been developed – but not yet used or procured – still presents an opportunity to incorporate requisite accessibility.

“Alteration,” in turn, is defined as a change to existing ICT that affects interoperability, the user interface, or access to information or data. In defining “alteration,” the Board seeks to distinguish between changes to existing (compliant) ICT that trigger compliance obligations under the Revised 508 Standards, and those that do not. For example, since correction of a typographical error on a Web page does not affect interoperability, user interface, or access to information and data, this type of change would not trigger compliance obligations under the Revised 508 Standards. However, changing the footer portion of an agency Web site through a content management system (CMS) would affect access to information and data (i.e., the information in the footer). In that case, changes to the footer would need to conform to the Revised 508 Standards; however, other page content that was not affected by the footer revision would not need to be upgraded or modified. In another example, a typical software security patch does not affect interoperability, user interface, or access to information and data; therefore, deployment of such software security patches would not be considered “alterations” under the safe harbor provision.

The safe harbor provision is applicable only to existing ICT covered by Section 508, and does not extend to Section 255-covered telecommunications equipment or CPE. Because the FCC has exclusive authority to implement and enforce Section 255, compliance with the Revised 255 Guidelines is not required until they are adopted by the FCC through a separate rulemaking. As such, application of the revised guidelines to existing ICT covered by Section 255 also lies within the province of the Commission.

Agencies and the public may need to refer to the existing 508 Standards to determine whether existing ICT complies with its accessibility requirements once the final rule takes effect. To that end, the existing 508 Standards have been republished as an appendix (Appendix D) to part 1194 for reference when evaluating legacy ICT under the safe harbor provision. In Appendix D, while the text and structure of each provision remains the same as in the existing 508 Standards, the numbering convention for each provision has been modified to comply with publication requirements for matter located in regulatory appendices.

The NPRM proposed five other general exceptions that apply to ICT that: is an integral part of a national security system (proposed E202.2); is acquired by a contractor incidental to a contract (proposed E202.3); is located in maintenance spaces (proposed E202.4); would require a fundamental alteration to be accessible (E204.5); or, is not commercially available (proposed E202.6). These five exceptions closely parallel equivalent requirements in existing 508 Standards (36 CFR §§1194.3(a), 1194.3(b), 1194.3(f), 1194.3(e), and 1194.2(b), respectively).

We received six comments expressing concern or requesting changes to proposed E202. Two commenters (a disability advocacy organization and an ICT subject matter expert) requested deletion of proposed E202.2, which exempts national security systems as defined by 40 U.S.C 1103(a). These commenters asserted that ICT that is part of a National Security System should be required to conform to the maximum extent possible, instead of being exempted entirely from compliance. Two commenters (a disability advocacy organization and an ICT subject matter expert) also requested that the exception for ICT acquired incidental to a contract in proposed E202.3 be removed, asserting it would discourage contractors from hiring employees with disabilities. Additionally, an individual commented that proposed E202.3 needed a major change because it has not been successful in the past in getting software manufacturers to make accessible software. This individual requested that the final rule require refunds if a future version of software failed to meet accessibility requirements. The Board also received three comments (one ICT company and two industry trade associations) seeking expansion of proposed E202.4, which exempts certain functions of ICT located in maintenance or monitoring spaces, to include a “back office exemption” for maintenance functions and maintenance spaces.

After carefully considering the comments received, we have decided not to make any changes to these five general exceptions in proposed E202, except to shift the numbering of the provisions to accommodate the incorporation of a safe harbor provision at E202.2 that applies to legacy 508-covered ICT. The exception proposed for National Security Systems (final E202.3) is taken directly from the statute authorizing the 508 Standards (Section 508 of the Rehabilitation Act of 1973, as amended, 29 U.S.C. 794d). Additionally, the statutory definition of “information technology,” which excludes equipment that is acquired by a Federal contractor incidental to a contract, prohibits the Access Board from requiring such ICT to comply with the Revised 508 Standards and 255 Guidelines. 40 U.S.C. 11101(6), stating that “[t]he term ‘information technology’ … does not include any equipment acquired by a Federal contractor incidental to a Federal contract.”

E202.4 in the proposed rule (final E202.5) was a change to existing 508 Standards §1194.3(f) in that the exception was narrowed to apply only to those status indicators and operable parts that are available from maintenance spaces. Since it is the usual case that rack-mounted equipment is operated remotely, this change makes it clear that the Revised 508 Standards do not preclude this usual business practice.

In response to the commenters’ requests seeking expansion of proposed E202.4 for a complete “back office exemption,” the Board, after careful consideration, declines to make a change. People with disabilities frequently perform “back office” IT work and the majority of these job functions can be addressed with assistive technology. The Board is sensitive to concerns raised by some commenters, that ICT will often not be accessible when there is a physical problem or failure with the equipment. We note that we did not provide a complete exception for maintenance functions in the proposed rule, as it only intended the requirements concerning the accessibility of operable parts to apply to the normal operation of ICT by end-users. In order to ensure clarity in the final rule, in addition to the edit to the definition for “operable part” mentioned above, we have revised 407.1 in the final rule to make the application of these Standards to normal operation explicit. This is discussed in further detail below in Section IV.F. (Summary of Comments and Responses on Other Aspects of the Propose Rule – Chapter 4: Hardware – 407). In addition, we note that the exception for maintenance spaces which are frequented only by service personnel for maintenance, repair, or occasional monitoring is consistent with the ADA and ABA Accessibility Guidelines. 36 CFR part 1191 (stating that “Spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment shall not be required to comply with these requirements or to be on an accessible route”). Therefore, in the final rule, we have not made any changes to proposed E202.4, with the exception of its renumbering (final E202.5).

E203 Access to Functionality

The NPRM proposed to require that all ICT be accessible to and usable by individuals with disabilities, either directly or by use of assistive technology. This section was based on the existing 508 Standards (36 CFR §§1194.1 and 1194.2(a)). We received ten comments regarding this proposed requirement; three individuals, a disability advocacy organization, three trade associations, and three ICT companies.

An ICT company and an ICT trade association expressed concern with the proposed requirements and requested clarification on the minimum required abilities assumed for operational functions of certain products. The specific example provided was that it would be very difficult for a person who is blind to have a job operating a large volume xerographic services machine, because that person would not be able to visually monitor the complex equipment. An ICT subject matter expert in the field of geographic information systems raised concerns and recommended that the Board expand the exceptions in proposed E203 to include rich content like maps that represent information and data visually because they do not know of any other means to convey the information and data. Another commenter raised concerns about the inability to make inherently visual representations, such as motion pictures, fully accessible to a person who is blind even when assistive technologies are used. Finally, a disability advocacy organization recommended that this provision be amended to require that people with disabilities be provided training to evaluate, install, and configure assistive technology.

The Board has reviewed the comments received and find that the commenters’ concerns requesting clarification of the minimum required abilities for operation functions are misplaced. The 508 Standards apply to all ICT; deliberately, they do not make assumptions regarding physical, cognitive, or sensory abilities associated with performing job tasks. Presumably, a job operating a large volume copier would include the requirement to confirm by visual inspection that output hard copy was correct. The fact that there may be specific performance requirements for certain jobs is not a sufficient justification to exempt the core functions of the ICT from the Revised 508 Standards. In response to the commenter’s request for an exception for ICT that cannot be adequately represented through assistive technology, the Board notes that the intent of the 508 Standards is to provide comparable access. In the Board’s experience, the scope and nature of accessibility improves over time as technology advances. The Board has concluded that these issues are well addressed by the technical and functional performance requirements, and has declined to narrow the scoping or expand the available exceptions as suggested. Finally, in response to the request that the final rule require training, we find that such a requirement is outside the scope of these Standards and have declined to make this suggested change.

We have considered the commenters’ suggestions regarding section E203, but as described above, found no reason to make substantive changes. We have made a few editorial changes to E203 in the final rule for clarity. The most significant of these editorial changes is in the title of E203.2, which is now “User Needs” instead of “Agency Business Needs.”

E204 Functional Performance Criteria

The NPRM proposed that where the requirements in Chapters 4 and 5 do not address one or more features of ICT, the features not addressed shall conform to the functional performance criteria (FPC) in Chapter 3. Many comments were received regarding the individual FPC referenced in proposed E204. As the technical criteria are provided in Chapter 4, these comments are addressed below in Section IV.F. (Summary of Comments and Responses on Other Aspects of the Proposed Rule – Chapter 4: Hardware). Some of the concerns with the FPC for limited vision, limited hearing, and limited cognition are addressed in the Major Issues section of this preamble, at Section III.E. (Major Issues – Functional Performance Criteria).

We identified 22 comments concerned with proposed E204. Several of these comments indicated that the applicability of proposed E204.1 should be further clarified. An ICT company asserted that as written, proposed E204.1 could be interpreted as requiring the applicability of the FPC to be considered on a feature-by-feature basis. Specifically, this commenter explained that for software products that typically include a long list of “features,” such a feature-by-feature evaluation would be quite onerous. Additionally, one commenter provided suggested text for inclusion in advisories in the final rule.

We concur with the commenter that proposed E204.1 could be misinterpreted. We intended for the functionality of the ICT to be considered holistically, and not on a feature-by-feature basis. The final rule revises this requirement and substitutes “functions” for “features,” to avoid this confusion. The Board regards this change as editorial, as it seeks to clarify the intent of the proposed provision, and makes the text of the provision consistent with the chapter title and phrasing used elsewhere in the Revised 508 Standards. In response to the commenter’s request for advisories, as described above, advisories are no longer published in the final rule; however, the Board intends to provide further guidance on the applicability of final E204.1 in its technical assistance.

E205.2 Public Facing

Three commenters raised concerns with proposed E205.2, specifically in regards to the application of this provision to social media platforms. One individual questioned whether social media constituted public-facing content under proposed E205.2. Another individual questioned whether third-party content added by members of the public to agency controlled social media sites would constitute public-facing content under proposed E205.2. The third commenter, a disability advocacy organization, recommended that agencies be precluded from using any social media platforms that are not compliant with the final rule.

In the NPRM preamble, we described public-facing content and included social media pages as an example of such content. 80 FR 10880, 10893 (Feb 27, 2015). The Board refers commenters on this topic to the discussion in the NPRM, as its position on this matter has not changed. Additionally, we note that under Section 508 of the Rehabilitation Act (as amended), agencies have responsibility for all content that they develop, procure, maintain, or use. 29 U.S.C. 794d. Agencies are therefore responsible for third-party content added to and maintained on their sites, and will need to develop policies and practices to ensure the accessibility of that third-party content. This is consistent with other policies and practices agencies employ regarding personally identifiable information, security, obscenities, or other concerns presented by third-party content. If an agency invokes an exception and uses inaccessible ICT to provide information and data to the public, the statute requires that the agency provide the same information and data to individuals with disabilities by an alternative means. Id. (stating that “the Federal department or agency shall provide individuals with disabilities covered by paragraph (1) with the information and data involved by an alternative means of access that allows the individual to use the information and data”). Under current law, an agency is not prevented from using an inaccessible social media platform under a provided exception, as long as the agency provides individuals with disabilities an alternative means of accessing the same information and data. Accordingly, the Board has not made a change to this requirement.

E205.3 Agency Official Communication

In addition to the changes made to E205.3, discussed above in Section III.A. (Major Issues – 508 Standards: Covered Electronic Content), a commenter expressed confusion and questioned what the difference was between a questionnaire and a survey. The Board notes it was not our intention for this item to refer to two different types of communication. Therefore, in the final rule we have amended this item from “questionnaire or survey” to “survey questionnaire.”

E205.4 Accessibility Standards

The NPRM generally proposed to replace the existing technical standards for Web, software, applications, and electronic content with incorporation by reference of the Level A and Level AA Success Criteria and Conformance requirements of WCAG 2.0, which appear at proposed E205.4. There is no direct analogy in the WCAG 2.0 Success Criteria for section 1194.22(d) of the existing 508 Standards, which states: “documents shall be organized so they are readable without requiring an associated style sheet.” 36 CFR §1194.22(d).

Three individual commenters expressed concern that eliminating the requirements of section 1194.22(d) of the existing 508 Standards would significantly reduce the level of user control over customized styling (including features such as magnification, color, and contrast), which is critical to some users with low vision. Section 1194.22(d) of the existing 508 Standards requires documents to be organized so that they are readable without an associated style sheet. This enables persons with low vision to remove style sheets from Web pages so that they can change aspects of text style, such as spacing, font, color, borders, and width of reading areas. A disability advocacy organization indicated that replacing the current requirement with referenced provisions of WCAG 2.0 Levels A and AA would result in scenarios problematic for some users with low vision, such as limiting the maximum required magnification to 200 percent while permitting horizontal scrolling (WCAG Success Criteria 1.4.4). In addition, WCAG 2.0 Levels A and AA will provide for a sole fixed contrast setting instead of permitting user control over the degree of contrast (WCAG Success Criteria 1.4.3), which presents a challenge for some individuals.

We have considered commenter concerns regarding the loss of user control over customized styling, and acknowledge that some individuals who elect to use ICT without assistive technology may be affected by the loss of the requirements in section 1194.22(d) of the existing 508 Standards. However, the Board finds that the existing section 1194.22(d) requirement is detrimental to the use of assistive technology, which has well-supported the use of stylesheets for several years. All users, including users of screen reading software and other assistive technology, rely on the presence of Cascading Style Sheets (CSS) in order to format text for a variety of devices and Web browsers. In complex Web applications, CSS is also used dynamically to hide content that is not relevant to the user’s current transaction and to selectively show content based on the user’s choices. The need for content authors to maintain support for section 1194.22(d) had the effect of slowing the adoption of robust accessible Web content. Further, mainstream adoption of contemporary technologies (for example, ARIA or Accessible Rich Internet Applications) depends on CSS being supported. Implementation of these newer, more advanced approaches is not compatible with 1194.22(d). For these reasons, the Board declines to reintroduce the requirements of section 1194.22(d) in the Revised 508 Standards. The Board is also not persuaded that amending the language of select WCAG 2.0 Success Criteria, such as 1.4.4 (Resize Text) is a prudent approach. Requiring, for example, 400 percent magnification might allow a select number of users with low vision to use ICT without assistive technology; however, the overall consistency of the requirements, an important goal of harmonization with international standards, would be lost.

Another individual commenter suggested that the technical requirements relating to text featured in software under proposed 502.3.6 be made applicable to text in all content generally, under E205.4. The Board is not persuaded to adopt the recommendation to apply proposed 502.3.6 to all content, including Web content. Adding such a requirement to the WCAG 2.0 criteria would create harmonization issues internationally as well as among Federal agencies. The technical requirement for “boundary of text rendered on the screen” is a detail that is readily available in client-side software, but is not always available in a Web browsing environment.

The Board carefully considered the public comments and it finds that incorporation of the WCAG 2.0 standard, without modification, adequately addresses the needs of the majority of users with low vision. The Board also notes that W3C® has formed a task force charged with investigating the issue of accessibility requirements related to low vision and with creating recommendations. Low Vision Accessibility Task Force, http://www.w3.org/WAI/GL/low-vision-a11y-tf/, (last visited Aug. 23, 2016). The Board is following that work and may incorporate their recommendations in future rulemaking.

Conforming Alternate Version

The NPRM proposed that a Web page could 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.” Because WCAG 2.0 always permits the use of conforming alternate versions, the Access Board sought input on whether there were any concerns that the 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, and whether the Board should restrict the use of conforming alternate versions beyond the explicit requirements of WCAG 2.0. NPRM, 80 FR at 10897.

Eleven commenters responded to the proposed provision allowing conforming alternate versions. Seven of the commenters (four ICT companies and trade associations, two disability advocacy organizations, and one individual) supported the approach to conforming alternate versions proposed in the NPRM. Four commenters (two individuals, one state government agency, and an ICT trade association) opposed the approach from the NPRM.

Under WCAG 2.0, in order for a non-conforming Web page to be included within the scope of conformance by using a conforming alternate version, the alternate version must: conform at the designated level (i.e., WCAG 2.0 Level AA success criteria); provide the same information and functionality in the same language; and be as up-to-date as the non-conforming content or page. In addition to these requirements, at least one of the following must be true: (1) the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism; (2) the non-conforming version can only be reached from the conforming version; or (3) the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version. W3C®, Understanding WCAG 2.0: Understanding Conforming Alternate Versions, Dec. 2012, http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conforming-alt-versions-head.

The W3C® explains that providing a conforming alternate version is intended to be a “fallback option for conformance to WCAG and the preferred method of conformance is to make all content directly accessible.” Id. While some commenters expressed specific concern that the use of conforming alternate versions could still create separate, unequal Web sites for people with disabilities, the Access Board has concluded that when the requirements for a conforming alternate version are viewed in conjunction with the W3C®’s guidance, it is clear that they are meant to be used only in the limited circumstances where the primary Web page or content cannot be made accessible for all users, typically due to a technical or legal limitation.

In the Revised 508 Standards, the Board has decided to retain the incorporation by reference to WCAG 2.0’s conforming alternate version, as proposed in the NPRM. WCAG 2.0’s conforming alternate versions provision provides a much clearer standard than the vague language of the existing 508 Standards. Section 1194.22(k) of the existing 508 Standards states that “[a] text-only page, with equivalent information or functionality, shall be provided to make a Web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.” While on its face, the existing 508 Standards may seem to more strictly limit the use of alternate pages, in practice it is difficult to determine when compliance cannot be accomplished in any other way, and thus, it is easy for agencies to justify the use of text-only pages. Such alternate text-only sites often are poorly maintained, lack the same information and functionality available on the non-conforming Web page, and have out-of-date content. As explained above, the WCAG 2.0 requirement for a conforming alternate version significantly exceeds the expectations for text-only pages, and would not permit these deficiencies. Therefore, the Board has concluded that agencies using the Revised 508 Standards for conforming alternate versions under WCAG 2.0 will not create Web sites that suffer from these same problems, because the requirements for conforming alternate versions under WCAG 2.0 are so rigorous.

Despite WCAG 2.0’s requirement that conforming alternate versions follow far more robust standards than the text-only pages permissible under the existing 508 Standards, some commenters have expressed concern that agencies may choose to use conforming alternate versions even in circumstances in which compliance could be achieved on the primary Web page. The Access Board expects that the stringent requirements for the use of conforming alternate versions under the Revised 508 Standards will prevent this abuse. The Board expects that an agency that decides to use a conforming alternate version of a Web page as opposed to making the main page accessible will typically do so when, as the W3C® explains, certain limited circumstances warrant or mandate their use. For example, W3C® has noted that a conforming alternate version may be necessary: (1) when a new emerging technology is used on a Web page, but the new technology cannot be designed in a way that allows assistive technologies to access all the information needed to present the content to the user (e.g., virtual reality or computer-simulated reality); (2) when it is not possible to modify some content on a Web page because the Web site owner is legally prohibited from modifying the Web content; or (3) to provide the best experience for users with certain types of disabilities by tailoring a Web page specifically to accommodate those disabilities. Id.

The Access Board does not anticipate that an agency would choose to maintain a separate conforming alternate version of a Web page for people with disabilities without a compelling reason, as maintaining separate sites in most, if not all circumstances, would be expensive and overly time-consuming. The Board notes that meeting the stringent criteria for a conforming alternate version under WCAG 2.0 is, in most cases, impractical if the primary page can be made accessible. The Access Board further notes that agencies will have a disincentive to allow conforming alternate versions of Web pages to become out-of-date, as this blatant failure to meet the requirements of WCAG 2.0 for conforming alternate versions could be evidence of noncompliance under the Revised 508 Standards. If the Board finds that use of conforming alternate versions, in practice, does not provide people with disabilities a Web experience equivalent to that of people without disabilities, the Board will consider whether rulemaking is appropriate to restrict the use of conforming alternate versions.

E206 Hardware

We received one comment on this provision from a disability advocacy organization which asserted that proposed E206 did not sufficiently include mobile phones and tablets. The Board disagrees with the commenter and finds that these products are hardware, and are therefore subject to the hardware requirements in Chapter 4 of the final rule.

E207 Software

We received one comment on this provision from a disability advocacy organization that indicated that proposed E207 did not sufficiently encompass mobile applications. The Board disagrees with the commenter and finds that such mobile “apps” are software applications and are therefore subject to the software requirements in Chapter 5 of the final rule.

The W3C® has formed a task force charged with investigating and making recommendations on the issue of accessibility requirements specific to mobile content. Mobile Accessibility Task Force, http://www.w3.org/WAI/GL/mobile-a11y-tf/ (last visited Aug. 23, 2016). The Board is following that work and may incorporate its recommendations in future rulemaking.

Additionally, the final rule contains an exception to E207.1 and E207.2 that excludes assistive technology software that supports the accessibility services of the platform. This exclusion appeared in the proposed rule as an exception to proposed 501.1. One commenter noted that the exception might be overlooked until after assistive technology was evaluated for conformance to WCAG 2.0. In response to the commenter’s concern, in the final rule, the Board has moved this exception from chapter 5 to E207.1 and E207.2. The Board regards the relocation of this exception as an editorial clarification since we never intended for assistive technology to be reviewed against the WCAG 2.0 Success Criteria. Moving the exception from Chapter 5 to Chapter 2 makes this clear, but requires that the exception be repeated in multiple places.

C. 255 Chapter 1: Application and Administration

Chapter 1 of the Revised 255 Guidelines includes a general section, defines equivalent facilitation, addresses application of referenced standards, and provides definitions of terms used in the guidelines. Most of the comments received on 508 Chapter 1, discussed above in Section IV.A. (Summary of Comments and Responses on Other Aspects of the Proposed Rule — 508 Chapter 1: Application and Administration), are also applicable to 255 Chapter 1. These are noted below with the applicable section numbers. Additionally, we have made minor changes specific to the 255 Chapter 1 in response to comments to improve clarity, accuracy, and ease of use. These changes are described below.

C101.1 Purpose

An ICT trade association raised a concern that inclusion of the phrase “and related software,” could be interpreted to go beyond the scope of Section 255 to cover software other than that essential to telecommunications functions. The Board agrees with the commenter that the inclusion of this phrase is problematic. The Communications Act defines telecommunications equipment to include “software integral to such equipment including upgrades.” 47 U.S.C. 153(45). The FCC, in its 1999 Report and Order implementing its regulations under Section 255, went on to find that customer premises equipment likewise includes software integral to the operations and functions of the equipment. FCC 99-181, adopted July 14, 1999; Released Sept. 29, 1999, pp. 41-42. The Board has concluded that the inclusion of the term “and related software” in proposed C101.1 is unnecessary and confusing, and has deleted it from the provision in the final rule. The Board has also made changes to several definitions in the final rule, discussed below, to conform to the terminology of Section 255 and the FCC implementing regulations.

C101.3 Conventional Industry Tolerances

For the same reasons discussed above in Section IV.A. (Summary of Comments and Responses on Other Aspects of the Proposed Rule – 508 Chapter 1: Application and Administration – E101.3), we have added “with specific minimum or maximum end points” to C101.3 in the final rule.

C102 Reference Standards

This section has been significantly reorganized and revised in the final rule. The general statements in the first two sentences regarding the application of referenced standards remain essentially unchanged from the proposed rule. However, the subsequent provisions in the proposed rule that expressly IBR the ten referenced standards into the Revised 255 Guidelines (i.e., proposed C102.2 – C102.10) have been moved in the final rule to a centralized IBR section – new Chapter 7 (Referenced Standards). This reorganization of IBR provisions was made to comply with OFR regulations that govern incorporations by reference. See 1 CFR part 51. Comments related to proposed incorporations by reference into the Revised 255 Guidelines are discussed below in Section IV.I (Summary of Comments and Responses on Other Aspects of the Proposed Rule – Chapter 7: Referenced Standards).

C103.4 Defined Terms

In addition to the corresponding changes made to C103.4 that were described above in the Section IV.A. (Summary of Comments and Responses on Other Aspects of the Proposed Rule – 508 Chapter 1: Application and Administration – E103.4), we have made a few additional changes based on public comments that are only applicable to the Revised 255 Guidelines.

We added a definition for “manufacturer” to final C103.4, and amended the definitions for “customer premises equipment” and “telecommunications equipment” to conform to the language of Section 255 and the FCC implementing regulations.

Finally, we received comments asking why the definitions for “closed functionality” and “ICT” in proposed C103.4 included examples that were not telecommunications equipment. The Board concurs with commenters’ concerns that the examples included with those definitions in proposed C103.4 were confusing because they were not telephony products, and thus not within the scope of the 255 Guidelines. Therefore, in the Revised 255 Guidelines the Access Board has amended the definitions for “closed functionality” and “ICT” by removing the examples.

D. 255 Chapter 2: Scoping Requirements

Chapter 2 of the Revised 255 Guidelines addresses application and scoping. Most of the comments received on 508 Chapter 2, discussed above in Section IV.B. (Summary of Comments and Responses on Other Aspects of the Proposed Rule – 508 Chapter 2: Scoping), are also applicable to 255 Chapter 2. The applicable 255 Chapter paragraph numbers are referenced below. Additionally, we have made minor changes specific to the Revised 255 Chapter 2 in response to comments to improve clarity, accuracy, and ease of use. These changes are described below.

C201.5 Design, Development, and Fabrication

An ICT subject matter expert was concerned that proposed C201.5 did not include the language from existing §1193.23(b) that directs telecommunications manufacturers to consider using people with disabilities in the design and development process. As the Board explained in the preamble of the NPRM, we did not retain this provision in the Revised 255 Guidelines because “consider” is not mandatory language and therefore is more appropriate for inclusion in advisory material providing guidance on best practices. 80 FR 10912 (Feb. 27, 2015). The Access Board is not persuaded by this commenter that the final rule should include this requirement and, as discussed above, advisory material is not included in the final rule. Therefore, this requirement has not been changed in the final rule.

C205 Software

In the final rule we have relocated an exception that excludes assistive technology software from proposed 501.1 to final C205. This relocation was necessary to avoid confusion and is described in detail above in Section IV.B. (Summary of Comments and Responses on Other Aspects of the Proposed Rule – 508 Chapter 2: Scoping – E207).

E. Chapter 3: Functional Performance Criteria

Chapter 3 of the final rule contains functional performance criteria, which are outcome-based provisions that apply when applicable technical requirements (i.e., Chapters 4 and 5) do not address one or more features of ICT. All sections of this chapter are referenced by scoping provisions in Revised 508 Chapter 2 and in Revised 255 Chapter 2. The functional performance criteria are also used to determine equivalent facilitation under both the Revised 508 Standards and the Revised 255 Guidelines (final E101.2 and C101.2).

We have made minor changes to Chapter 3 in response to comments to improve clarity, accuracy, and ease of use. These changes are described below. In addition, two of the provisions in the final rule, 302.2 and 302.5, have been significantly amended in response to comments and a new provision, and 302.9 has been added to the final rule. These provisions are discussed above in Section III.E. (Major Issues – Functional Performance Criteria).

New Functional Performance Criteria Recommended

We received two comments (a coalition of disability rights organizations and an academic research institution) suggesting that the Board add three new functional performance criteria (FPC) to the final rule addressing depth perception, the use of ICT without gestures, and the use of ICT without human skin contact. The purpose of these recommendations was to anticipate possible developments in technology that would require the use of functions not currently addressed in the Revised 508 Standards and 255 Guidelines. Each of these suggestions are discussed below.

The requested addition for a FPC addressing depth perception would require that one visual mode of operation be provided that does not require binocular perception of depth. This commenter did not indicate what functions of ICT would require binocular perception of depth, or where this criterion might apply, other than to suggest that at some point in the future binocular perception of depth might be required to access functions of some ICT.

Similarly, the addition of a “use of ICT without gestures” FPC was suggested by a commenter without a rationale for where the criterion might be used. The functional limitations suggested by the criterion are already addressed in the FPC for limited vision. For example, a gesture-based system would not be usable by persons with no vision, since they would be unable to perceive where their gestures were to be located or performed without vision. Therefore, providing a mode of operation that does not require user vision would address those functional needs. The commenter did not apply this suggested FPC to any existing technology or technology known to be in development.

Finally, a commenter suggested a new FPC for the use of ICT without human skin contact. It is the Board’s understanding that this suggestion is not technically feasible with modern touch screens which rely on capacitive touch. Capacitive touchscreen displays rely on the electrical properties of the human body to detect when and where on a display the user touches. Because of this, capacitive displays can be controlled with very light touches of a finger and generally cannot be used with a mechanical stylus or a gloved hand. See “What is ‘capacitive touchscreen’?”, http://www.mobileburn.com/definition.jsp?term=capacitive+touchscreen (last visited Aug. 3, 2016). While resistive, or pressure sensitive touch screens, are available for such functions as signing an ATM screen, they can only recognize one activation point at a time. This technical limitation precludes the use of resistive touch screens for common gestures used with personal devices (for example, pinch-to-zoom on a smart phone). See “Okay, but how do touch screens actually work?” at Science Line, the Shortest Distance Between You and Science, http://scienceline.org/2012/01/okay-but-how-do-touch-screens-actually-work/, (last visited Aug. 3, 2016). Most touch screen technology today uses capacitive touch.

After consideration, the Board declines to adopt any of the suggested FPC. No specific examples of real-world applications were provided for any of the suggested FPC. The suggested FPC would not have any close correlation to technical criteria in the final rule, and the access barriers theoretically covered by the suggested FPC are substantially addressed by the other FPC in the final rule. Additionally, the suggested FPC lack the necessary research and public input to determine the need and benefit of such additional criteria. Therefore, at this time, the Board declines to adopt the commenters’ suggested functional performance criteria.

Section 301 General and 302 Functional Performance Criteria

We received a number of comments from a variety of stakeholders who sought clarification from the Board on the relationship between the FPC and the technical requirements. This issue has been extensively discussed and commented on during the history of this rulemaking. In the 2010 ANPRM, the Board recommended that for ICT meeting the technical requirements, the FPC did not need to be considered at all. After numerous commenters opposed this approach as being too limiting, and likely to lead to the procurement of ICT that is not actually usable by individuals with disabilities, the Board proposed in the 2011 ANPRM that ICT must conform to the FPC, even when the technical criteria are met. In response to the 2011 ANPRM, commenters noted that required conformance to the FPC would be unduly burdensome and costly, and would greatly increase the time for accessible ICT procurement, without notably improving the likelihood that accessible ICT would be procured. Accordingly, in the NPRM, we proposed that the FPC need only be met when the features of the ICT are not addressed by the provisions in Chapters 4 or 5.

Fifteen general comments were received on Chapter 3. These comments encompassed a wide variety of responses to the proposed FPC. Four commenters from disability advocacy organizations praised the approach taken by the Board in the proposed rule of requiring compliance with the FPC when the technical requirements in Chapters 4 and 5 are not applicable. Two commenters, one from an ICT trade association, and one from coalition of disability rights organizations, suggested that we adopt an approach similar to that taken in EN 301 549, where the FPC are expressed using very broad and conditional language. Three commenters, one from an accessible ICT services provider, one from a state/local agency, and one ICT company, urged the Board to reinstate the proposed approach from the 2011 ANPRM and require the use of the FPC and the technical requirements for all ICT. One commenter who self-identified as an individual with a disability recommended that we revise the language of the FPC to focus only on functional limitations, and not use disability-specific terminology. All other commenters approved of the approach proposed in the NPRM of identifying specific functional limitations using disability-specific language and noted that this approach was understandable, usable, and important in providing context for accessible solutions. Along with this support, one commenter from an ICT trade association suggested that the Access Board change the approach of describing the FPC to necessary to ensure accessibility, rather than providing more technical requirements. In the final rule, we have retained the approach proposed in the NPRM and provide disability-specific context for the functional performance criteria.

Finally, five commenters, two from disability rights organizations, two ICT companies, and an ICT trade association, requested further clarification on our proposed approach. The most specific comment came from an ICT trade association which expressed confusion about how to interpret and apply the FPC in Chapter 3 for individuals with low and limited vision in conjunction with the scoping requirement for access to “all ICT functionality” as required by proposed E203 and C201.3. This commenter requested clarification on how persons with limited or low vison were supposed to access functions on ICT such as copiers, for example, when checking copy output quality, or attempting to change paper trays. The comment also raised the concern that some functions, by their nature, such as visual inspection for copy quality, assume a certain level of ability. In response, in the final rule, we have revised the text of the provision for operable parts (final 407.1) to clarify that maintenance functions are separate and distinct from normal operations and are not covered by the provisions in Chapters 3 and 4. Only the functions of ICT used in normal operation must be made accessible. The discussion of 407.1 is found below in Section IV.F. (Summary of Other Comments and Responses on Other Aspects of the Proposed Rule – Chapter 4: Hardware). We also retained the proposed provision on status indicators (final 409.1), which requires that information on the status of ICT hardware, such as the need for maintenance, be provided visually, and by touch or sound. The discussion on 409.1 is found below in Section IV.F. (Summary of Comments and Responses on Other Aspects of the Proposed Rule – Chapter 4: Hardware – 409).

After review of all of these comments, we have decided to retain the proposed approach in the final rule of requiring the FPC where the requirements in Chapters 4 and 5 do not address one or more functions of ICT. The Board has also retained the requirement that the FPC are used when evaluating an alternative design or technology under equivalent facilitation (final E101.2 and C101.2). The approach taken in the final rule reflects the longstanding, established practice in the Federal Government of the application of the FPC when technical requirements do not sufficiently address the features of the particular ICT at issue. It also allows for balance between providing for accessible ICT while encouraging flexibility and innovation in the development of accessible ICT. We did make changes to some of the individual FPC. The major changes are discussed above in Section III.E. (Major Issues – Functional Performance Criteria); other changes are discussed below.

302.1 Without Vision

We received three comments on this section. One of the commenters was from a disability rights organization, one was from a coalition of disability rights organizations, and one was an individual who self-identified as having a disability. One commenter commended us on the functionality and usability of the FPC addressing the functional needs of users with no vision, and had no recommendations for change. The remaining two commenters, a self-identified individual with a disability and a disability rights organization, expressed concern that the requirement was too limited and could lead some agencies to provide only an audio solution, which would not provide access for individuals who are deaf-blind. These commenters recommended that the Board add language requiring the support of auxiliary aids, such as refreshable braille devices, in order to ensure that all potential users without vision could have access. In the final rule, we have declined to modify the criterion because mandating a specific solution such as a refreshable braille keyboard would restrict the development of other potential solutions and would be costly. The Board concluded that retaining the NPRM’s open ended approach is the best way to maximize potential solutions for this population of users. In addition, the Revised 508 Standards work in tandem with customized solutions developed as appropriate to accommodate the needs of individuals under Sections 501 and 504 of the Rehabilitation Act. The Revised 508 Standards 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 (final E203).

302.3 Without Perception of Color

We received four comments on this provision. All four commenters generally approved of the proposed provision. Three of these commenters, one from an ICT trade association and two ICT companies, requested guidance on allowable alternatives to color. In response, the Board notes that the supporting materials for the WCAG 2.0 Success Criteria contain technical assistance on the use of color. The remaining commenter, a coalition of disability rights organizations, recommended that we add the word “visual” to clarify the mode of operation. We agree with this comment and have added the word “visual” to describe the mode of operation in the final rule.

302.6 Without Speech

In response to a comment made by a coalition of disability rights organizations, the Board added the phrase where “speech is used for input, control or operation” to clarify in the final rule when this FPC is applied.

302.7 With Limited Manipulation

Three commenters (an accessible ICT services provider, a coalition of disability rights organizations, and an ICT company) requested changes to proposed 302.7. The accessible ICT services provider asserted that the provision was insufficient to address the needs of users with limited manipulation in a touch screen environment because it did not address motions that required more than one finger, such as a pinch zoom gesture, or a twisting motion that required only a single control, but might not work for individuals with some types of limited manipulation abilities. A provision in Chapter 4 addresses this concern by requiring at least one mode of operation operable with one hand that does not require tight grasping, pinching or twisting of the wrist (final 407.6). In addition, there is an exception for input controls for devices for personal use that have input controls that are audibly discernible without activation and operable by touch (final Exception 407.3). The ICT company recommended that we reference the FPC from EN 301 549 clause 4.2.7 “Usage with limited manipulation or strength.” We decline to adopt the recommendation to use the language in EN 301 549 because it combined the functions of limited manipulations with limited strength, which the Board has determined are distinct functions that should be treated separately. Finally, the coalition of disability rights groups recommended that we clarify the text of the provision to make it easier to understand. In response to this comment, we have added the phrase “simultaneous manual operations” to clarify the limitation on this FPC.

F. Chapter 4: Hardware

Chapter 4 contains requirements for hardware that transmits information or has a user interface. Examples of such hardware include computers, information kiosks, and multi-function copy machines. Chapter 4 in the final rule has been substantially reorganized from the proposed rule in response to comments to improve clarity, accuracy and ease of use. The changes are described below.

401 General

An ICT trade association asserted that the Twenty-First Century Communications and Video Accessibility Act (CVAA) was the latest word from Congress, that the Board should avoid mandating technical requirements, and that the Board was exceeding its jurisdiction. As discussed above in Section I.A. (Executive Summary – Purpose and Legal Authority), both the 508 Standards and the 255 Guidelines are within the Board’s purview, and the Board has not introduced any conflict with the CVAA.

402 Closed Functionality

ICT with closed functionality has limited functionality by design or choice, which limits or prevents a user from adding assistive technology. The NPRM proposed that ICT with closed functionality with a display screen must be capable of providing speech output (proposed 402).

We received numerous comments on this section. One commenter, a coalition of disability rights organizations, expressed confusion over the concept of closed functionality in software. Closed functionality as it relates to software is discussed at length in Section IV.G (Summary of Comments and Responses on Other Aspects of the Propose Rule – Chapter 5: Software) of this preamble, below, and is not addressed here. The provisions in Chapter 4 only pertain to closed functionality with regard to hardware. The same commenter also recommended that the provisions related to closed functionality be separated into a standalone chapter. The Board has not accepted this recommendation. We proposed that approach in the 2010 ANPRM and it was overwhelmingly rejected by commenters who disagreed with the approach and found it awkward to use. Therefore, in the final rule we have retained the approach from the NPRM.

This commenter, and many others representing disability rights organizations and ICT companies, also expressed concern with the structure and organization of the various provisions related to ICT with closed functionality. One commenter, a disability rights organization, suggested that provisions on transactional outputs (proposed 409) were in the wrong place and recommended that we combine the section for transactional outputs into the section on closed functionality as a subset of speech-output enabled ICT (final 402.2). Several commenters from industry (a trade association for information technology companies and a large manufacturer of business software and hardware) suggested edits to speech-output enabled ICT consistent with Section 707.5.2 of the 2010 ADA Standards.

The Board agrees that the clarity and coherence of these provisions could be improved by reorganization and has significantly revised the final rule to relocate requirements related to hardware with closed functionality to 402. We moved two exceptions that address audible output on devices with closed functionality from the proposed section on transactional outputs into the section on speech output in the final rule (proposed 409.1 Exceptions 1, 3; final 402.2 Exceptions 5, 6) and we have deleted an exception for duplicative information as unnecessary (proposed 409.1 Exception 2). Additionally, the Board has revised the provision for transactional outputs to clarify that the speech output shall be required to provide all information necessary to verify a transaction (proposed 409.1; final 402.2.2).

We also received numerous comments on technical requirements related to closed functionality. We received comments from copier manufacturers who suggested that a speech output requirement was not needed for any ICT with closed functionality that provides copying functions, because the needs of users with visual impairments were already addressed by provisions in the NPRM requiring magnification (proposed 302.2) and supporting the use of assistive technology (proposed E203). The Board disagrees with this suggestion as we have determined that it is too restrictive and has the potential of leading to a lack of access for users with visual limitations. Therefore, we have not made this recommended change in the final rule (final 302.2). If ICT is capable of attaching assistive technology, then by definition it is not considered to have closed functionality, and the provisions on speech-output for closed functionality do not apply (proposed E103; final E103; proposed C103; final C103). In addition, we have concluded that magnification alone may be insufficient to address the functional needs of users with disabilities, and the functional performance requirement for limited vision has been revised accordingly (proposed 302.2; final 302.2; and Section III.E.1. (Major Issues – Functional Performance Criteria – Limited Vision and Limited Hearing).

Numerous commenters (disability advocacy organizations, individual commenters, and industry) recommended that the Board add a requirement to explicitly address the needs of individuals who are both deaf and blind. At the present time, the only technology that addresses these concerns is in the form of dynamic braille displays, which are prohibitively expensive, costing as much as $3,000 to $5,000 to produce a single line of refreshable braille, and up to $55,000 to produce a full page of refreshable braille, and require significant modifications in order to be incorporated into existing ICT. The Board has concluded that the many examples of ICT with speech output currently available with minimal hardware requirements are sufficient and appropriate to meet the needs of this population, and accordingly no language has been added on this issue.

We received numerous comments on user control from industry, requesting that we clarify when a particular language, such as English was required (proposed 402.2.1). We have determined it is unnecessary to address the use of languages other than English because business requirements would dictate what languages would be used for interface and speech output. If the interface of the ICT was in a language other than English, then the speech output would also be in that language. Similarly, if the interface does not support multiple languages, then the speech output would not have to support multiple languages.

Several commenters (a coalition of disability rights organizations and an academic research institution), supported the requirement for stopping and resuming audio (proposed 402.2.1), stressing that such a feature is essential when audio information is lengthy. An ICT company recommended that the Board reference the provision of EN 301 549 clause 5.1.34. The Board disagrees with this recommendation because the EN provision duplicates the proposed requirement, and also includes additional notes that are confusing and could be interpreted as inconsistent with the basic requirement. The provision in the final rule is renumbered due to restructuring, but is otherwise unchanged from the proposed rule (proposed 402.2.1; final 402.2.4).

We received a significant number of comments on the proposed provision requiring braille instructions on hardware. Five commenters from industry, (three ICT trade associations and two ICT companies), all stated that it would be difficult for global manufacturers to use braille, and suggested that the Board follow the example in EN 301 549 and require tactile indicators instead. On the other side of the issue, three commenters (a coalition of disability rights organizations, a state/local government, and an academic research institution) all supported the proposed provision, and requested that we retain it (proposed 402.2.2; final 402.2.5).

Based on the prior experience with requiring braille instructions under the ADA and ABA Accessibility Guidelines mentioned above, and the favorable response for tactile instructions, the Board has decided to retain the provision. The braille instructions need not be lengthy, so this is an appropriate requirement for copiers and similar types of ICT, in helping provide equal access to users with low vision. We have declined to follow the approach of providing tactile indicators as indicated in EN 301 549, clause 8.5 “Tactile indication of speech mode” in v.1.1.2 (2015-04) since the EN provision as written allowed for the use of braille, but also permits other unspecified tactile indicators. Instead, we have retained the approach from the NPRM, which specifies a known and predictable method of communicating tactile instructions (final 402.2.5).

Industry commenters also objected to the proposed requirement for English braille, arguing that global markets may spur the manufacture of devices for markets where English is not used as the primary language. In response to this concern, we have revised the final rule to specify the use of contracted braille instead of Grade 2 (English) braille. The Board has also modified the reference to provision 703.3.1 of the ADA and ABA Accessibility Guidelines (proposed 402.2.2; final 402.2.5). Finally, several commenters from industry (ICT trade associations and ICT companies), and a coalition of disability rights organizations asserted that personal use devices do not need braille instruction for initiating the speech mode, and noted that the physical space available on a personal use device would be insufficient to accommodate braille instructions. In response to these comments, we have added an exception from the braille requirement for personal use devices (final 402.2.5 Exception).

The NPRM included a provision requiring volume control for ICT that provides private listening (proposed 402.3.1). Commenters from both industry and disability advocacy organizations recommended that this provision should be consistent with the provision addressing magnetic coupling (proposed 410.3). The Board agrees that the regulatory language could be strengthened to clarify the relationship between private listening and magnetic coupling. Accordingly, we have revised the provision on magnetic coupling to clarify that the requirement to provide effective magnetic coupling applies where ICT delivers output by means of an “audio transducer held up to the ear” (proposed 410.3; final 412.3).

Numerous industry commenters expressed concerns with the proposed requirement that, where ICT provides non-private listening, incremental volume control shall be provided with output amplification up to a level of at least 65 dB, and where ambient noise level of the environment is above 45 dB, a volume gain of at least 20 dB above the ambient level shall be user selectable (proposed 402.3.2). These commenters all criticized the proposed provision on technical grounds as being imprecise and incapable of determination. We were persuaded by these criticisms and have removed the requirement in the final rule.

These commenters also raised concerns with a requirement for non-private listening that requires automatic volume reset to a default level after every use, on the grounds that the proposed rule was unclear what constituted a “use” of the equipment (proposed 402.3.2). We have declined to make a change in response to this concern. Manufacturers have the ability to determine what constitutes a “use” in the context of their device. For example, a device like a walkie-talkie might reset only when turned off and on, whereas a copier machine might reset automatically after several minutes of inactivity (final 402.3.2).

The NPRM proposed in 402.4 to address the size, font, and contrast requirements for characters displayed on a screen. We received comments from a range of stakeholders (ICT trade associations and companies, two state/local, a coalition of disability rights organizations and an academic research institution). Commenters from industry objected to the size and contrast requirements as being vague and needing additional explanation. On the other hand, commenters from the state agencies, disability advocacy organizations, and academia supported the provision as being useful in providing criteria for a more accessible font style and size. The disability advocacy organizations wanted an additional requirement to specify a font size in at least one mode where ICT did not have a screen enlargement feature. We have declined to change the provision (final 402.4). The language of the provision is derived from 707.7.2 in the ADA and ABA Accessibility Guidelines. This language has proven over time to strike a fair balance as a minimum standard that is technically feasible for a broad range of devices. While the Board agrees that a more specific contrast requirement would be beneficial, there is not yet an industry consensus standard for measuring contrast as delivered. We considered the metric for contrast as specified by WCAG 2.0 Level AA Success Criterion 1.4.3 but determined that it is inapplicable here, since it only applies to source content and is not appropriate for displays, as addressed in this provision.

In the NPRM preamble we provided variable message signs (VMS) as an example of ICT with closed functionality that would be covered by Section 402 but noted that we were not aware of any VMS technology that provides audible output. We also noted that there is one voluntary consensus standard that addresses the needs of persons with low vision. In Question 18, the Board sought comment on whether it should reference the requirements for VMS in ICC A117.1-2009 Accessible and Usable Buildings and Facilities, if there were technologies that would allow blind users to receive audible messages generated by VMS, and if VMS cannot be speech output enabled, should it at least require VMS to be accessible to people with low vision. NPRM, 80 FR 10880, 10915 (Feb 27, 2015). Several commenters, with a wide variety of backgrounds, agreed that the ICC A117.1-2009 requirements are appropriate to address the needs of many users with low vision, and that we should use those requirements even if VMS cannot be speech output enabled. The few commenters responding to our questions about technologies that might generate an audible version of VMS affirmed that the commercially available products are not sufficiently mature to justify mandating their use. Consequently, in the final rule we now reference the ICC A117.1-2009 standard and have added an exception to 402.2 Speech Output Enabled for VMS (final 402.2 Exception 1). The Board has also added a new requirement for characters on variable message signs (final 402.5) that references the requirements for VMS in ICC A117.1-2009.

Two commenters (a coalition of disability rights organizations and an academic research institution) requested that the Board add a requirement for audio cutoff. The intention of the recommendation was to ensure privacy for users of headsets. When users plugged their audio connectors into a standard connection port of ICT that delivers output through an external speaker that broadcasts information in public, the sound from the speakers would be cut off. The Board has declined to add a requirement for audio cutoff as it has determined that it is overly prescriptive, and the objective is already addressed in the final rule by 405, which addresses privacy of input and output for all individuals.

We received a detailed comment from an ICT company who suggested the addition of more requirements for products with closed functionality. The commenter recommended that the Board add five provisions from EN 301 549 onto the existing requirement for closed functionality (proposed 402). Two of the EN provisions, addressing privacy and spoken language, are dependent on unspecified external conditions such as privacy policies and undefined terms such as “indeterminate language” and are unenforceable. EN 301 549 clause 5.1.3.9 and clause 5.1.3.14. Accordingly, the Board has declined to add them to the final rule. The commenter also proposed that the Board adopt a formula for minimum text size as used in EN 301 549, clause 5.1.4. The Board has determined that this is unnecessary and would be redundant of the final rule’s provision addressing minimum text size (final 402.4), which we have decided is straightforward and capable of being tested. The remaining two suggested provisions also had existing parallel provisions in the final rule: a provision on audible signals (EN 301 549, clause 5.1.5) has a parallel provision in 411 of the final rule; and a provision on tactilely discernible controls and keys (EN 301 549, clause 5.1.6, clause 5.1.6.1, and clause 5.1.6.2) is addressed in the final rule provision for tactilely discernible controls and keys (final 407.3). Accordingly, we did not add any of these recommended EN provisions to the final rule.

406 Standard Connections

The NPRM proposed that where data connections used for input and output are provided, at least one of each type of connection shall conform to industry standard non-proprietary formats (proposed 406). Several industry commenters recommended that we use the exact wording from EN 301 549, which specifies the direct or indirect use of commercially available adapters (EN 301 549, clause 8.1.2). The proposed requirement closely corresponds to §1194.26(d) of the existing 508 Standards and §1193.51(a) of the existing 255 Guidelines; the intent of this requirement is to support compatibility with assistive technology hardware. Because hardware used with assistive technology may require a different adapter from a commercially available one, the Board has concluded that it is important to retain the flexibility to allow for both non-proprietary and proprietary connections. For all these reasons, we have retained the phrasing used in the proposed rule (proposed 406; final 406).

407 Operable Parts

The NPRM contained a lengthy section addressing accessibility features of operable parts. We received several comments from industry (ICT trade association and an ICT company) requesting that we delete the provision requiring that keys and controls contrast visually from background surfaces, (proposed 407.2) as being imprecise and incapable of being measured. We have declined to delete this requirement because contrast on controls and keys is an important feature in providing access to the labels on the keys for persons with low vision. The language of the provision is derived from 707.7.2 in the ADA and ABA Accessibility Guidelines. The language has proven to strike a fair balance as a minimum standard and being technically feasible for a broad range of devices. While the Board would prefer to have a more specific contrast requirement, there is not yet an industry consensus standard for measuring contrast as delivered. The metric for contrast as specified by WCAG 2.0 Level AA Success Criterion 1.4.3 is inapplicable here, since it only applies to source content and is not appropriate for displays, as addressed in this provision. Accordingly, we have retained the provision without change from the proposed rule (proposed 407.2; final 407.2).

The NPRM proposed that at least one tactilely discernible control be provided for each function. Devices for personal use with input controls that were audibly discernible without activation and operable by touch were exempted from this requirement. Several commenters (a disability advocacy organization, two ICT trade organizations, and three ICT companies) recommended providing an exception for tactile discernibility for products that are discernable audibly or products that used other non-tactile methods to be discernable without vision. We have determined that these suggestions would make the exception overly broad. For example, tactile discernibility is essential for devices located in public spaces, such as an information transaction machine, where ambient sound may interfere with an individual’s ability to perceive instructions given solely in the form of audible output. Likewise, an exception that permitted a device to rely solely on gesture controls might not be accessible to individuals who are blind or who are unable to gesture. We have retained the exception proposed in the NPRM, which is limited to personal use devices that are discernable audibly without activation (proposed 407.3; final 407.3).

The NPRM proposed that input controls be tactilely discernible and operable by touch and, where provided, that key surfaces outside active areas of the display screen shall be raised above the surrounding surface. A number of commenters (an ICT company, two ICT trade associations, and a disability advocacy organization), opposed the requirement. The commenter from the disability advocacy organization stated that raised keys would be difficult to use for some individuals with disabilities and potentially decrease accessibility. Industry commenters argued that requiring raised keys would add to the cost of designing and fabricating ICT. In response to these concerns, we have deleted the requirement that key surfaces be raised above their surroundings in the final rule. The provision in the final rule now simply requires input controls to be operable by touch and tactilely discernible without activation (proposed 407.3.1; final 407.3.1).

The proposed rule required alphabetic keys, where provided, to be arranged in a QWERTY layout, with the “f” and “j” keys tactilely distinct from the other keys. The provision further required that, where an alphabetic overlay was provided on numeric keys, the overlay must conform to the ITU-T Rec. E. 161. We received a number of comments from industry (three ICT companies and two ICT trade associations) raising concerns that some culture-dependent keyboards contained slight deviations from the strict “QWERTY” arrangement. The intent of this provision is to ensure that individuals who are blind have a point of orientation when encountering an unfamiliar device that uses alphabetic key entry. We have determined that QWERTY key arrangement, commonly used by touch typists, is the best for this purpose. However, in response to comments, we changed the reference for the required keyboard layout from “QWERTY” to “QWERTY-based” keyboards, which provides enough flexibility to be applied for settings where English is not the preferred language (proposed 407.3.2; final 407.3.2).

The proposed rule also included a provision on numeric keys, in addition to the provision on alphabetic keys discussed above. One commenter objected to the language of the provisions in the proposed rule and discussed the difficulty of requiring the “f” and “j” keys to be tactually discernable when a numeric keyboard is used for alphabetic key entry. We reviewed the language of the two provisions and saw that while the proposed provision had one sentence addressing use of alphabetic keys and a second sentence addressing the use of an alphabetic overlay on a numeric keyboard for alphabetic key entry, it was confusing. To clarify this distinction, in the final rule we have moved the requirement for alphabetic overlay for numeric keys from the provision on alphabetic keys to the associated provision on numeric keys (proposed 407.3.2 and 407.3.3; final 407.3.2 and 407.3.3).

The proposed rule had a provision requiring a fixed or adjustable key repeat rate, when a keyboard had the key repeat feature. We received several comments from industry (an ICT trade association and an ICT company), suggesting that the provision was unnecessary since a comparable key repeat requirement was also proposed for software (proposed 502.4; final 502.4). The key repeat provision for hardware is found in the existing 508 Standards §1194.23(k)(3) and we have determined that it continues to be useful for individuals with manual dexterity issues. We disagreed with the assertion by the commenters that a hardware provision for key repeat was unnecessary and could be adequately addressed solely by a provision addressing software. Accordingly, we made no change in the final rule (proposed 407.4; final 407.4).

The proposed rule included a provision related to timed responses, which proposed that a user be alerted visually, as well as by touch or sound, when a timed response was required. In addition, the user was to be provided the opportunity to request an extension of time to complete their response. We received several comments from industry (an ICT trade association and an ICT company), suggesting that the provision be deleted because a similar requirement was proposed for software (WCAG 2.0 Success Criterial 2.2.1 Timing Adjustable). The requirement for hardware to give the user the ability to extend the time for a response is found in the existing 508 Standards §1194.22(p) and we have determined that this is an important feature for a number of users, including individuals with manual dexterity issues, among others. We disagreed with the assertion by the commenters that a hardware provision for key repeat was unnecessary and could be adequately addressed solely by a provision addressing software. Accordingly, we made no change in the final rule (proposed 407.5; final 407).

The proposed rule had several requirements related to reach height which address how a user in a wheelchair can reach the operable parts of controls and keys of stationary ICT from a forward or side position. The NPRM was an expansion of requirements in the existing 508 Standards §1194.25(j), which address only side approaches to stationary ICT, to include both forward and side approaches. These revisions add flexibility for users and for manufacturers and designers of ICT (proposed 407.12; final 407.8).

A commenter addressing this reach height asked whether a paper tray on a copier could be used as a reference point for the location of any controls. A paper tray is not used as a reference point in determining either the leading edge or reference plane of stationary ICT. Access to a paper tray is considered a maintenance function, so it is not addressed by the reach requirements. We have revised the language in the final rule to clarify that the operable parts requirements apply to “operable parts used in the normal operation of ICT” (proposed 407; final 407). Normal operation, such as using keys to input data or create content or operate ICT such as a multifunction copier, is different from maintenance functions, such as changing toner on a printer. Placing paper on the surface of a copier for making copies is considered normal operation. However, replacing paper in a paper tray is considered a maintenance function, not a normal daily operation, so access to a copier paper tray is not covered under this provision.

The NPRM proposed requirements for display screens on stationary ICT (proposed 408). In the preamble to the NPRM, we sought comment on whether to add a requirement that the viewing angle of display screens be adjustable. 80 FR 10880, 10919 (Feb. 27, 2015), question 23. In response to this question, eight commenters (two ICT trade association, three ICT companies, an accessible ICT services provider, a state/local agency, and an ICT subject matter expert) all recommended against adding a provision for a tilted display screen, citing concerns that the provision would be too prescriptive and would introduce maintenance and cost issues to the upkeep of the ICT. In response to these comments, we have decided against adding such a provision to the final rule.

409 Status Indicators

The NPRM proposed that all status indicators should be visually discernible and discernible by either touch or sound. The provision contained examples of the types of controls or keys that should be discernible. A commenter (ICT company) found this approach confusing and asked whether discernibility was a feature that needed to be available all the time, or whether it only needed to be discernible when a change of status occurred. In response, the Board removed the reference to examples of types of controls and keys. We did not specify a limitation on when discernibility was required, but have determined that a single notification of a change of state is sufficient (proposed 407.6; final 409).

411 Audible Signals

The NPRM proposed that audio signaling shall not be used as the only means of conveying information, indicating and action, or prompting a response (proposed 407.8). We received comments from a coalition of disability rights organizations which strongly supported this provision. We also received a comment from an ICT company who expressed confusion as to the meaning of the term, “audio signaling.” In response to these comments, we have replaced the term “Audio Signaling” with “Audible Signals or Cues,” in the final rule. This section was elevated and renumbered from a sub-provision in the proposed rule

412 ICT with Two-Way Communication

In the proposed rule, this section contained provisions for Real-Time Text Functionality (proposed 410.6). Those provisions are now reserved, pending the outcome of rulemaking by the Federal Communications Commission (FCC) as discussed in Section III.D (Major Issues – Real-Time Text). The majority of the remaining provisions in this section address features of two-way communication such as volume gain, minimized interference, and magnetic coupling. There were numerous comments on this section, resulting in the edits discussed below.

In the proposed rule, the Board referenced FCC regulations at 47 CFR §68.317 in anticipation of a pending rulemaking by the FCC on volume control covering all types of communication technology that provides two-way voice communication, to facilitate hearing aid compatibility (proposed 410.2). Currently 47 CFR §68.317 only addresses volume gain for analog and digital wireline telephones. As noted by several commenters from ICT trade associations, it does not address volume gain for wireless devices (e.g., mobile phones). We have amended the provisions on volume gain to distinguish between volume gain requirements for wireline telephones and non-wireline devices. The Board will consider further updates to these requirements at such time as the FCC completes its rulemaking on this issue.

The proposed rule contained two separate provisions addressing magnetic coupling and minimizing interference (proposed 410.3 and 410.4). We received two comments, one from an ICT trade association and one from a coalition of disability rights organizations, urging that the two provisions be combined since they address related features of ICT with two-way voice common to wireless or wireline devices. The ICT trade association stated that the phrase “to the lowest extent possible” was too subjective and should be removed, leaving the citation to the referenced standard in the provisions. In the final rule, the requirements for magnetic coupling and minimizing interference have been combined into a single provision that clarifies that, where ICT delivers output by a handset or other audio transducer that is typically held to the ear, it shall reduce interference with hearing technologies and provide a means for effective magnetic wireless coupling (final 412.3).

One commenter from an ICT trade association recommended that the Board reference the European standard ETSI ES 200 381-2 in addition to ANSI C63.19-2011 to address minimized interference on wireless handsets. We have reviewed ETSI ES 200 381-2 and determined that it covers only a subset of the frequency ranges covered by ANSI C63.19-2011, because it has a smaller operating range for devices (698 MHz to 3 GHz) compared to ANSI C63.19-2011 (698 MHz to 6 GHz). If the ETSI standard were applied by this rule, manufacturers of devices currently producing products with the broader ANSI frequency ranges could potentially reduce the ranges offered by the products, thereby reducing accessibility (proposed 410.4.1; final 412.3.1).

The NPRM included a proposed requirement for digital encoding of speech (proposed 410.5). In response to comments from industry (ICT trade associations and an ICT company), we have updated the referenced standards cited for digital encoding of speech to the current versions, ITU-T Recommendation G.722.2 and IETF RFC 6716 (also known as the Opus Codec). In addition, we have deleted the exception because the updated standards address the technical basis for the exception, and therefore it is not needed (final 412.4).

414 Audio Description Processing Technologies

In response to a comment from an ICT trade association, we have revised this provision in the final rule to clarify that the standard referenced in this section, ATSC A/53 Digital Television Standard, Part 5 (2010) only applies to ICT in the form of digital television tuners. We added a separate provision to require that ICT other than digital television tuners provide audio description processing (proposed 412; final 414).

415 User Controls for Captions and Audio Description

The NPRM proposed that ICT provide user controls for the selection of captions in at least one location that is comparable in prominence to the location of user controls for volume. It further proposed that ICT provide user controls for selection of audio description in at least one location that is comparable in prominence to the location of controls for program selection. An exception was provided for devices for personal use, which were not required to comply with the proposed provision (proposed 413).

Commenters from a coalition of disability rights organizations strongly supported this requirement but expressed concern over the exception, fearing that the language “personal use” could be interpreted so broadly as to exempt many devices from coverage. Commenters from industry objected to the language “comparable in prominence” because they found it imprecise and incapable of being tested. They asked that we either define the term or remove it. Commenters from industry also objected to the requirement to provide a physical button arguing that it would significantly impact the design of hardware devices such as remote controls.

After review of the comments, we have revised the exception to make it available when captions and audio descriptions can be enabled through system-wide platform settings. We further revised the requirement for caption selection to state that where operable parts are provided for volume control, ICT shall also provide operable parts for caption selection. The requirement for selection of audio description was likewise revised to state that where ICT provides operable parts for program selection, it shall also provide operable parts for the selection of audio description. We have concluded that these changes will provide users of captions and audio description with comparable access to those controls, without being overly prescriptive of technological solutions (final 415).

G. Chapter 5: Software

Chapter 5 contains the technical requirements for programs, procedures, rules, and computerized code that directs the use and operation of ICT, and instruct ICT to perform a given task or function. Software includes applications (including mobile apps) and operating systems, as well as processes that transform or operate on information and data. The NPRM proposed that software with a user interface, including client-side and Web applications conform to WCAG 2.0 Level AA. We have retained this requirement in the final rule. Traditional client-side software must also conform to final 502 and 503. Software, including Web applications, that are authoring tools must conform to the requirements of final 504.

Many commenters expressed concern with the complexity of the proposed rule. They urged us to adopt WCAG 2.0, and only WCAG 2.0, as the complete and sufficient set of accessibility requirements for software. Chapter 2 of the final rule incorporates WCAG 2.0 Level AA into the software requirements, and while some of what Chapter 5 requires is parallel or redundant to WCAG 2.0 Success Criteria, Chapter 5 includes requirements that go beyond WCAG 2.0, provide additional detail, or parallels those of the existing 508 Standards. The authors of WCAG 2.0 were informed by the existing 508 Standards, but since WCAG 2.0 only addresses Web content, it has natural technical limitations with its scope. Most subject experts agree that there would be a significant accessibility gap if software were only bound to Success Criteria from WCAG 2.0, and the requirements of this chapter address that gap. Accordingly, no change was made in this approach from the proposed rule to the final rule.

A state/local agency asked why the Board was not making additional references to technology standards, and asked specifically about WAI-ARIA, ATAG 2.0, and UAAG 2.0, and EPUB3. The Board agrees that these are all useful resources, but as discussed below, we have concluded that these additional standards are too detailed and prescriptive as compared to what is being addressed with our Revised 508 Standards and 255 Guidelines.

WAI-ARIA 1.0 (Accessible Rich Internet Applications 1.0, Mar. 20, 2014, http://w3.org/TR/2014/REC-wai-aria-20140320) is a completed W3C® Recommendation but WAI-ARIA 1.1 is still under development and we cannot cite it until it is formally completed. (Accessible Rich Internet Applications 1.1 Working Draft, July 21, 2016, http://w3.org/TR/wai-aria-1.1). It contains specifications for Web technologies like HTML5, SVG, and Ajax (short for asynchronous JavaScript and XML). WAI-ARIA can be used to create Web applications that conform to WCAG, but is not required for WCAG conformance. WAI-ARIA is a valuable specification, but the technology it addresses is too narrow for our Standards and Guidelines to require its use at this time.

Authoring Tool Accessibility Guidelines (ATAG) 2.0 is a completed W3C® Recommendation. (ATAG 2.0, Sept. 24, 2015, http://w3.org/TR/ATAG20). The Board relied on ATAG 2.0 in developing the requirements for authoring tools included in Revised 508 Standards and 255 Guidelines (proposed 504; final 504). Since ATAG 2.0 applies to software, many of its requirements are redundant to our requirements in 502 and 503. ATAG 2.0 is very narrowly focused on Web content and is very prescriptive. For these reasons, and because of the limited use of ATAG 2.0 in the Federal sphere, the Board has declined to reference it. We have worked to ensure that there are not any conflicts between our requirements and ATAG 2.0. Authoring tools that provide Level AA conformance to ATAG 2.0 will conform to these Standards and Guidelines.

User Agent Accessibility Guidelines (UAAG) 2.0 was published as a “working group note” and there are no plans to move it forward as a W3C® Recommendation. (UAAG 2.0, Dec. 15, 2015, http://w3.org/TR/UAAG20). This last step would be necessary for it to be characterized as an industry consensus standard so it is not appropriate to reference at this time. As an accessibility metric for certain types of software (i.e., Web browsers, media players, document readers and other applications that render Web content), UAAG 2.0 does not have any conflicts with the requirements of these Revised 508 Standards and 255 Guidelines.

EPUB® is the distribution and interchange format standard for digital publications and documents based on open Web standards, and EPUB 3.0.1 is the current and stable version of the EPUB standard. See EPUB 3.0.1, International Digital Publishing Form, http://idpf.org/epub/301 (last visited Aug. 23, 2016). EPUB3 is an excellent file format for electronic documents and accessibility features were integrated throughout in the development of the specification. There are several popular (and accessible) platforms for reading EPUB3 content, but the software currently available for interactively editing EPUB3 content is limited. The EPUB3 format is fundamentally accessible; however, it is possible to create content that technically is in the EPUB3 file format, but not sufficiently accessible. One example would be an EPUB3 file with poor quality alternative text associated with images. WCAG 2.0 Level AA provides an appropriate rubric for assessing the accessibility of EPUB3 documents and this rule would not gain substantively from a reference to EPUB3.

501 General

As with the other chapters, Chapter 5 begins with a reference back to the scoping provisions. We heard from several commenters that people unfamiliar with standards might miss the incorporation by reference of WCAG 2.0 and that they, and others, prefer the formatting approach used by EN 301 549 where the WCAG 2.0 Success Criteria are restated as needed for each section. These commenters were concerned that the provisions of Chapter 5 were all that a software developer might pay attention to. The Board is preparing advisory material to this effect to help users of this rule avoid that oversight.

An ICT company and an ICT trade association urged the Board to modify the exception for Web applications from technical requirements in Chapter 5, which is conditional on those Web applications being fully conformant with WCAG 2.0 Level AA. These commenters urged the Board to exempt all Web applications from proposed sections 502 and 503, regardless of conformance with WCAG 2.0. They reasoned that for non-conformant Web applications, complying with these sections would not necessarily address the non-compliant aspect of the application and would introduce additional testing and compliance issues. Their position is that a conformity assessment against WCAG 2.0, perhaps using a format similar to the current Voluntary Product Accessibility Template® developed by the Information Technology Industry Council, is complete and sufficient for a Web application, so also assessing against final sections 502 and 503 would be superfluous or even onerous. One commenter gave the example of Web software missing a single text equivalent and thus being subject to the requirements of Chapter 5.

The Board supports having a single conformance model for accessible Web applications and agrees that WCAG 2.0 Level AA is generally sufficient for assessing the accessibility of Web applications. The value of a single unified standard for the accessibility of Web content outweighs the value of additional requirements particular only to certain kinds of Web applications.

However, we have declined to extend an absolute exception from the requirements of Chapter 5 for Web applications without regard to their conformance to WCAG 2.0. The Board recognizes that in some cases, reviewing those non-conforming Web applications against 502 and 503 would not identify additional accessibility concerns. In other cases, a Web applications failing against a particular WCAG 2.0 requirement, for example Success Criteria 4.1.1 Parsing, will have accessibility issues mitigated by addressing requirements from 502 and 503. Therefore, the Board has retained the exception as only being applicable to Web applications that meet WCAG 2.0 Level AA.

In addition, we have narrowed the exception to Web applications that are not isolated from the operating system or the platform they run on. During its examination of this exception, the Board became concerned that certain Web applications that had access to platform accessibility services (and which conformed to WCAG 2.0) were not always compatible with certain assistive technology (such as screen reading software). We concluded that the Exception to 501.1 should be somewhat narrowed from that of the proposed rule, to exclude only Web applications that do not have access to platform accessibility services. This qualification is important because major developers are working hard to make the distinction between desktop and Web applications less apparent to the end-user. As this class of Web applications mature, it is reasonable to anticipate that they might gain the ability to use the accessibility features of the underlining platform they run on. Accordingly, the 501.1 Exception has been changed in the final rule to only be for those Web applications that conform to WCAG 2.0 Level AA and do not have access to platform accessibility services (directly or through included components).

An ICT company and an ICT trade association disagreed with inclusion of Exception 2 in proposed 501.1, which proposed to exempt assistive technology from the technical requirements in Chapter 5 when assistive technology supports platform accessibility services. These commenters asserted that assistive technology software should be held to the same requirements as mainstream software, and further recommended that the Board adopt an approach similar to EN 301 549, which does not distinguish between assistive technology and other software, and imposes additional requirements on assistive technology.

The purpose of Section 508 is to provide people with disabilities comparable access to ICT. Having additional requirements for assistive technology, or even just holding assistive technology to the same technical requirements as mainstream software, can be counter-productive to that purpose. For example, requiring an on-screen keyboard that is used by a sighted switch user to also be compatible with screen reading software could impose technical challenges that would decrease its utility or pose a barrier to product development. The Board does not want the 508 Standards to create an impediment to Federal agencies procuring assistive technology they need for their employees with disabilities. However, we are aware that in order for mainstream software to work with all assistive technology, the assistive technology must use the accessibility services of the platform. We have retained this requirement as the basis on which assistive technology can obtain the exception from the requirements of Chapter 5. The exception for assistive technology was moved from Chapter 5 to Chapter 2 (final E207.1; E207.2; C205.1; and C205.2) to better ensure that assistive technology developers would not be asked for unnecessary conformity assessment reviews.

502 Interoperability with Assistive Technology

The NPRM proposed that users have control over documented accessibility features (proposed 502.2.1) and that software not disrupt documented accessibility features (proposed 5.2.2.2). An ICT company and an ICT trade association recommended adding an exception to this latter requirement for “when requested to do so by the user during the operation of the software.”

We have not changed the requirement from the proposed rule. The suggested edit is not necessary since if the user is changing the setting, then the accessibility feature could not be reasonably characterized as having been disrupted. User selection and control of accessibility features is not the same as disrupting the accessibility features. If an agency were to disable platform settings that provide accessibility (thereby violating 502.2.2) then the agency would have the responsibility under 508 for demonstrating equivalent facilitation. This is similar to causing software to be closed to the addition of assistive technology, changing the nature of the platform to be functionally indistinguishable from closed hardware, and the requirements of 402 would be applicable.

The NPRM proposed that platform developers provide accessibility services (proposed 5.2.3) and the sub-provisions listed the requirements for software running on those platforms. The Board has changed the phrasing of 502.3 in the final rule to be more consistent with other parts of the rule but the requirements are fundamentally the same as with the proposed rule. As discussed above in Section IV.A. (Summary of Comments and Responses on Other Aspects of the Proposed Rule – 508 Chapter 1: Application and Administration – E103.4), in the final rule we have added a definition for “software tools” which is software used for developing software. We also made editorial changes based on input from commenters.

The sub-provisions of 502.3 come from the existing 508 Standards and other accessibility standards and specify details that the Board concluded are important for software accessibility. The authors of WCAG 2.0 included requirements from §1194.21 of the existing 508 Standards where they could (for example, an explicit requirement for keyboard accessibility is in WCAG 2.0 but was not in WCAG 1.0), but some requirements are not applicable to all technologies and therefore are not explicit in WCAG 2.0. For example, the requirement for row and column headers of data tables to be programmatically determinable (final 502.3.3) is explicit in the existing 508 Standards, and is in WCAG 1.0, but not explicit in WCAG 2.0 because WCAG 2.0 is written to be technology neutral. The Board’s approach in the final rule is consistent with EN 301 549 and other standards for software accessibility.

The numbering of sub-provisions in 502.3 of the final rule has been changed significantly from the proposed rule. Commenters requested that programmatically determinable object information, values, text, and other details be separated from the requirement to set or change that object information, values, text, and other details. The proposed rule had nine sub-provisions under proposed 502.3 whereas the final rule now has fourteen, but the requirements are substantially unchanged. Another commenter suggestion was to clarify that by “table” we meant “data table,” so the Board has made that explicit in the final rule.

There was a recommendation from a disability advocacy organization that the event notification provision “should be made to assure that a screen reader can retain control of the reading cursor” but did not offer a specific text change. As part of renumbering and separating the requirements, we have added a separate requirement for modification of focus cursor (final 502.3.13) which addresses this commenter’s concern. An ICT company and an ICT trade association recommended adding a requirement to this section, “Execution of Available Actions.” The proposed rule contained an equivalent requirement (the second of two sentences in proposed 502.3.7) and in the final rule it is a separately numbered provision (final 502.3.11) requiring that: “Applications shall allow assistive technology to programmatically execute available actions on objects.” This provision is intended to address scenarios such as when a person is using screen reading software and encounters a button control with four options. The person should not only hear the description of the control, but also be able to select any one of those four options through the usual keystrokes used with the screen reading software.

Section 502.4 in the final rule is unchanged from the proposed rule. It lists seven requirements from ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces. In the NPRM preamble the Board asked if the cost was excessive or if there was another authoritative standard we could use. An ICT company and an ICT trade association confirmed the resource as being unique. These two commenters and a Federal agency characterized the standard as relatively expensive and asked if the Board could instead excerpt the seven cited requirements in full. As noted in the preamble to the proposed rule, the seven cited requirements mostly predate the existing 508 Standards and are common features of operating systems. For people familiar with accessibility features, the requirements are readily apparent just from the titles cited in the final rule. Therefore, the final rule retains a reference to the ANSI/HFES 200.2 standard.

One ICT company recommended adding some additional requirements for assistive technology interoperability that parallel clauses 11.3.2.2 and 11.3.2.3 in EN 301 549. The Board declines to follow this recommendation as we have determined that 502.3 in the final rule already contains equivalent technical requirements for assistive technology interoperability, and is simpler and more practical to apply relative to the EN approach, without compromising accessibility.

503 Applications

The proposed rule included a general requirement that applications must permit users to set their preferences from platform settings for color, contrast, font type, and focus cursor (proposed 503.2). For example, a user with low vision might want the default windowing scheme to use yellow on black text with an 18 point sans-serif font. An exception to this provision exempts applications that are designed to be isolated from their underlying platform software (such as Web applications) from this requirement. We received several comments (from individuals, a disability advocacy organization, and an accessibility ICT services provider) concerning the scope of the exception. These commenters acknowledged that certain technologies (such as Adobe® Flash®) were properly exempted, but thought that the exception was otherwise overbroad by sweeping in other types of Web applications (which were unspecified). More generally, some of these commenters also suggested that the Board broaden 503.2 so that the requirement for pass-through of user preferences apply to Web content, as well as applications.

With respect to commenters’ suggestion of overbreadth, the Board declines to revise the exception to apply only to certain types of Web applications. We are aware of no discernible basis for differentiating between Web applications that do and do not warrant the exception, nor did commenters offer any such criteria. It is not technically feasible to require Web applications to use platform preferences because generally the developer of a Web application has no way of knowing what font characteristics a reader will be using for text in windows of their operating system. Applications, including Web applications, which qualify for the exception to use platform settings are still subject to the other requirements of Chapter 5, including the requirements referenced by WCAG 2.0 Level AA.

Likewise, the Board finds commenters’ suggestion that the scope of proposed 502.3 be broadened to include Web content to be misplaced. Section 502.3 in the final rule, as with all of Chapter 5, addresses technical requirements for accessibility of software, not Web content. In any event, requiring Web content to meet requirements for pass-through of user preferences would face the same technical challenges as Web applications.

504 Authoring Tools

This section contains additional requirements for software used to create and edit content and documents. The major substantive change from the proposed rule is the addition of a new requirement (final 504.2.2) that authoring tools capable of creating full-featured PDFs (that is, a PDF that conforms to PDF 1.7, also known as ISO 32000-1) must also support creating PDFs conforming to PDF/UA-1. PDF/UA-1 is an extension to PDF 1.7, meaning that PDF/UA-1 is only applicable to PDFs that already conform to PDF 1.7.

Based on comments from a standards developing organization, an ICT trade association, and an ICT company, we have made some editorial changes to proposed sections 504.2, 504.3, and 504.4 for the final rule. For example, “all features and formats” in the proposed rule have been changed to “all supported features and, as applicable, to file formats” in the final rule, to clarify that the limitations of the file formats be taken into consideration.

A disability advocacy organization commented that the accessibility features should be turned on by default, but the Board has decided that would be overly prescriptive. In addition, such a requirement could interfere with automated testing of content for accessibility features. For example, it is significantly easier to identify missing alternative text (as an error) than it is to test for overuse of placeholder or default alternative text. In response to requests from commenters, the Board also plans to incorporate examples from EN 301 549 into forthcoming technical assistance materials.

The NPRM proposed that authoring tools prompt authors to create content that conforms to WCAG 2.0 Level AA, and went on to specify that the tools should provide the option for prompts during initial content creation or when the content is saved (proposed 5.4.3). Based on a commenter observation that accessibility features might best be addressed in the middle of a document workflow process, the last sentence from proposed 504.3 has been deleted in the final rule. The Board agrees that prompts and conformance checks can be performed at any point, not just upon content creation or when saving a file.

H. Chapter 6: Support Documentation and Services

601 General

Chapter 6 contains accessibility requirements for ICT support documentation and services. This section requires support services such as help desks, call centers, training services, and automated self-service technical support systems that provide documentation addressing accessibility and compatibility features available in accessible formats. We received multiple comments on the application of the PDF/UA-1 standard to electronic support documentation under proposed 602.3. Those comments are discussed in Section III.C. (Major Issues – Incorporation by Reference of PDF/UA-1). Additionally, we received a few comments on some of the other proposed provisions of Chapter 6, which are discussed below.

602 Support Documentation

The NPRM proposed a provision addressing alternate formats for non-electronic support documentation for people who are blind or have low vision (proposed 602.4). The Board received two comments on this provision, one from a state/local agency, and another from a disability advocacy organization. Both commenters asked that we broaden the application of proposed 602.4 to clarify that alternate formats must be provided to any requester with a disability, not just individuals who are blind or have low vision. The Board concurs with this and has amended 602.4 to require alternate formats usable by “individuals with disabilities.” The intent of this provision is to address the needs of individuals whose disability makes it difficult to use hardcopy materials. Examples of such disabilities include blindness, low vision, fine motor impairments, and limited cognitive, language and learning abilities.

We received an additional comment from a disability advocacy organization requesting that a notification of the availability of alternate formats be prominently displayed, and that the alternate format provided be that of the requestor’s choosing. The final rule requires that support documentation be provided on request in alternate formats usable by individuals with disabilities. We do not agree that mandating a particular placement for notification of this is necessary. In addition, the Board does not find that it is reasonable to require manufacturers and government agencies to create alternate documentation in every format requested. We anticipate that most manufacturers and agencies will provide accessible softcopy to those that need it, but manufactures are also permitted the flexibility to instead provide non-electronic support documentation in formats such as large print and braille if they choose to do so. We have concluded that the language of the final rule adequately ensures that alternate formats of electronic support documentation will be made available to individuals who need them, without overburdening manufacturers and government agencies.

603 Support Services

Three commenters discussed the proposed provision regarding support services to include information on accessibility and compatibility features of ICT (proposed 603.2). One commenter was a self-identified individual with a learning disability, one was an accessible ICT services provider, and one was a disability advocacy organization. All three commenters suggested that the Board add language to the provision mandating continuing education for personnel who staff help desks. The Board understands the concern, but declines to add the suggested language as it is overly prescriptive. We intend to provide technical assistance after the final rule has been promulgated that will address training programs as an example of a best practice in complying with this provision. Therefore, this provision is unchanged in the final rule.

I. Chapter 7: Referenced Standards

This new chapter, which provides a centralized IBR section for standards referenced in the Revised 508 Standards or Revised 255 Guidelines, was added to the final rule to comply with OFR regulations that govern incorporations by reference into the Federal Register. See 1 CFR part 51. This reorganization does not alter or change in any way the underlying application of the ten referenced standards in the revised standards and guidelines. Each of these standards is still referenced and apply to the prescribed extent specified in the respective IBR provisions. Chapter 7, in effect, simply streamlines the final rule by combining the respective IBR provisions of the Revised 508 Standards and 255 Guidelines into one consolidated IBR section.

With respect to the NPRM’s proposed IBR under Section 508, a number of commenters provided input on the proposed referenced standards. Several commenters raised concerns about the specific technical application of certain standards proposed for incorporation. These comments are addressed above in the applicable parts of Section III (Major Issues) and Section IV (Summary of Comments and Responses on Other Aspects of the Proposed Rule).

In addition, several commenters suggested that the Access Board reference other, additional standards in the updated 508 Standards. While several of the suggested standards serve as useful resources, the Board has determined that their incorporation into the standards is not necessary. With the exception of EN 301 549 (which is addressed below), the Board’s bases for declining the suggested reference of additional standards are discussed above in Section IV.G (Summary of Comments and Responses on Other Aspects of the Proposed Rule – Chapter 5: Software).

Of the 32 commenters mentioned above, 22 addressed the potential incorporation by reference of EN 301 549. Five commenters (three ICT companies and two ICT trade associations) suggested that the Access Board reference EN 301 549 as the sole technical standard for accessibility, or, at the very least, deem conformance with EN 301 549 as compliance with the Revised 508 Standards. These commenters made their recommendations in the interest of harmonization and, as one commenter put it, “promoting broader commercialization of accessible ICT systems.” In contrast, one commenter (an international disability advocacy organization) applauded the proposed rule as an improvement on several aspects of EN 301 549. This commenter also noted that, after publication of this final rule, EN 301 549 might well be revised to meet the higher (and, for some areas, more specific) accessibility requirements in the Revised 508 Standards.

For several important reasons, we decline to follow some commenters’ suggestion that the Access Board incorporate by reference EN 301 549 into the final rule (or otherwise deem conformance with this European specification to be compliance with Section 508). In sum, EN 301 549 was not developed using a voluntary consensus process, which makes this specification unripe for incorporation by reference into Federal regulations. Moreover, even assuming that EN 301 549 was an appropriate standard for incorporation by reference, reference in the Revised 508 Standards would be both unnecessary (e.g., due to the high degree of harmonization between the Standards and the European specification) and contrary to law (e.g., certain EN 301 549 provisions failing to provide sufficient accessibility under Section 508). Each of these considerations are discussed below.

First, EN 301 549 cannot be incorporated by referenced in the final rule because this European specification was not adopted through the requisite voluntary consensus standard development process. Under section 12(d) of the National Technology Transfer and Advancement Act of 1995 (codified at 15 U.SC. 272 note) (NTTAA), Federal agencies are directed to use technical standards developed by voluntary consensus standards bodies (as opposed to government-unique standards) when carrying out their regulatory functions unless doing so would be inconsistent with applicable law or otherwise impractical. OMB Circular A-119, which provides Federal agencies with interpretive guidance on the NTTAA, specifies that standards must be developed under processes that feature five enumerated characteristics to be deemed “voluntary consensus standards” (i.e., openness, balance, due process, appeals process, and consensus). See OMB, Circular A-119, Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities §§ 2(d)–(e) (revised Jan. 27, 2016).

EN 301 549, however, was not developed under such a process. Mandate 376, which was issued by the European Commission and tasked the European standardization bodies (i.e., CEN, CENELEC, and ETSI) with development of a harmonized set of functional accessibility requirements for publicly-procured ICT, did not require use of a voluntary consensus process; instead, this mandate merely provided that CEN/CENELEC/ETSI “shall work in close cooperation with relevant stakeholders” when developing the European procurement specification that became EN 301 549. See European Commission, Mandate 376 § 4 (Dec. 7, 2005), available at http://www.etsi.org/WebSite/document/aboutETSI/EC_Mandates/m376en.pdf. Additionally, while there was public input during the development of EN 301 549 by various stakeholders (including ICT industry representatives and some consumer groups), it does not appear that the process was sufficiently open or balanced to satisfy the requirements of Circular A-119. See, e.g., ACT NOW! EDF Position on the European Standard on Accessibility Requirements for Public Procurement of ICT, EASPD, http://www.easpd.eu/en/content/act-now-edf-position-european-standard-accessibility-requirements-suitable-public (last accessed Aug. 23, 2016) (noting concern that interests of persons with disabilities were not sufficiently represented during the development of EN 301 549 due to non-voting status of disability rights organizations); VVA Europe Ltd., European Association for the Coordination of Consumers Representation in Standardisation (ANEC), Preliminary Study on Benefits of Consumer Participation in Standardisation to All Stakeholders 45-52 (Nov. 13, 2014), available at http://www.anec.eu/attachments/ANEC-R&T-2014-SC-006.pdf (noting similar concerns with respect to consumer groups) Thus, while EN 301 549 represents an important step towards a more accessible ICT environment and serves as a meaningful set of technical specifications for public procurements of ICT in the European Union, it is not a voluntary consensus standard within the meaning of Circular A-119.

Moreover, even assuming that EN 301 549 was appropriate for incorporation by reference into the Revised 508 Standards, there is already broad harmonization between EN 301 549 and the final rule. As noted in prior preamble sections summarizing key aspects of the final rule and describing its rulemaking history, the timelines for development of the Revised 508 Standards and EN 301 549 largely overlapped; consequently, there was considerable coordination amongst the Federal entities (Section 508) and private organizations (CEN/CENELEC/ETSI) working on their respective technical accessibility standards for public ICT procurements. See Sections I.B.3 (Executive Summary – Summary of Key Provisions – Harmonization with International Standards) & II.F (Rulemaking History – Harmonization with European Activities).

Harmonization with international standards has been a guiding principle for this rulemaking from its earliest stages. For example, TEITAC Advisory Committee included several international representatives (including, notably, the European Commission), recognized the importance of standardization across markets worldwide, and coordinated its work with standard-setting bodies in the U.S. and abroad. See II.B (Rulemaking History – TEITAC Advisory Committee 2006-2008) (summarizing TEITAC Advisory Committee deliberations and report). Moreover, in the 2011 ANPRM, the Access Board express noted the standardization work going on in Europe at the time. See 76 FR at 76642, 76644–45. Indeed, one of the Access Board’s primary reasons for issuing a second ANPRM in 2011 was to afford the Joint Working Group on eAccessibility3 and the European Commission an opportunity to see the Board’s progress and to promote harmonization. Id. at 76642. Consequently, EN 301 549 – which was initially finalized in 2014 – was largely harmonized with the Board’s 2011 ANPRM. Compare, e.g., ETSI, EN 301 549 V1.1.1 (2014-02) with U.S. Access Board, 2011 ANPRM, Draft Updated ICT Standards and Guidelines, available at https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/draft-rule-2011; see also ETSI, EN 301 549 V1.1.2 (2015-04).

Harmonization, however, does not necessarily mean that the technical requirements for accessibility are exactly the same as between the final rule and EN 301 549. Rather, harmonization exists when the two sets of technical specifications are complimentary, in the sense that compliance with each can be achieved simultaneously without conflict. The Access Board evaluated EN 301 549 on a provision-by-provision and has determined that there are no conflicts between the technical requirements in the final rule and those specified in EN 301 549. However, we also concluded that, in some situations, EN 301 549 does not provide sufficient accessibility.4 This conclusion was also shared by several NPRM comments, principally European disability rights organizations. These commenters urged the Board to “stick to its proposal,” especially in relation to requirements for functional performance criteria, real-time text interoperability, and wideband audio. These commenters not only applauded the proposed rule’s high level of harmonization achieved with EN 301 549, but also expressed hope that the European specification would be revised at a future date to conform to the clearer requirements in, and higher levels of accessibility achieved by, the proposed rule.

Lastly, in any event, reference to EN 301 549 would be premature at this time because the specification is still likely to undergo revision after publication of the final rule. In December 2015, the CEN/CENELEC/ETSI Joint Working Group on eAccessibility met and concluded that “[a]t this moment there is consensus within [the Joint Working Group] on the need to revise EN 301 549 as soon as possible, with the aim to improve the document and to harmonize it with the next version of Section 508 as soon as [it] is public.” European Joint Working Group on eAccessibility, Draft Minutes 9th eAcc Meeting 7 (Dec. 10, 2015), http://www.itu.int/en/ITU-T/jca/ahf/Documents/Doc%20219.pdf.

For the foregoing reasons, the Access Board declines to reference EN 301 549 in the Revised 508 Standards or otherwise state that conformance with EN 301 549 equates to compliance with the final rule. The Revised 508 Standards’ requirements closely track the EN 301 549 phrasing where appropriate. In places where the Revised 508 Standards diverge from EN 301 549, the Board has done so deliberately because it finds that other technical requirements provide better accessibility. The Board anticipates providing technical assistance materials on its Web site to assist product manufacturers with mapping EN 301 549 requirements to the Revised 508 Standards and vice versa.

Additionally, several NPRM commenters pointed out to the Access Board that some of the specific editions of the standards proposed for IBR in the NPRM had been supplanted by newer editions or versions. For example, commenters noted that there were newer versions of ITU-T Recommendation G.722 and TIA 1083, which were respectively referenced in proposed E102.7.1 and E102.8.2. One commenter also recommended the Opus Codec (IETF RFC 6716) as a modern industry consensus standard for digital audio compression that has merits similar to ITU-T Recommendation G722.2. We concur with commenters and, in the final rule, the Board has updated the references in 702.7.2 to ITU-T Recommendation G.722.2, as well as the reference in 702.9.1 to TIA-1083-B. We also have added the Opus Codec as one of the referenced standards for digitally encoding speech in 412.4 of the final rule. (Incorporation of this standard appears at 702.8.1.)

We also made several other “housekeeping”-type changes to the standards referenced in the final rule. For example, because the Access Board is not addressing Real-Time Text at this time, see discussion above Section III.D (Major Issues – Real-Time Text), we have deleted the RTT-related references to TIA 825-A and IETF RFC 4103. In addition, because the final rule specifies requirements for characters on variable message signs (402.5) see Section IV.G (Summary of Comments and Responses on Other Aspects of the Proposed Rule – Chapter 4: Hardware), we have added a reference to ICC A117.1-2009 (Accessible and Usable Buildings and Facilities) in Chapter 7. Finally, we rearranged the list of referenced standards in Chapter 7 by alphabetical order of publisher name (rather than publisher acronym), which resulted in the reordering of some standards.

Finally, two commenters (an open government non-profit organization and an accessible ICT services provider) objected to the Access Board’s incorporation by reference of any voluntary consensus standard that are was not available to the public free of charge on the ground that such standards were not “reasonably available.” While the Access Board agrees that making referenced standards reasonably available to interested parties is required under both Federal administrative law and regulation, see 5 U.S.C 552(a); 1 CFR part 51, we strongly disagree with their contention that the standards referenced in the final rule do not collectively meet this standard. Prior to publication of the final rule, Access Board staff worked with the standards developing organizations (SDOs) to ensure that versions of the referenced standards were, to the greatest extent possible, available to the general public either without charge or at a reduced rate. See discussion infra Section V.G (Regulatory Process Matters – Availability of Materials Incorporated by Reference). As a result, nine of the ten standards incorporated by reference into the final rule will be available online free of charge, either because the standards developing organization makes the standard freely available on its Web site or a read-only copy of the standard will be made available on one or more SDO’s online standards portal. Id. The only exception is TIA-1083-B, which is referenced in 412.3.2 and 702.9.1. In discussions with Access Board staff, the SDO (Telecommunications Industry Association) declined to make a read-only version of this standard available online. Nonetheless, TIA-1083-B is still reasonably available by purchase (i.e., publisher or online standards store) or personal inspection without charge at the offices of either the Access Board or the National Archives and Records Administration. See id.; see also 702.9 (providing information on obtaining standard from publisher).

J. Revised 508 Standards: Compliance and Effective Dates

In the NPRM, the Board noted that it was considering making the Revised 508 Standards effective six months after publication in the Federal Register. The Board also noted it was considering deferring to the Federal Acquisition Regulatory Council (FAR Council) to establish the effective date for application of the Revised 508 Standards to new ICT contracts awarded after publication of the FAR Council’s final rule, as well as existing ICT contracts with award dates that precede that final rule.

The Board received 11 comments regarding the compliance date (seven from ICT companies and trade associations, two from state/local governments, one from a Federal agency, and one from an individual). Most of the commenters supported the Board’s proposal to defer to the FAR Council for establishing the compliance date for new and existing ICT contracts. However, a few of the commenters also requested more than the six-month delay suggested in the NPRM for application of the Revised 508 Standards to ICT other than procurements. These commenters asserted that a six-month delay was too short given the amount of potential remediation required for legacy technology and content, and the limited availability of resources to effect the changes.

As noted in Section IV.A (Summary of Comments and Responses on Other Aspects of the Proposed Rule – 508 Chapter 2: Scoping Requirements), the Board has incorporated a safe harbor into the Revised 508 Standards (E202.2) that, generally speaking, exempts unaltered, existing (legacy) ICT from having to upgrade or modify to conform to the Revised 508 standards. The Access Board expects that the addition of this safe harbor provision in the final rule substantially addresses some agencies’ concerns about the potentially high cost of remediating currently-compliant legacy Web sites and other public-facing electronic content. In addition, to allow agencies to maximize planning and resources for timely compliance with the Revised 508 Standards, the Board has extended the compliance date for the Revised 508 Standards from six months (as proposed in the ICT NPRM) to twelve months from the date of publication of the final rule. Prior to this date, agencies must continue to comply with the existing 508 Standards. For ease of reference, the existing 508 Standards have been republished as Appendix D to 36 CFR part 1194. (Note that, while the text of each provision provided in Appendix D remains identical to the existing 508 Standards, the numbering for each has been revised to conform to CFR publication requirements.)

This one-year compliance for the Revised 508 Standards is applicable to all ICT except that which is covered by the Federal Acquisition Regulations. The Board continues to defer to the FAR Council to establish the compliance date for new and existing ICT procurements subject to the Revised 508 Standards.

While the compliance date for the Revised 508 Standards is one year from the date of publication in the Federal Register, the overall effective date of the rule remains 60 days from publication. On the effective date of the rule, the existing 255 Guidelines will be replaced by the Revised 255 Guidelines, which may then be considered or adopted by the FCC pursuant to Section 255. Once the final rule is effective, the FAR Council within six months will incorporate the Revised 508 Standards into the FAR and establish an effective date for application of these revised regulations to new and existing procurements.