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

D. Functional Performance Criteria and Technical Requirements (Section-by-Section Analysis)

Appendix C sets forth proposed functional performance criteria (Chapter 3) and technical requirements (Chapters 4 through 6) that are referenced by, and applied in, the Application and Scoping provisions in the 508 Standards (Appendix A) and 255 Guidelines (Appendix B). The proposed requirements in Appendix C are based on recommendations from the Advisory Committee unless otherwise noted.

Chapter 3: Functional Performance Criteria (Section-by-Section Analysis)

Chapter 3 contains proposed 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 508 Chapter 2 and in 255 Chapter 2. These functional performance criteria would also be used to determine equivalent facilitation under both the proposed 508 Standards and 255 Guidelines. Accordingly, they are referenced by the equivalent facilitation provisions in 508 Chapter 1 and 255 Chapter 1.

301 General (Section-by-Section Analysis)

This is an introductory section.

301.1 Scope (Section-by-Section Analysis)

This section proposes that the functional performance criteria in Chapter 3 be applied where either (a) required by 508 Chapter 2 or 255 Chapter 2, or (b) where referenced by other requirements.

302.1 Without Vision (Section-by-Section Analysis)

This section proposes to revise the criterion for users who are blind. This provision would clarify the requirements in existing 508 Standards §1194.31(a) and 255 Guidelines §1193.41(a) by specifying that provision of a mode of operation without vision is required when the ICT otherwise provides a visual mode of operation.

302.2 With Limited Vision (Section-by-Section Analysis)

This section proposes to revise the functional performance criterion for users with limited vision so that, where a visual mode of operation is provided, one mode of operation that magnifies, one mode that reduces the field of vision, and one mode that allows user control of contrast would be required. This provision contains significant changes from the functional performance criteria in the existing 508 Standards §1194.31(b) and existing 255 Guidelines §1193.41(b). Existing 508 Standards §1194.31(b) requires at least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 to be provided in both audio and enlarged print output working together or independently. Existing 255 Guidelines §1193.41(b) is similar, except that it defines users with limited vision as users possessing visual acuity that ranges between 20/70 and 20/200. For a further discussion of the history of these proposed changes, see Section IV.E.6 (Rulemaking History – 2010 and 2011 ANPRMs: Significant Issues – Modifications to the Functional Performance Criteria for Limited Vision).

Question 17. Some commenters raised concerns with proposed 302.2 With Limited Vision. They recommended that the Board establish thresholds for how much magnification, reduction, or contrast is sufficient to meet the provision. Should proposed 302.2 be more specific, and if so, what should the thresholds be? Please cite a scientific basis for threshold recommendations.

302.3 Without Perception of Color (Section-by-Section Analysis)

This section proposes to add a new functional performance criterion for users with color blindness to better map to technical specifications in the 508 Standards and 255 Guidelines. Section 302.3 would require at least one mode of operation that does not require user perception of color where a visual mode of operation is provided. The technical provisions in existing 508 Standards §§ 1194.25(g) and 1194.21(i), existing 255 Guidelines § 1193.41(c), as well as proposed 407.7, prohibit color coding from being the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

302.4 Without Hearing (Section-by-Section Analysis)

This section proposes to revise the criterion for users who are deaf. This provision would clarify the requirements in existing 508 Standards §1194.31(c) and existing 255 Guidelines §1193.41(d) by specifying that provision of a mode of operation without hearing is required when the ICT otherwise provides an auditory mode of operation.

302.5 With Limited Hearing (Section-by-Section Analysis)

This section proposes to revise the criterion for users with limited hearing. The existing 508 Standards require at least one mode of operation and information retrieval to be provided in an enhanced auditory fashion. The existing 255 Guidelines require that input, control, and mechanical functions be operable with limited or no hearing. Proposed 302.5 is more specific, and would require at least one mode of operation that improves clarity, one mode that reduces background noise, and one mode that allows user control of volume, when an auditory mode of speech is provided.

302.6 Without Speech (Section-by-Section Analysis)

This proposed section would clarify the requirements in existing 508 Standards §1194.31(e) and existing 255 Guidelines §1193.41(h) by specifying that provision of a mode of operation without speech is only required when the ICT provides a spoken mode of operation. This section is primarily intended to address the needs of users who are unable to speak.

302.7 With Limited Manipulation (Section-by-Section Analysis)

In this section, the Board proposes to address the functional performance criterion for users with limited manipulation. The provision would require that, when ICT provides a manual mode of operation, it must also provide at least one mode of operation that does not require fine motor control or operation of more than one control at the same time. The existing 508 Standards address the needs of users with limited manipulation and users with limited reach or strength in the same criterion (see § 1194.31(f)). By contrast, the existing 255 Guidelines address the needs of users with limited manual dexterity and users with limited reach or strength in different provisions (see §§ 1193.41(e) and (f)). Because these conditions do not necessarily exist together, their respective accessibility solutions are best presented separately. The criterion for users with limited reach or strength is set forth in proposed 302.8.

302.8 With Limited Reach and Strength (Section-by-Section Analysis)

In this section, the Board proposes to address the functional performance criterion for users with limited reach or strength. The existing 508 Standards address the needs of users with limited manipulation and users with limited reach or strength in the same criterion (see § 1194.31(f)). By contrast, the existing 255 Guidelines address the needs of users with limited manual dexterity and users with limited reach or strength in different criteria (see §§ 1193.41(e) and (f)). Because these conditions do not necessarily exist together, their respective accessibility solutions are best presented separately. The criterion for users with limited manipulation is set forth in proposed 302.7.

Chapter 4: Hardware (Section-by-Section Analysis)

Chapter 4 contains proposed requirements for hardware that transmits information or has a user interface. Examples of such hardware include computers, information kiosks, and multi-function copy machines. This chapter draws substantively from existing 508 Standards, as well as the technical requirements for automatic teller machines and fare machines in the ADA and ABA Accessibility Guidelines. See 36 CFR Part 1191, Appendix D, section 707. The requirements in this chapter apply under both the proposed 508 Standards and 255 Guidelines absent an express exception.

Most of the proposed hardware requirements are new to the 255 Guidelines. This is because the existing 255 Guidelines parallel only existing 508 Standards §§ 1194.23 Telecommunications products, 1194.31 Functional performance criteria, and 1194.41 Information, documentation, and support. The existing 255 Guidelines do not currently address the other 508 requirements in Subpart B Technical Standards, namely 508 Standards §§ 1194.21 Software applications and operating systems, 1194.22 Web-based intranet and Internet information and applications, 1194.24 Video and multimedia products, 1194.25 Self-contained, closed products, and 1194.26 Desktop and portable computers. A major objective of this rulemaking is to harmonize the 255 Guidelines and 508 Standards.

Yet, while new to the 255 Guidelines, these proposed hardware rules are generally not expected to have a significant cost impact. Due to convergent technologies, a telecommunications product that previously stood alone may now be part of a more complex system. For example VoIP telephone systems may include a web interface used to operate the telephone. While these products have long been required under existing guidelines to be accessible, see, e.g., 255 Guidelines § 1193.41(a) (requiring telecommunications products be operable without vision), the product-by-product based structure of the guidelines results in a multiplicity of accessibility requirements. This proposed rule aims to address this problem by taking a functional approach across technologies, as well as by adding clarity and detail as to what accessible means. For these reasons, the proposed rule is not expected to impose material new costs on manufacturers of telecommunications equipment and customer premises equipment.

With respect to an increasingly ubiquitous type of ICT hardware—self-service transaction machines—the Board has worked collaboratively with the Departments of Justice (DOJ) and Transportation (DOT) to develop a common set of technical requirements that could be referenced and scoped by these agencies in their respective rulemaking initiatives. While each agency has different regulatory authority, self-service transaction machines can be found in a variety of settings, and the accessibility barriers are generally common across these settings. In late 2013, DOT published a final rule implementing the Air Carrier Access Act that addresses accessibility standards for airline websites and automated kiosks located at domestic airports. See 78 FR 67882 (Nov. 12, 2013). The DOT requirements for automated kiosks are consistent with existing 508 Standards for self-contained, closed products. In 2010, DOJ published an ANPRM to solicit public comment on accessibility requirements under the Americans with Disabilities Act for furniture and equipment. See 75 FR 43452 (July 26, 2010). Such requirements would cover, among other things, kiosks, interactive transaction machines, and point-of-sale devices. In a future rulemaking, the Board may update the ADA and ABA Accessibility Guidelines to harmonize those guidelines with the proposed 508 Standards and the 255 Guidelines, once finalized.

401 General (Section-by-Section Analysis)

This is an introductory section.

401.1 Scope (Section-by-Section Analysis)

This section proposes that the technical requirements for hardware in Chapter 4 be applied where (a) required by 508 Chapter 2 or 255 Chapter 2, or (b) where referenced by other requirements. Assistive technology hardware would be excepted from conformance with this chapter. This exception is proposed in response to public comments to the 2010 and 2011 ANPRMs that sought clarification on this point. Commenters expressed the concern that, should this scoping section be read as obligating assistive technology hardware to meet the requirements of this chapter, some assistive technology would not be able to serve its function. For example, people with very low muscle tone might use a specialized membrane keyboard that is completely flat, with no tactilely discernible separation between the keys, because it is the most optimal input device for them. This type of specialized keyboard, however, would not be permitted under proposed 407.3, which addresses tactilely discernible input controls. In light of the specialized nature of assistive technology, the Board proposes it be excepted from the technical requirements in this chapter.

402 Closed Functionality (Section-by-Section Analysis)

This is an introductory section.

402.1 General (Section-by-Section Analysis)

This section proposes to require ICT with closed functionality to be operable without requiring the user to attach or install assistive technology, with the exception of personal headsets or other audio couplers. This provision is needed because, when ICT has closed functionality, the end user typically does not have the option of installing or attaching assistive technology. Closed functionality can also apply to the platform user interface. This is sometimes referred to as “firmware” because it has a software aspect, but is not alterable by the end-user and the user interface is necessarily tied to the hardware platform. The proposed technical requirements for software (Chapter 5) do not specifically address closed functionality, except for the interoperability of software and assistive technology.

Components of ICT subject to the 255 Guidelines would be excepted from the requirements of this section (see C204.1 Exception) because such telecommunications equipment typically has closed functionality. For example, it is often impossible to attach or install assistive technology, such as a specialized keyboard.

Variable message signs (VMS) frequently are installed in federal buildings and facilities to provide information about ongoing events. Some VMS also convey information relevant to emergencies. VMS with closed functionality would be covered by this section. The Board is currently unaware of any VMS technology that provides audible output. However, there is one voluntary consensus standard addressing accessibility of VMS with respect to the needs of persons with low vision. The most recent edition of the International Code Council (ICC)’s “Accessible and Usable Buildings and Facilities” (ICC A117.1-2009) contains specifications for making high-resolution and low-resolution VMS more accessible to people with low vision. For low-resolution signs, these requirements address signage characters (e.g., case, style, height, width, stroke width, and spacing), as well as other characteristics relating to height above the floor, finish, contrast, protective coverings, brightness, and rate of change. High-resolution VMS need only comply with the provisions for character case (uppercase), protective coverings, brightness, and rate of change since they typically meet or exceed the other specifications. In addition, section 1110.4 of the 2012 edition of the International Building Code requires VMS in transportation facilities and in emergency shelters to comply with ICC A117.1 unless equivalent information is provided audibly. The IBC, however, does not require the VMS, itself, to provide the audible message. For example, in a transportation facility, information equivalent to the VMS display can be provided through a public address system.

Question 18. In the final rule, the Board is considering incorporating by reference the requirements for VMS in ICC A117.1-2009—or its successor ICC A117.1-2015, if the standard has been finalized by that time—in order to make such signs more accessible to individuals who are blind or have low vision. The Board seeks comment on the advisability of incorporating by reference the requirements in ICC A117.1-2009 (or its successor) for variable message signs. Are there technologies that would allow a user to receive an audible message generated by the VMS sign? If so, the Board requests that commenters provide information regarding this technology. Until VMS can be made directly accessible to persons who are blind, we recognize that VMS would have to be paired with audible public address announcements. If VMS cannot be speech enabled, should the Board require VMS to, at least, be accessible to people with low vision?

402.2 Speech-Output Enabled (Section-by-Section Analysis)

This section proposes to require ICT with closed functionality that has a display screen to be speech-output enabled. This means that operating instructions and orientation, visible transaction prompts, user input verification, error messages, and all displayed information necessary for full use, would have to be accessible to and usable by individuals with vision impairments. In actual practice, for all but the simplest ICT (e.g., hardware without display screens), this means ensuring that the ICT has built-in speech output. This explicit requirement would be new to the 508 Standards. That is, while the requirement in existing 508 Standards §1194.25(a) has been interpreted as requiring ICT with closed functionality to provide speech output since that is the only means of making such products “usable by people with disabilities without requiring an end-user to attach assistive technology,” there is currently no express mandate for speech output. This proposed section contains two exceptions, which exempt specific types of information from speech output requirements, as discussed below.

Exception 1 to 402.2 Speech-Output Enabled

This section proposes to exclude from the requirement for speech output any user inputted content that is not displayed as entered for security purposes, such as when asterisks are shown on-screen instead of personal identification numbers. Excluded material may be delivered as audible tones, rather than as speech.

Exception 2 to 402.2 Speech-Output Enabled

This section proposes to permit visible output that is not necessary for the transaction being conducted—such as advertisements and similar material—from the requirement for audible output.

402.2.1 User Control (Section-by-Section Analysis)

This section proposes requirements for user control of speech-enabled output concerning interruption upon selection of a transaction, as well as repeat and pause capabilities. This section is similar to § 1194.25(e) of the existing 508 Standards.

402.2.2 Braille Instructions (Section-by-Section Analysis)

This section proposes that, where displays for ICT with closed functionality are required to have speech output, instructions for initiating the speech mode be provided in braille. Braille instructions would be required to conform to specifications for braille in the ADA and ABA Accessibility Guidelines. See ADA and ABA Accessibility Guidelines, 36 CFR Part 1191, Appendix D, section 703.3. This requirement would be new to the 508 Standards. For telecommunications equipment and customer premises equipment subject to Section 255, this requirement is inapplicable; an exception to proposed C204.1 expressly exempts such ICT from this hardware requirement. This proposal was included in the 2011 ANPRM, and the Board received no comments.

402.3 Volume (Section-by-Section Analysis)

This section proposes to require two alternate standards for volume control and output amplification on ICT with closed functionality that delivers sound, depending on whether such sound is being conveyed for private or non-private listening. An exception also provides that ICT conforming to 410.2, which addresses volume gain for ICT with two-way voice communication, would be exempted from complying with this section.

402.3.1 Private Listening (Section-by-Section Analysis)

This section proposes to require that, where ICT subject to 402.3 provides a mechanism for private listening—such as a handset or headphone jack—it must have a mode of operation for controlling the volume, and provide a means for effective magnetic wireless coupling to hearing technologies. This proposed requirement would be new to the 508 Standards.

402.3.2 Non-private Listening (Section-by-Section Analysis)

This section proposes to require that, where ICT subject to 402.3 provides non-private listening, incremental volume control must be provided with output amplification up to a level of at least 65 dB. In addition, where the ambient noise level of the environment is above 45 dB, a volume gain of at least 20 dB above the ambient level would be required and must be user selectable. This provision would require a function to be provided to automatically reset the volume to the default level after every use. This section closely corresponds to § 1194.25(f) in the existing 508 Standards.

402.4 Characters (Section-by-Section Analysis)

This section proposes to require that at least one mode of characters displayed on a screen be in sans serif font. In addition, where ICT does not provide a screen enlargement feature, characters would be required to have a minimum height requirement of 3/16 inch based on the uppercase letter “I.” This section would also require that characters contrast with their background with either light characters on a dark background or dark characters on a light background. This section would be new to the 508 Standards.

403 Biometrics (Section-by-Section Analysis)

This is an introductory section.

403.1 General (Section-by-Section Analysis)

This section proposes to prohibit biometrics from being the only means for user identification or control unless at least two different biometric options using different biological characteristics are provided. This new exception was recommended by the Advisory Committee. Without the added exception, the language in this section is substantially unchanged from § 1194.25(d) of the 508 Standards, but would be new to the 255 Guidelines.

404 Preservation of Information Provided for Accessibility (Section-by-Section Analysis)

This is an introductory section.

404.1 General (Section-by-Section Analysis)

This section proposes to prohibit ICT that transmits or converts information or communication from removing non-proprietary information provided for accessibility or, if the non-proprietary information or communication is removed, this section would require that it be restored upon delivery. For example, a video or multimedia presentation with closed captioning would be required to retain the caption encoding, or, if removed in transmission, then restore such encoding upon delivery. This provision closely models §§ 1194.23(j) and 1193.37 of the 508 Standards and 255 Guidelines, respectively.

405 Flashing (Section-by-Section Analysis)

This is an introductory section.

405.1 General (Section-by-Section Analysis)

This section proposes that, where ICT emits lights in flashes, there can be no more than three flashes in any one-second period. An exception would allow small flashes not exceeding the general flash and red flash thresholds defined in Success Criterion 2.3.1 of WCAG 2.0 because such flashes do not pose seizure risks to users. This requirement is based on recommendations from the Advisory Committee. This proposed section closely corresponds to existing 508 Standards §§ 1194.21(k), 1194.22(j), and 1194.25(i), and is similar to § 1193.43(f) of the existing 255 Guidelines. The flash rate specification in this section is supported by scientific studies on seizures and photosensitivity.⁹

406 Standard Connections (Section-by-Section Analysis)

This is an introductory section.

406.1 General (Section-by-Section Analysis)

This section proposes that, where ICT provides data connections used for input and output, at least one of each type of data connection conform to industry standard non-proprietary formats, e.g., jacks and plugs. This proposed section closely corresponds to § 1194.26(d) of the existing 508 Standards and § 1193.51(a) of the existing 255 Guidelines. The intent of this provision is to support compatibility with assistive technology hardware.

407 Operable Parts (Section-by-Section Analysis)

This is an introductory section.

407.1 General (Section-by-Section Analysis)

This section addresses accessibility features of operable parts—such as keys and controls—when part of the user interface is hardware. This section proposes to require operable parts of ICT to conform to the technical requirements in proposed 407.2, 407.3, and 407.4. This section is consistent with requirements in existing 508 Standards §§ 1194.21 and 1194.25, along with § 1193.41(f) of the existing 255 Guidelines.

407.2 Contrast (Section-by-Section Analysis)

This section proposes that keys and controls, where provided, contrast visually from background surfaces. Characters and symbols would have to provide this contrast with either light characters or symbols on a dark background or dark characters or symbols on a light background. The goal of this section is to make operable parts of hardware on ICT more usable for persons with low vision. A contrast requirement for hardware was recommended by the Advisory Committee. It would be new to the 508 Standards and 255 Guidelines.

407.3 Tactilely Discernible (Section-by-Section Analysis)

This section proposes to require that at least one tactilely discernible input control conforming to the requirements of this section be provided for each function. ICT containing touchscreens is widely used in the marketplace. Touchscreens currently are not generally tactilely discernible. This requirement would not prohibit use of touchscreens, membrane keys, or gesture input, provided there is at least one alternative method of input that is tactilely discernible. The intent of this proposed section is to address the difficulty certain people with visual and dexterity impairments often have when using touchscreens. This section, which contains subsections for three types of functions (i.e., identification, alphabetic keys, and numeric keys) is new to the 255 Guidelines, but is consistent with existing 508 Standards §§ 1194.23(k)(1)-(k)(4), with some changes as discussed below.

The Board is also proposing an exception to the requirement for tactile discernibility for touchscreen-based devices in today’s marketplace that have proven to be accessible to—and popular with—people with visual disabilities. Specifically, the proposed exception would exempt devices for personal use offering input controls that (a) are audibly discernible without activation, and (b) operable by touch. Examples of currently available devices without tactilely discernible keyboards that are still navigable and usable by individuals with visual disabilities include devices offered by Apple with the iOS-based VoiceOver feature, such as the iPhone® and iPad®. Technology has evolved to the point where touch screens can be made navigable by blind users. Keyboards are an optional design feature. This proposed exception would be a significant departure from the 508 Standards and 255 Guidelines, but more accurately reflects the state of current technology. We welcome comment on this proposed approach.

In addition, the Board is considering adding to the final rule a requirement that at least one type of input technology on ICT with touch screens be compatible with a prosthetic, similar to the requirement in existing 255 Guidelines § 1193.51(c).

Question 19. Does the proposed exception to the requirement for tactilely discernible input controls strike the appropriate balance so that it permits innovative accessibility approaches for individuals with visual impairments without being overbroad? Should there be additional requirements for touchscreens? For example, should the Board require touchscreens to be compatible with prosthetic devices?

407.3.1 Identification (Section-by-Section Analysis)

This section proposes to require input controls to be tactilely discernible without activation, as well as operable by touch. It also would require key surfaces outside active areas of display screens to be raised above their surrounding surfaces. The Board notes that, by requiring raised key surfaces, it does not thereby intend to prohibit contouring of keys. Users with limited manual dexterity may prefer concave keys. Contoured keys would be permitted under proposed 407.3.1, for example, by providing keys with raised edges and concave centers, as is often used on computer keyboards and landline telephone keypads. This section is new to the 255 Guidelines, but is similar to existing 508 Standards §§ 1194.23(k)(1), 1194.25(c), and 1194.26(b). It is also consistent with the requirements for input controls in the ADA and ABA Accessibility Guidelines. See 36 CFR Part 1191, Appendix D, section 707. This is not a material change from the existing standards, and therefore, imposes no new costs.

Question 20. Some industry commenters to the 2011 ANPRM suggested that the Board permit concave—as well as raised—key surfaces. What would be the impact on accessibility if proposed 407.3.1 instead prohibited key surfaces outside the active area of the display screen from being flush with surrounding surfaces?

407.3.2 Alphabetic Keys (Section-by-Section Analysis)

This section proposes to require alphabetic keys, where provided, to be arranged in a traditional QWERTY layout, with tactilely distinct letter “F” and “J” keys. The requirement for tactilely discernible home row keys derives from existing 508 Standards § 1194.23(k)(1), but would be a new requirement for the 508 Standards and 255 Guidelines. The intent of this section is to address identification and orientation when alphabetic key entry is used. This section was added to the proposed rule at the request of commenters to the 2011 ANPRM, who suggested that a requirement for alphabetic keys was needed to complement the proposed requirement for numeric key layout (proposed 407.3.3). Where a numeric keypad with an alphabetic overlay is provided (such as on a telephone keypad), the relationships between letters and digits would be required to conform to ITU-T Recommendation E.161, as incorporated by reference in 508 Chapter 1 and 255 Chapter 1.

This requirement for a QWERTY layout in keyboards and conformance to ITU-T Recommendation E.161, while new to the 508 Standards and 255 Guidelines, represents current design practice. Accordingly, there should be no additional cost associated with this provision.

407.3.3 Numeric Keys (Section-by-Section Analysis)

This section proposes to require numeric keys, where provided, to be arranged in a 12-key ascending or descending keyboard layout, with a tactilely distinct number “5” key. The requirement for a tactilely discernible “5” key derives from existing 508 Standards § 1194.23(k)(1), but would be a new requirement for the 508 Standards and 255 Guidelines. The intent of this section is to address identification and orientation when numeric data entry is used.

407.4 Key Repeat (Section-by-Section Analysis)

This section proposes to require that, where a keyboard with a key repeat feature is provided, the delay before activation of the key repeat feature must be fixed at, or adjustable to, 2 seconds minimum. The intent of this section is to address the unintentional activation of keys by people with dexterity impairments. The proposed requirement closely corresponds to existing 508 Standards §§ 1194.23(k)(3), 1194.25(c), and 1194.26(b), but is new to the 255 Guidelines. Because telecommunications products generally do not have a key repeat feature, the Board expects the impact of this provision on telecommunications equipment manufacturers to be negligible.

407.5 Timed Response (Section-by-Section Analysis)

This section proposes to require that where a timed response is required, ICT would have to alert the user visually, as well as by touch or sound. It would also have to provide the user an opportunity to indicate that more time is needed. The intent of this section is to afford people with certain disabilities—namely, those relating to manual dexterity, cognitive disabilities, or otherwise affecting response time—additional time to complete a task, if needed. The proposed requirement is consistent with existing 255 Guidelines § 1193.41(g), and closely corresponds to existing 508 Standards §§ 1194.25(b) and 1194.22(p).

407.6 Status Indicators (Section-by-Section Analysis)

This section would require status indicators, including all locking or toggle controls or keys, such as “Caps Lock” and “Num Lock,” to be discernible visually and by either touch or sound. The intent is to ensure that users who are blind can determine the status of locking or toggle keys audibly or by touch, and that users who are deaf can make this determination visually. This proposed provision closely corresponds to existing 508 Standards §§ 1194.23(k)(4), 1194.25(c), and 1194.26(b), but would be new to the 255 Guidelines. While new to the 255 Guidelines, status indicators for Caps Lock and Num Lock controls represent current design practice. Accordingly, there should be no additional cost associated with this provision.

407.7 Color (Section-by-Section Analysis)

This section proposes to prohibit color-coding from being the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. The proposed section is the same as existing 508 Standards § 1195.25(g), and is consistent with 255 Guidelines § 1193.41(c). The use of color is also addressed in existing 508 Standards § 1194.22(c), which requires that Web pages “be designed so that all information conveyed with color is also available without color, for example from context or mark up.” The intent of the proposed section is to address the needs of people who are color blind or have low vision. The proposed prohibition on color-coding represents current practice in the design of electronic content and, therefore, should not result in any additional cost.

407.8 Audio Signaling (Section-by-Section Analysis)

This section proposes to prohibit audio signaling from being the only means of conveying information, indicating an action, or prompting a response. For example, when a landline telephones provides a stutter tone to indicate a voice mail message, such a tone is typically accompanied by an activated light on the phone. This proposal closely parallels the prohibition in existing 508 Standards § 1194.25(g) against use of color as the only means of conveying information. The section is intended to address the needs of individuals with hearing impairments in the same way that proposed 407.7 addresses the needs of persons who have color blindness. Although an express prohibition on audio signaling would be new to the 508 Standards and 255 Guidelines, such a prohibition is implied by the existing functional performance criteria (508 Standards § 1194.31(c)), and represents current industry practice. This proposed provision should not, therefore, result in any significant cost increase.

407.9 Operation (Section-by-Section Analysis)

This section would require ICT with operable parts to provide at least one mode of operation that is operable with one hand, and prohibits operable parts requiring tight grasping, pinching, or twisting of the wrist. The force required to activate operable parts would be limited to 5 lbs. (22.2 N) maximum. The proposed requirement closely corresponds to existing 508 Standards §§ 1194.23(k)(2), 1194.25(c), and 1194.26(b), and is consistent with existing 255 Guidelines §§ 1193.41(e) and (f). This section is aimed at addressing the needs of people with manual dexterity impairments when using operable parts.

407.10 Privacy (Section-by-Section Analysis)

This proposed section would require the same degree of privacy of input and output for all individuals. For example, individuals using a speech output mode must be afforded the same degree of privacy as those using a display screen. The proposed requirement would be new to both the 508 Standards and 255 Guidelines. ATMs and Fare Vending Machines, as addressed in the ADA and ABA Accessibility Guidelines (36 CFR Part 1191, Appendix D, section 707.4), typically support compliance with this requirement by providing a handset or audio jack. Additionally, this proposed section would prohibit screens from automatically going blank when the speech function is engaged. Many people with low vision use speech output to supplement or reinforce on-screen prompts. Consequently, automatically blanking the screen would render the ICT less accessible to these users. Provision of an option for users to blank the screen, however, may be helpful to individuals who desire greater privacy.

407.11 Keys, Tickets, and Fare Cards (Section-by-Section Analysis)

This section would require that, when kiosks or other ICT provide a key, ticket, or fare card, those objects have a tactilely discernible orientation, if orientation is important to the object’s further use. This requirement would be new to the 508 Standards and 255 Guidelines, and is intended to address the needs of individuals with visual impairments. This section is identical to the recently issued final rule by the Department of Transportation concerning the accessibility of tickets and boarding passes issued by shared-use automated kiosks at airport facilities. See Nondiscrimination on the Basis of Disability in Air Travel: Accessibility of Web Sites and Automated Kiosks at U.S. Airports, 78 FR 67882 (Nov. 12, 2013) (to be codified at 49 CFR Part 27). ICT subject to the 255 Guidelines would be expressly exempted from the requirements of this section (by proposed C204.1 Exception) because telecommunications equipment does not typically issue keys, tickets, or fare cards.

407.12 Reach Height (Section-by-Section Analysis)

This section proposes requirements for the height of side and forward reaches that would enable persons using wheelchairs or other mobility aids to reach and operate at least one of each type of operable part. This proposed section would apply only to ICT that is stationary. By “stationary,” the Board means that the ICT, once put in place, is not intended to be relocated for routine use. Proposed 407.12 parallels existing 508 Standards § 1194.25(j), which applies side reach requirements to ICT that is “freestanding, non-portable, and intended to be used in one location.” We are proposing to use the term “stationary” to address concerns that the word “freestanding” implies an independent supporting structure that may not always be in place, such as with a multifunction printer specifically designed for table-top or desk-top use.

Specifically, this section would establish requirements for position (i.e., vertical reference plane), forward reach, and side reach. This section proposes maximum and minimum reach heights for either forward (over the lap) or side reaches to stationary ICT. Existing 508 Standards § 1194.25(j) only provides specifications for side reaches to operable parts of ICT. This section would provide greater design flexibility by permitting controls to be configured for either forward reach (407.12.3) or side reach (407.12.2). This flexibility would allow manufacturers to assess conformance prior to sale and independent of factors outside their control. For example, a manufacturer cannot control the installation location once ICT is purchased. However, because controls are designed to be within reach, the purchaser can then ensure that the ICT is located so that at least one of each type of control is accessible to individuals with disabilities. ICT subject to the 255 Guidelines would be expressly exempted from the requirements of this section (by proposed C204.1 Exception) because it is not typically stationary.

Question 21. Should the requirements for reach height in proposed 407.12 apply to ICT subject to the 255 Guidelines, such as, for example, routers attached to racks? The Board asks that telecommunications equipment manufacturers provide information on the costs of such a requirement. Are there alternative ways of making these components accessible? We welcome comments on suggested approaches.

407.12.1 Vertical Reference Plane (Section-by-Section Analysis)

This section proposes that the positioning of operable parts for side reaches and forward reaches be determined with respect to a vertical reference plane, with the location and length of the plane dependent on the type of reach.. The provisions for a side reach in existing 508 Standards § 1194.25(j)(1) contain references to this same vertical reference plane.

407.12.1.1 Vertical Plane for Side Reach (Section-by-Section Analysis)

This section proposes that, where a side approach is provided, the vertical reference plane must have a minimum length of 48 inches. The 48-inch dimension is based on the length of a stationary occupied wheelchair. This side reach requirement mirrors existing 508 Standards § 1194.25(j)(1) and Figure 1.

407.12.1.2 Vertical Plane for Forward Reach (Section-by-Section Analysis)

This section proposes that, where a forward reach is provided, the vertical reference plane must be, at a minimum, 30 inches long. The 30-inch dimension is based on the width of a stationary occupied wheelchair. This dimension is consistent with the ADA and ABA Accessibility Guidelines (36 CFR Part 1191, Appendix D, section 305.5).

407.12.2 Side Reach (Section-by-Section Analysis)

This section specifies proposed requirements for operable parts providing unobstructed or obstructed side reaches. It proposes to limit the height of the portion of the ICT over which a person must reach to access controls to 34 inches maximum in height. Although the existing 508 Standards do not include a maximum height for the portion of the ICT over which a person must reach, the proposed 34 inches maximum height is consistent with ICC A117.1-2009, as well as the ADA and ABA Accessibility Guidelines (36 CFR Part 1191, Appendix D, section 308). Without such a height limitation, controls at 48 inches could be out of reach if an obstruction blocked a user’s arm and impeded his or her reach to the controls.

407.12.2.1 Unobstructed Side Reach (Section-by-Section Analysis)

This section proposes that, where the operable part is located 10 inches or less behind the vertical reference plane, the operable part must be 48 inches high maximum and 15 inches high minimum above the floor. Although existing 508 Standards § 1194.25 (j)(2) permits a maximum reach height of 54 inches, it contains the same minimum height (15 inches) and 10-inch reach depth. The proposed lowering of the maximum height for unobstructed side reach (i.e., from 54 inches in the existing 508 Standards to 48 inches in this proposed rule) reflects a similar change in 2004 to the ADA and ABA Accessibility Guidelines. See 36 CFR Part 1191, Appendix D, section 308.3. This proposed maximum height is also consistent with accessible reaches specified in the 1998 edition, as well as two subsequent editions, of the ICC A117.1.

407.12.2.2 Obstructed Side Reach (Section-by-Section Analysis)

This section proposes that, where the operable part is located more than 10 inches, but not more than 24 inches, behind the vertical reference plane, the height of the operable part must be 46 inches maximum and 15 inches minimum above the floor. In addition, the operable part would not be permitted to be located more than 24 inches behind the vertical reference plane. Although it is editorially revised, this section is the same as existing 508 Standards §§ 1194.25(j)(3) and 1194.25(j)(4).

407.12.3 Forward Reach (Section-by-Section Analysis)

This section contains proposed requirements for operable parts providing either an unobstructed or obstructed forward reach. This section proposes to limit the height of an obstruction that must be reached over to operate the control to 34 inches in height. The 34-inch height restriction is consistent with the ADA and ABA Accessibility Guidelines. See 36 CFR Part 1191, Appendix D, section 308. The proposed provision would also require the vertical reference plane to be centered on, and intersect with, the operable part.

As noted previously, the existing 508 Standards do not provide specifications for forward reaches. While this requirement (and its subsections) would thus be new to the existing 508 Standards, it nonetheless would provide greater design flexibility by permitting controls to be configured for forward reach (or, alternatively, side reach), at the manufacturer’s discretion.

407.12.3.1 Unobstructed Forward Reach (Section-by-Section Analysis)

This section proposes that, where an unobstructed forward reach is provided, the operable part must be located 48 inches high maximum and 15 inches high minimum above the floor. An unobstructed forward reach, for purposes of this section, occurs when the operable part is located at the leading edge of the maximum protrusion within the length of the vertical reference plane of the ICT. These dimensions and their resulting geometry are consistent with the ADA and ABA Accessibility Guidelines (36 CFR Part 1191, Appendix D, sections 306 and 308).

407.12.3.2 Obstructed Forward Reach (Section-by-Section Analysis)

This section proposes that, where an obstructed forward reach is provided, the maximum allowable forward reach to an operable part would be 25 inches. An obstructed forward reach, for purposes of this section, occurs when the operable part is located behind the leading edge of the maximum protrusion within the length of the vertical reference plane of the ICT. In addition, this proposed section also contains subsections, as discussed below, establishing maximum heights for operable parts with obstructed forward reaches, as well as dimensions for knee and toe spaces. These dimensions and their resulting geometry are consistent with the ADA and ABA Accessibility Guidelines (36 CFR Part 1191, Appendix D, sections 306 and 308).

407.12.3.2.1 Height (Section-by-Section Analysis)

This section, presented in tabular form (Table 407.12.3.2.1), proposes alternative maximum heights for operable parts with obstructed forward reaches depending on reach depth. As specified in this table, if the reach depth of the operable part is less than 20 inches, then the operable part must be no higher than 48 inches. If the reach depth of the operable part is 20 inches to 25 inches, then the operable part must be no higher than 44 inches. These dimensions and their resulting geometry are consistent with the ADA and ABA Accessibility Guidelines (36 CFR Part 1191, Appendix D, sections 306 and 308).

407.12.3.2.2 Knee and Toe Space (Section-by-Section Analysis)

This section proposes dimensions for knee and toe space under ICT when an obstructed forward reach is provided. The dimensions necessary to accommodate the full knee and toe space under ICT would be 27 inches high minimum, 25 inches deep maximum, and 30 inches wide minimum. This knee and toe space would also have to be clear of obstructions. These dimensions and their resulting geometry are consistent with the ADA and ABA Accessibility Guidelines (36 CFR Part 1191, Appendix D, sections 306 and 308).

There are two proposed exceptions to this knee and toe space requirement. First, toe space with a reduced clear height of 9 inches (rather than 27 inches) would be permitted for a depth of no more than 6 inches. Building on this exception, the second exception would allow further reduction in the height of the space along the profile of the knee to the toe sloping at 6:1 toward the maximum protrusion of the ICT. This means that, for every 6 inches of height, the line can move toward the maximum protrusion of the ICT up to 1 inch or, put another way, 6 inches of rise to 1 inch of run. These two exceptions allow ICT to provide space beneath operable controls for ICT for knees and toes, or a portion of knees and toes, depending on the location of the controls.

408 Display Screens (Section-by-Section Analysis)

This is an introductory section.

408.1 General (Section-by-Section Analysis)

This section proposes to require that, where stationary ICT provides one or more display screens, at least one of each type of screen must be visible from a point located 40 inches above the floor space where the display screen is to be viewed. The word “stationary” in this proposed section would have the same meaning as in proposed 407.12. The intent of this provision is to ensure that display screens are viewable by individuals who use wheelchairs or other mobility aids. This would be a new requirement for the 508 Standards. ICT subject to the 255 Guidelines would be expressly exempted from the requirements of this section (by proposed C204.1 Exception) because such equipment is not typically stationary.

Question 22. The visibility requirements for display screens in section 408.1 apply only to stationary ICT (i.e., ICT that is not intended to be moved once put in place), and, consequently, would not generally apply to telecommunications equipment subject to the 255 Guidelines—such as cable modems and routers. Should the requirements for display screens apply to ICT subject to the 255 Guidelines?

In addition to the proposed requirements above, the Board is considering establishing a requirement for the angle of the display screen to be adjustable, so that a person using a wheelchair or other mobility aid could see the entire viewable area of the display screen and minimize the effect of glare.

Question 23. Should the Board add a requirement that the viewing angle of display screens be adjustable to permit wheelchair users or persons of small stature to see the entire viewable area of such screens and minimize glare? Are there other characteristics of display screens that would make them more viewable to persons who use wheelchairs or other mobility aids?

409 Transactional Outputs (Section-by-Section Analysis)

This is an introductory section.

409.1 General (Section-by-Section Analysis)

This section proposes that, where transactional outputs—such as tickets and receipts—are provided by ICT with speech output, the speech output must contain all information necessary to complete or verify a transaction. As applied to ICT with closed functionality and display screens required to be speech-output enabled under proposed 402.2, this section would require all information necessary to complete or verify a transaction, including information printed on receipts or tickets, to be provided audibly.

This proposed requirement in 409.1 would be new to the 508 Standards. ICT subject to the 255 Guidelines would be expressly exempted from the requirements of this section (by proposed C204.1 Exception) because telecommunications equipment generally does not provide transactional outputs. For ICT covered by the 508 Standards, there would be exceptions for three specific types of transactional outputs: information unrelated to the substance of particular transactions (e.g., machine location and identifier, time of transaction); information already presented audibly during the same transaction; and, lastly, itineraries, maps, and other visual images. Each of these exceptions is discussed below.

Question 24. Do the three proposed exceptions to 409.1 adequately cover the types of information that should be exempted from the requirement for audible presentation of transactional outputs? Are there other types of information typically provided on transaction outputs that should be exempted? Should the Board limit the types of transactional outputs required to be presented audibly to certain types of outputs, e.g., tickets or sales receipts?

Exception 1 to 409.1

Proposed Exception 1 would exempt information regarding the machine location, date and time of transaction, customer account number, and the machine identifier from the proposed requirement for audible transaction output. Although this information may be on printed receipts and other transactional outputs, it is not typically consulted by the user during, or immediately following, a transaction. This proposed exception is based on an exception to the requirements for speech output at Automated Teller Machines and Fare Vending Machines in the ADA and ABA Accessibility Guidelines. See 36 CFR Part 1191, Appendix D, section 707.5.2 Exception 1.

Exception 2 to 409.1

Proposed Exception 2 would exempt all information that is part of a transactional output from the proposed requirement if it has already been presented audibly at another point during the same transaction. For example, if a user purchasing stamps on a self-service U.S. Post Office machine selected a particular commemorative stamp and the selected stamp name was presented in an audible format previously in that same transaction, it need not be repeated when the machine issues the stamp.

Exception 3 to 409.1

Proposed Exception 3 would exempt itineraries, maps, or other visual images that are provided on ticketing machines from being required to be presented in an audible format. This exception is proposed in recognition of the technical challenges posed by audible presentation of visual images.

Question 25. Are there requirements in proposed Exception 3 to 409.1 sufficiently clear?

410 ICT with Two-Way Voice Communication (Section-by-Section Analysis)

This is an introductory section.

410.1 General (Section-by-Section Analysis)

This section addresses the accessibility of telecommunications equipment that offers two-way voice communication (i.e., an interactive, multi-party voice communication occurring in real time), including both older technologies (such as landline telephones and two-way pagers) and more modern ICT (such as mobile wireless devices). It would also apply to two-way video communication when the video also transmits voice communication. Proposed 410.1 would require ICT with two-way voice communication functionality to conform to the technical requirements in proposed 410.2 through 410.8, which cover, among other things: volume gain magnetic coupling, minimization of interference, real-time text functionality, and video communication.

410.2 Volume Gain (Section-by-Section Analysis)

This section proposes to require ICT with two-way communication to provide volume gain conforming to the FCC’s current regulation at 47 CFR 68.317, which establishes technical standards for volume control on analog and digital telephones to facilitate hearing aid compatibility. The proposed section would replace existing 508 Standards § 1194.23(f) and existing 255 Guidelines § 1193.43(e). The Advisory Committee recommended that the Board adopt the FCC’s volume gain requirements for landline ICT with two-way voice communication.

In July 2013, the FCC issued a request for comment on a petition for rulemaking filed by a telecommunications industry group requesting that the agency revise its hearing aid compatibility volume control gain requirements for analog and digital telephones.¹⁰ The Telecommunications Industry Association (TIA) petition urged the Commission to issue a notice of proposed rulemaking to, among other things, update its Part 68 rule to incorporate the most recent TIA standard for hearing aid compatibility volume control on telephones: ANSI/TIA-4965, Receive Volume Control Requirements for Digital and Analog Wireline Handset Terminals (2012). 28 FCC Rcd. at 10338-39. At present, the Commission’s regulation at § 68.317 sets forth separate requirements for analog and digital telephones based on speech amplification metrics known as “Receive Objective Loudness Rating” (ROLR). ANSI/TIA-4965, on the other hand, uses a new amplification metric—referred to as “conversational gain”—to establish requirements for both analog and digital telephones.

While the “conversational gain” method of measuring amplification for wireline phones in ANSI/TIA-4965 may hold promise, it would be premature for the Board to reference this standard unless and until it is adopted by the FCC. As the lead regulatory agency on hearing aid compatibility standards for wireline telephones, the FCC is in the best position to assess the technical merits, as well as costs and benefits, of referencing this new TIA standard in any subsequent revisions to its existing regulation in Part 68.

Question 26. The Board proposes to adopt 47 CFR 68.317, which is the FCC’s current regulatory standard addressing volume control for analog and digital telephones. In the future, should the FCC revise its regulation and incorporate by reference ANSI/TIA-4965 (or any other consensus standard) for wireline phones, the Board plans to update its regulations—as needed— to reflect revisions by the Commission. We seek comment on this proposed course of action.

410.3 Magnetic Coupling (Section-by-Section Analysis)

This section proposes to require that, where ICT with two-way voice communication delivers output by an audio transducer that is typically held up to the ear, it provide a means for effective magnetic wireless coupling to hearing technologies, such as hearing aids, cochlear implants, and assistive listening devices. This section is equivalent to §§ 1194.23(h) and 1193.43(i) of the existing 508 Standards and 255 Guidelines, respectively.

410.4 Minimize Interference (Section-by-Section Analysis)

This proposed section would require wireless handsets and digital wireless devices to reduce interference with hearing technologies to the lowest possible level, with interference specifications set forth in proposed subsections 410.4.1 (wireless handsets) and 410.4.2 (digital wireline). This section closely corresponds to existing 508 Standards § 1194.23(i) and 255 Guidelines § 1193.43(h), but also incorporates by references consensus standards developed since the 508 Standards and 255 Guidelines were published.

The proposed subsections 410.4.1 and 410.4.2 refer to industry-accepted standards for performance requirements for mobile and landline telephones.

410.4.1 Wireless Handsets (Section-by-Section Analysis)

This section proposes that ICT in the form of wireless handsets—that is, cellular telephones—would be required to conform to ANSI/IEEE C63.19-2011, as incorporated by reference in 508 Chapter 1 and 255 Chapter 1.

410.4.2 Digital Wireline (Section-by-Section Analysis)

This section proposes that ICT in the form of digital wireline devices (such as VoIP-based office desk telephones) would be required to conform to TIA 1083, as incorporated by reference in 508 Chapter 1 and 255 Chapter 1.

410.5 Digital Encoding of Speech (Section-by-Section Analysis)

This section proposes to require ICT with two-way voice communication to transmit and receive digitally encoded speech in the manner specified by ITU-T Recommendation G.722, a consensus standard for encoding and storing digital audio information that is incorporated by reference in 508 Chapter 1 and 255 Chapter 1. An exception for closed systems would exempt such systems from conformance to ITU-T Recommendation G.722 provided that they conform to another standard that ensures equivalent or better acoustic performance and support conversion to ITU-T Recommendation G.722 at their borders. This provision was recommended by the Advisory Committee to help improve auditory clarity for persons with hearing impairments. It is new to both the 508 Standards and 255 Guidelines.

410.6 Real-Time Text Functionality (Section-by-Section Analysis)

This proposed section establishes requirements for RTT functionality for ICT that provides real-time voice communication. As noted previously, both the Advisory Committee and the Board believe that RTT represents an important technological advance that provides an equivalent alternative to voice communications for persons who are deaf, as well as those with limited hearing or speech impairments. RTT delivers a more interactive, conversational communication experience compared to standard text messaging. It also provides superior speed and reliability in emergency situations. Furthermore, RTT permits the user to communicate using mainstream devices—such as mobile phones—rather than having to use specialized and expensive devices (such as TTYs). See discussion above in Section IV.E.4 (Rulemaking History – 2010 and 2011 ANPRMs: Significant Issues – Coverage of Real-Time Text), and Section V.D (Major Issues – Real-Time Text).

Proposed 410.6 would require that, where ICT supports real-time voice communication, it must also support RTT functionality. Subsections of this proposed provision would, in turn, establish technical requirements for display, text generation, and interoperability. Importantly, proposed 410.6 would not mandate that all ICT provide RTT functionality. Rather, only those ICT that already have real-time voice communication capabilities would be required to support RTT functions. In this way, the Board’s approach to requirements for RTT in the proposed rule mirrors the approach taken in the existing 508 Standards and 255 Guidelines toward TTY compatibility. Neither the existing standards and guidelines nor the proposed rule establish an across-the-board command that telecommunications equipment or devices “build in” text capability. Instead, both sets of rules simply require that, when such equipment or devices offer voice communication functions, they must also ensure compatibility with certain types of text communication (i.e., TTY and RTT) by supporting use of specified cross-manufacturer, non-proprietary signals. See 36 CFR 1193.51((e), 1194.23(b).

410.6.1 Display of Real-Time Text (Section-by-Section Analysis)

This proposed section is new to the 508 Standards and 255 Guidelines and would require that, wherever ICT provides real-time voice communication and includes a multi-line screen, the ICT must also support the display of real-time text. This provision would not apply to telecommunications devices that either do not have display screens, or only have display screens capable of showing one line of text at a time.

410.6.2 Text Generation (Section-by-Section Analysis)

This proposed section is new to the 508 Standards and 255 Guidelines and would require that, wherever ICT provides real-time voice communication and includes a keyboard, the ICT must also support the generation of real-time text.

410.6.3 Interoperability (Section-by-Section Analysis)

This section proposes that, where ICT with real-time two-way voice communication operates outside of a closed network or connects to another system, such ICT must ensure real-time text interoperability by using one of two cross-manufacturer, non-proprietary consensus standards depending on the nature of the system with which it is exchanging information—namely, a traditional telephone network or Internet-based telephony.

410.6.3.1 PSTN (Section-by-Section Analysis)

This section proposes that, where ICT with real-time two-way voice communication interoperates with the publicly switched telephone network (PSTN), real-time text conform to TIA 825-A (incorporated by reference in 508 Chapter 1 and 255 Chapter 1). This is the current industry standard for TTY signals (also known as Baudot) at the PSTN interface.

410.6.3.2 VoIP Using SIP (Section-by-Section Analysis)

This section proposes that, where ICT with real-time two-way voice communication interoperates with “Voice over Internet Protocol” (VoIP) products or systems that use Session Initiated Protocol (SIP), real-time text conform to RFC 4103 (incorporated by reference in 508 Chapter 1 and 255 Chapter 1). In Question 8 above, see Section V.D., the Board seeks comment regarding the potential benefits, costs, and drawbacks associated with referencing other standards in addition to RFC 4103.

410.6.4 Voice Mail, Auto-Attendant, and IVR Compatibility (Section-by-Section Analysis)

This section proposes that, where ICT provides real-time two-way voice communication, any associated voice mail, auto-attendant, and interactive voice response systems must be compatible with real-time text functionality. This section derives from existing 508 Standards §§ 1194.23(c)-(e), as well as existing 255 Guidelines §§ 1193.51(d)-(e).

410.6.5 HCO and VCO Support (Section-by-Section Analysis)

This section proposes that, where ICT provides real-time two-way voice communication, it must permit users to intermix speech with the use of real-time text. Such ICT would also be required to support modes that are compatible with Hearing Carry Over (HCO) and Voice Carry Over (VCO). This provision is collectively derived from existing 508 Standards § 1194.23(a) and 255 Guidelines § 1193.51(d), and is consistent with changes in technology over time from TTYs to real-time text functionality. It is particularly significant in preserving the use of HCO/VCO with evolving technology.

410.7 Caller ID (Section-by-Section Analysis)

This section proposes that, where ICT provides two-way voice communication, any associated caller identification or similar telecommunications functions must be presented in both visual (e.g., text) and auditory formats. This requirement would be new to the 255 Guidelines, but corresponds to a similar requirement in § 1194.23(e) of the existing 508 Standards. This proposed requirement could be met, for example, by having the system provide Caller ID in an auditory format, or by ensuring that Caller ID is available to assistive technology. Presentation of Caller ID in both visible and auditory forms ensures that individuals with visual impairments, hearing loss, or both, could use Caller ID and similar services, when provided.

410.8 Video Communication (Section-by-Section Analysis)

This section proposes that ICT with real-time video functionality must ensure that the quality of the video is sufficient to support communication through sign language. This proposed section would be new to both the 508 Standards and 255 Guidelines. The Advisory Committee recommended that the Board include a provision requiring ICT used to transmit video communications in real-time to meet certain specifications for video quality and fluidity (i.e., speed, data stream, and latency). See TEITAC Report, Part 6. Subpt. C, Rec. 6-E.

The Board’s proposals relating to the requisite quality of real-time video communications have received mixed reviews from commenters. In the 2010 ANPRM, the Board proposed specifications for the quality of real-time video communication that largely mirrored the Advisory Committee’s recommendation. Many commenters expressed support for the general concept of a video quality requirement as important for ensuring the accessibility of a means of communication, which, for persons who are deaf or hard of hearing, is the functional equivalent of voice communication. Some commenters, on the other hand, were critical of the Board’s proposed technical specifications as overly prescriptive or unsupported by research. In light of such concerns, in the 2011 ANPRM, the Board simply proposed—as here in this proposed rule—that the quality of video must be sufficient to support sign language communication. Commenters to the 2011 ANPRM, while again generally supportive of the effort to ensure real-time video communications were usable by persons with hearing impairments, largely took issue with the proposal’s lack of testable measures.

While the Board is mindful of commenters’ criticisms to the 2011 ANPRM’s performance-based standard for video quality of real-time video functionality, the Board has nonetheless retained this standard in this proposed rule. This provision would cover video communication via the web on dedicated videophones, as well as commonly used ICT such as smartphones. We are not aware of standards or specifications for video quality that would provide testable and achievable metrics to assess the quality and transmission of real-time video communications. However, technologies—as well as standards development—have progressed greatly in recent years. We welcome public comment on technological improvements or useful metrics relating to real-time video communication developed since the 2011 ANPRM.

Question 27. Does the performance-based standard in proposed 410.8 ensure that video quality would be sufficient to support a real-time video conversation in which one or more parties use sign language? If not, are there standards for video quality or transmission that would better implement the accessibility goal of this proposed requirement? Would it be readily achievable for manufacturers of telecommunications equipment to comply with section 410.8?

411 Closed Caption Processing Technologies (Section-by-Section Analysis)

This is an introductory section.

411.1 General (Section-by-Section Analysis)

This section addresses the accessibility of audio-visual technologies—including analog and digital televisions, tuners, personal video display devices, converter boxes, and computer equipment—by requiring such technologies to support closed and open captions. Captioning is critical for persons with hearing impairments to use and understand information presented in a video format. Specifically, proposed 411.1 provides that, where audio-visual players and displays process video with synchronized audio, they must either decode closed caption data and display open captions, or pass-through the closed captioning data stream in an accessible format. This proposal largely corresponds to existing 508 Standards §§ 1194.23(j) and 1194.24(a), and existing 255 Guidelines § 1193.37, though it differs in a few notable respects. Due to advances in technology, this proposed section neither distinguishes between analog and digital televisions, nor conditions the requirement for closed caption decoder circuitry on screen size. Additionally, the proposal substitutes the term “synchronized audio information” for “multimedia” because it is more precise and consistent with current terminology.

Question 28. Would compliance with section 411 be readily achievable for manufacturers of mobile telecommunications equipment?

411.1.1 Decoding of Closed Captions (Section-by-Section Analysis)

This section proposes that, where audio-visual players and displays process video with synchronized audio, they must decode closed caption data and support display of open captions.

411.1.2 Pass-Through of Closed Caption Data (Section-by-Section Analysis)

This section proposes that, where audio-visual players and displays process video with synchronized audio, cabling and ancillary equipment would be required to pass through caption data. High-definition multimedia cables (HDMI) carry audio and video signals, and are technically capable of passing through caption data; typically, however, caption data is not included with the audio-visual stream.

412 Audio Description Processing Technology (Section-by-Section Analysis)

This is an introductory section.

412.1 General (Section-by-Section Analysis)

This proposed section would require that, where ICT displays or processes video with synchronized audio, ICT must provide a mode of operation that plays associated audio description. This requirement draws from the audio description requirement in existing 508 Standards § 1194.24(b), but would include a specification for digital television tuners. This would be a new requirement to the 255 Guidelines.

Question 29. Would compliance with section 412 be readily achievable for manufacturers of mobile telecommunications equipment?

412.1.1 Digital Television Tuners (Section-by-Section Analysis)

This section proposes that, where audio description is played through a digital television tuner, that such tuner conform to Part 5 of the ATSC A/53 Digital Television Standard (incorporated by reference in 508 Chapter 1 and 255 Chapter 1). The provision then goes on to require that tuners provide processing for audio description when encoded as a Visually Impaired (VI) associated audio service. This is the industry-wide accepted method for delivery of audio description content and the means to identify audio as a VI associated audio service.

413 User Controls for Captions and Audio Description (Section-by-Section Analysis)

This is an introductory section.

413.1 General (Section-by-Section Analysis)

This proposed section addresses the accessibility of controls for captioning and audio description on devices used to watch video programming, including analog and digital televisions, tuners, personal video display devices, converter boxes, and computer equipment. Specifically, this provision would require hardware displaying video with synchronized audio to locate user controls for closed captions and audio description in specified locations of equal prominence to common user controls (i.e., volume and program selection), as set forth in two accompanying subsections (proposed 413.1.1 and 413.1.2). An exception would be provided for devices for personal use when closed captions and audio description can be enabled through system-wide platform settings. This exception is proposed in recognition of the fact that the small size of most mobile devices would make compliance particularly challenging.

The requirements in proposed 413.1 would be new to the 508 Standards and the 255 Guidelines. The Advisory Committee recommended inclusion of this provision to ensure that persons with hearing- and vision-related disabilities can find—and use—captioning and audio description controls. See TEITAC Report, Part 6, Subpt. C, Rec. 4-C. (Complimentary provisions governing software-based on-screen controls for captions and audio description are addressed in proposed 503.4.)

This proposed requirement, albeit with slightly different wording, was included in the 2010 and 2011 ANPRMs. Comments from organizations representing persons with disabilities lauded this proposed requirement as a significant step toward improving the accessibility of captioning and audio description controls. These organizations characterized consumers with disabilities as having long struggled with varying methods among manufacturers for accessing such controls, describing them as typically more complex and less “user friendly” compared to the control of other core functions. They also noted that difficulties locating and using caption and audio description controls is of particular concern for persons with disabilities when in unfamiliar locations (e.g., television in hotel room), or an emergency situation when accessing captioned or audio described information could be life-saving.

Commenters with connections to the ICT industry, on the other hand, expressed concern with the broad scope of the proposed provision. These commenters noted that the proposed requirement governing location of controls for captions and audio description would apply not only to televisions and remote controls, but also a wide range of “general purpose” devices—such as desktop computers, laptops, and other mobile devices—for which multimedia output is an incidental function. They suggested that either the scoping of the requirement be modified, or “general purpose” devices be exempted from providing physical buttons for closed captions and audio description. Others simply noted more generally that providing caption controls with equal prominence to volume controls could be problematic for some types of hardware-based ICT.

In late 2013, the FCC issued a final rule addressing, among other things, the accessibility of user interfaces on digital devices and software used to view video programming, including closed captioning and audio description (which, in the Commission’s rule, is referred to as “video description”).¹¹ To implement the Twenty-First Century Communications and Video Accessibility Act of 2010 (CVAA), Public Law No. 111-260 (2010) (codified in scattered sections of 47 U.S.C.), the FCC, in pertinent part, promulgated rules requiring “digital apparatus” designed to receive or play back video programming to provide access to closed captioning and video description through a mechanism that is reasonably comparable to a button, key or icon.¹² “Navigation devices”—which include digital cable ready televisions, set-top boxes, computers with CableCARD slots, and cable modems—are required to provide similar access to closed captioning (but not, at this juncture, video description) for on-screen menus and guides. The Commission declined, however, to adopt technical standards, performance objectives, or other specific metrics to evaluate accessibility. Establishment of such standards, the Commission determined, was beyond its statutory authority, and would, in any event, potentially stifle innovative approaches.

Proposed 413.1, in the Board’s view, complements the approach taken by the FCC in its final rule on accessibility of user interfaces. As with the FCC’s rule, the Board proposes to require that ICT with the capability of displaying video with synchronized audio ensure that controls for closed captions and audio description are accessible to persons with disabilities. Unlike the FCC, however, the Board does propose technical standards—namely, placement of caption and audio description controls—that govern how accessibility must be achieved. This is consistent with the Board’s statutory mandate under both the Rehabilitation Act and Communications Act. See 29 U.S.C. §§ 794d(2)(A)(ii), 794d(B); 47 U.S.C. 255(e). Thus, while the FCC may have been statutorily constrained by the CVAA with respect to technical standards for user interfaces, the Board is not. Indeed, one of Board’s core missions is the establishment of technical standards. In this way, proposed 413.1 may be seen as complimenting the FCC’s recent final rule. Both agencies establish an accessibility mandate for user interfaces on certain ICT that displays video with synchronized audio, but the Board, in this proposed rule, goes one step further by establishing a metric to assess accessibility—namely, placement of user controls for closed captions and audio description in locations of equal prominence to other core functions (i.e., volume control and program selection).

Question 30. Does proposed 413.1 strike an appropriate balance between ensuring users with hearing or vision impairments can readily find and use controls for closed captioning and audio description, while also affording device manufacturers sufficient design flexibility? Should the requirement for a captioning button be limited to devices that have both up/down volume controls and a mute button? Or, more generally, should the provision of caption controls be limited to certain types of hardware?

413.1.1 Caption Controls (Section-by-Section Analysis)

This proposed section would require that, where video-capable hardware provides physical volume adjustment controls, such ICT must also have a control for closed captioning in at least one location of comparable prominence to the volume adjustment controls. So, for example, if a television had physical volume controls on the display panel, as well as its accompanying remote control, this proposed requirement would be satisfied so long as a user control for captions was located either, at the manufacturer’s discretion, on the display or remote control in an equally prominent location to the volume control. (If this television also had a feature to adjust volume by way of an on-screen tool or menu, caption control requirements for this on-screen control would be governed by the software-based requirements in proposed 503.4.)

Question 31. While the Board believes that proposed 413.1.1 would greatly benefit persons who are deaf or hard of hearing, we did not monetize the benefits or costs of providing caption controls on covered hardware. The Board seeks data and other information from the public in order to estimate the monetized costs and benefits of this proposal. For commenters who do not view this proposed requirement as beneficial, how should the accessibility barriers faced by individuals with hearing impairments who seek to locate and operate closed caption features be addressed? Commenters should provide concrete suggestions for improving proposed 413.1.1.

413.1.2 Audio Description Controls (Section-by-Section Analysis)

This proposed section would require that, where video-capable hardware provides controls for program selection, such ICT must have user controls for audio description in at least one location of comparable prominence to the program selection controls. This requirement would be new to the 508 Standards. Locating audio description controls in a prominent location is not currently a common design practice, though the Board does not anticipate that it will add substantial cost. In practice, this would require one extra button on a remote control. While not as common as products featuring controls for captioning, there are already products commercially available that feature user controls for audio description.

Question 32. While the Board believes that proposed 413.1.2 would greatly benefit consumers who are blind or have low vision, we did not monetize the benefits or costs of providing audio description controls on covered hardware. The Board seeks data and other information in order to estimate the monetized costs and benefits of this proposal. For commenters who do not view this proposed requirement as beneficial, how should the accessibility barriers faced by individuals with vision impairments who seek to locate and operate audio description features be addressed? Commenters should provide concrete suggestions for improving proposed 413.1.2.

Chapter 5: Software (Section-by-Section Analysis)

Chapter 5 contains proposed technical requirements for software, applications, platforms, and software tools. The requirements in this chapter, along with the scoping provisions in proposed E207 and C205, collectively form the “suite” of accessibility requirements for these types of ICT. This chapter is largely drawn from existing 508 Standards § 1194.21, but with updating to harmonize with WCAG 2.0.

501 General (Section-by-Section Analysis)

This is an introductory section.

501.1 Scope (Section-by-Section Analysis)

This section proposes that the technical requirements for software in this chapter be applied where either (a) required by 508 Chapter 2 or 255 Chapter 2, or (b) where otherwise referenced in any other chapters. There are two exceptions. Exception 1, as proposed, provides that Web applications conforming to all Level A and AA Success Criteria and all Conformance Requirements in WCAG 2.0 need not conform to proposed 502 (Interoperability with Assistive Technology) or 503 (Applications). This exception is provided because software that conforms to WCAG 2.0 AA is already accessible. The value of promoting a single harmonized standard outweighs any small benefit that might be achieved by conforming to overlapping, but separate, standards.

Exception 2 proposes that software that (1) is assistive technology and (2) supports the accessibility services of the platform for which it is designed need not conform with the provisions of this chapter. This exception is included because assistive technology frequently needs flexibility in order to perform well for end-users with disabilities. For example, a switch-activated on-screen keyboard might not have a mode that makes it usable by someone who is blind. This exception is also deliberately limited to software that follows platform specifications because it is important that assistive technology be compatible with other assistive technology.

502 Interoperability with Assistive Technology (Section-by-Section Analysis)

This is an introductory section.

502.1 General (Section-by-Section Analysis)

This section proposes that platforms, software tools provided by platform developers, and applications must conform to the requirements in the accompanying subsections related to documented accessibility features (502.2), accessibility services (502.3), and platform accessibility services (502.4). An exception is provided for platforms and applications that have closed functionality.

This section has implications for both platform developers and federal procurement officials. Agencies would have to ensure that all operating systems they purchase have an associated set of documented accessibility services. Software developers would have to provide accessibility services when creating platforms and their software tools.

502.2 Documented Accessibility Features (Section-by-Section Analysis)

This section addresses the compatibility of software and assistive technology. Specifically, under proposed 502.2, platform features that are defined in the platform documentation as accessibility features would be required to conform to requirements in accompanying subsections related to user control (502.2.1) and non-disruption (502.2.2) of accessibility features.

502.2.1 User Control of Accessibility Features (Section-by-Section Analysis)

This section proposes that platforms must provide user control over platform features when such features are defined in platform documentation as serving an accessibility purpose. This provision would be new to the 508 Standards and 255 Guidelines, though it draws on the prohibition in § 1194.21(b) of the existing 508 Standards against disrupting or disabling accessibility features. The Advisory Committee recommended that the Board include an express provision ensuring that persons with disabilities are able to activate and use features or settings—such as font size, or color—that preclude network or system-wide configurations from “locking down” needed accessibility features. See TEITAC Report, Part 6, Subpt. C, Rec. 2-C. This proposal was included in the 2010 and 2011 ANPRMs, and the only comments received related to minor editorial changes.

502.2.2 No Disruption of Accessibility Features (Section-by-Section Analysis)

This section proposes that, where accessibility features are defined in platform documentation, applications must not disrupt them. This provision mirrors existing 508 Standards § 1194.21(b). The Advisory Committee strongly recommended that the Board include this requirement in the proposed rule not only to ensure accessibility, but also to avoid platform developers from being responsible for incompatibilities that derived from undocumented platform services or hidden requirements of assistive technology. See TEITAC Report, Part 6, Subpt. C, Rec. 3-Q. This proposal was included in the 2010 and 2011 ANPRMs and received no adverse comments.

502.3 Accessibility Services (Section-by-Section Analysis)

This section proposes that platforms (such as operating systems) and software tools provided by the platform developer furnish a documented set of accessibility services—usually referred to as Application Programming Interfaces (APIs)—in order to enable applications running on the platform to interoperate with assistive technology. Additionally, applications that are themselves platforms would be required to expose underlying platform accessibility services or implement other document accessibility services.

This proposal does not have an analog in the existing 508 Standards because, at the time the standards were issued in 2000, mainstream operating systems had a well-established track record of providing APIs. Since then, some platforms, particularly those used by first generation mobile devices, stopped providing these requisite components of baseline accessibility. This proposed provision would not represent a significant change from widespread industry practice, since all major platforms have well-developed APIs that incorporate accessibility. Consequently, it is important to expressly require APIs. A documented set of accessibility services is important to end-users because, without them, developers are likely to provide inconsistent access to assistive technology, thereby leaving end-users with disabilities without access to needed features. Well-documented accessibility services are especially important for developers new to accessibility, and can serve to alert all developers to the importance of the accessibility features of platforms.

502.3.1 Object Information (Section-by-Section Analysis)

This section proposes that particular programming elements—namely object role, state, boundary, name, and description—must be programmatically determinable. Moreover, user-adjustable states would be required to be set programmatically, including through assistive technology. This proposal, along with proposed 502.3.3, corresponds to WCAG 2.0 Success Criteria 4.1.2 Name, Role, and Value. It is also consistent with existing 508 Standards § 1194.21(d), but more explicitly provides for the user to be able to change data values, not just read them. Making the specified states programmatically determinable is already a widespread industry practice and is a standard feature provided in software designed to be accessible. Nonetheless, it is important to address this issue in the proposed rule because, on occasion, users of assistive technology find that they can read data in fields, but cannot make changes.

502.3.2 Row, Column, and Headers (Section-by-Section Analysis)

This section proposes that, where a programming object is in a table, occupied rows and columns (i.e., those populated with data), as well as any headers associated with such rows or columns, must be programmatically determinable. This provision corresponds to §§ 1194.22(g) and 1194.22(h) of the existing 508 Standards. A similar requirement is set forth in WCAG 2.0 Success Criteria 1.3.1 Info and Relationships. See W3C, Understanding SC 1.3.1, Understanding WCAG 2.0 (Sept. 16, 2014), http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html.

502.3.3 Values (Section-by-Section Analysis)

This section proposes that current values, as well as any set or range of allowable values associated with a programming object, must be programmatically determinable. This proposal would also require values that can be set by the user to be capable of being set programmatically, including through assistive technology. This proposal, along with proposed 502.3.1, corresponds to WCAG 2.0 Success Criteria 4.1.2 Name, Role, and Value. An express requirement for values to be set programmatically would be new to the 508 Standards. However, existing industry practice in response to existing standards (i.e., 508 Standards § 1194.21(d)) is to permit values to be set programmatically.

502.3.4 Label Relationships (Section-by-Section Analysis)

This section proposes that relationships between components must be programmatically exposed to assistive technology where a component labels, or is labeled by, another component. This provision corresponds to §§ 1194.21(l) and 1194.22(n) in the existing 508 Standards, though it is broader in scope since, unlike these current requirements, its coverage extends beyond forms. A similar requirement is set forth in WCAG 2.0 Success Criteria 1.3.1 Info and Relationships. See W3C, Understanding SC 1.3.1, Understanding WCAG 2.0 (Sept. 16, 2014), http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html.

502.3.5 Hierarchical Relationships (Section-by-Section Analysis)

This section proposes that any hierarchical (parent-child) relationship between components be programmatically exposed to assistive technology. This is important for individuals who use assistive technology so they can understand the relationships or interdependencies between menu options, database entries, or other software elements that have parent-child relationships. For example, word processing and email software commonly use one or more sub-menus that cascade from a “main” menu item, which permit the user to perform desired actions such as saving a file in a specific format or altering font styles. Requiring components to expose (i.e., provide) hierarchical relationships to assistive technology ensures that an individual using a screen reader, for example, could understand these relationships and, thereby, perform the desired function or action. This provision corresponds to existing 508 Standards §§ 1194.21(l) and 1194.22(n). In addition, in response to existing 508 Standards § 1194.21(d), current industry practice is to ensure that any parent-child relationship that components have to other components is programmatically exposed to assistive technology. This requirement closely parallels Success Criterion 1.3.1 in WCAG 2.0, but has greater specificity because software is more structured than Web content.

502.3.6 Text (Section-by-Section Analysis)

This section proposes that the content of text objects, text attributes, and on-screen text boundaries be programmatically determinable. Additionally, text that can be set by the user would have to be capable of being set programmatically, including through assistive technology. This provision would be useful for a screen-reader user, for example, when filling in a field on a form. It would be quite frustrating to be able to navigate to a form field, and perhaps even read placeholder text in that field, but then not be able to enter text as needed. This provision corresponds to § 1194.21(f) in the existing 508 Standards.

502.3.7 Actions (Section-by-Section Analysis)

This section proposes that a list of all actions that can be executed on an object must be programmatically determinable. An example of an “object” is a drop-down menu of states and U.S. territories in an online form. Applications would also be required to allow assistive technology to programmatically execute available actions on objects. While this requirement is new to the 508 Standards, it represents widespread industry practice. It is also already a feature provided by software designed to be accessible. This proposed requirement is important because, on occasion, developers new to accessibility overlook this need.

502.3.8 Focus Cursor (Section-by-Section Analysis)

This section proposes that software be required to expose information and mechanisms necessary to programmatically track and modify keyboard focus, text insertion point, and selection attributes of user interface components. An example of “focus cursor” is a database, which, as the user hits the tab key, displays a visible box outlining the various fields. This provision corresponds to § 1194.21(c) in the existing 508 Standards.

502.3.9 Event Notification (Section-by-Section Analysis)

This section proposes that programmatic notification of events relevant to user interactions— including changes in a component’s state, value, name, description, or boundary—must be available to assistive technologies. This proposal complements existing 508 Standards § 1194.21(d), but more explicitly requires that changes to on-screen user interfaces be done in a way that such changes, otherwise known as events, are exposed to assistive technology. Such event notification is already a widespread industry practice, and, moreover, a feature provided by software designed to be accessible. This proposed requirement is important to address this issue in these proposed requirements because, on occasion, developers new to accessibility overlook this need.

502.4 Platform Accessibility Features (Section-by-Section Analysis)

This section addresses specifications for capabilities that users with disabilities have come to expect as core accessibility features when using today’s platforms and operating systems, such as allowing adjustment of delay before key acceptance and displaying provided captions. These features include: sticky keys; bounce keys; delay keys; show sounds; the ability to produce synthesized speech; and, the capability to display captions included in content. Specifically, this proposal would require platforms and platform software to conform to seven specific sections in ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces (incorporated by reference in 508 Chapter 1 and 255 Chapter 1). While this proposed requirement (and accompanying incorporation by reference of ANSI/HFES 200.2) is new to the 508 Standards and 255 Guidelines, it does not represent a material change from current industry practice. The seven enumerated features were first available as an add-on for the IBM DOS 3.3 operating system (which was publicly released in the mid-1980s), and have been incorporated into every release of the Microsoft Windows® operating system since then.

Question 33. The Board is requesting information from covered entities and other stakeholders on the potential costs or benefits from incorporation of ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces —Part 2: Accessibility (2008). Are there suggestions for other standards that would result in the same level of accessibility?

503 Applications (Section-by-Section Analysis)

This is an introductory section.

503.1 General (Section-by-Section Analysis)

This section addresses specifications for non-Web software—that is, programs with a user interface that are executed on a computing platform—related to certain user preferences, interfaces, and controls. The proposed requirements in this section are separate from, and in addition to, any required conformance to WCAG 2.0 success criteria that may be otherwise required under the proposed 508 Standards (under E207) or the 255 Guidelines (under C205).

503.2 User Preferences (Section-by-Section Analysis)

This section proposes that applications must permit user preferences to carry over from platform settings for text color, contrast, font type, font size, and focus cursor. This closely corresponds to § 1194.21(g) in the existing 508 Standards.

503.3 Alternative User Interfaces (Section-by-Section Analysis)

This section proposes to require that, when applications provide alternative user interfaces that function as assistive technology, such applications must use platform accessibility services (i.e., APIs). Examples of alternative user interfaces include on-screen keyboards for a single switch user, and screen reading software for a person who is blind. This proposed requirement would be new to the 508 Standards and 255 Guidelines. It is included in this proposed rule to address the accessibility gap that would occur should developers of novel interfaces not consider their products to be assistive technology and, consequently, conclude they may ignore the requirements for interoperability with assistive technology (proposed 502). By clarifying that alternative user interfaces functioning as assistive technology need to satisfy interoperability requirements, the section aims to forestall the rare, but problematic, situation where there is a question about whether a product should be treated as assistive technology or another type of software.

503.4 User Controls for Captions and Audio Description (Section-by-Section Analysis)

This proposed section addresses the accessibility of on-screen controls for captioning and audio description. Specifically, this provision would require software displaying video with synchronized audio to locate user controls for closed captions and audio description at the same menu level as common user controls (i.e., volume, program selection), as set forth in two accompanying subsections (proposed 503.4.1 and 503.4.2).

These proposed requirements for accessibility of software-based on-screen controls for captions and audio description serve as a complement to the near-identical requirements for hardware-related controls in Chapter 4. See discussion above in Section VI.C (Section-by-Section Analysis – section 413 User Controls for Captions and Audio Description). These proposed requirements would be new to the 508 Standards and 255 Guidelines. The Advisory Committee recommended inclusion of these provisions to ensure that persons with hearing- and vision-related disabilities can find—and use—captioning and audio description controls. See TEITAC Report, Rec. 4-C.

503.4.1 Caption Controls (Section-by-Section Analysis)

This proposed section would require that, where video-capable software provides on-screen volume adjustment controls, such ICT must also have a control for closed captioning at the same menu level as the volume adjustment controls.

503.4.2 Audio Description Controls (Section-by-Section Analysis)

This proposed section would require that, where video-capable software provides on-screen controls for program selection, such software must have user controls for audio description at the same menu level as the volume or program selection controls.

504 Authoring Tools (Section-by-Section Analysis)

This is an introductory section.

504.1 General (Section-by-Section Analysis)

This section proposes requirements for software used to create or edit electronic content— which is generally referred to as authoring tools—to ensure the accessibility of this content. Specifically, authoring tools would be required to conform to accessibility requirements related to content creation and editing (504.2), prompts (504.3), and templates (504.4) to the extent supported by the destination format. Authoring tools include applications that allow users to develop new Web pages, edit video, or create electronic documents. Authoring tools can also be used to create and publish content for use with telecommunications products or services. One example of a telecommunications equipment-based authoring tool is an interactive voice response system (IVR) that uses software capable of creating content used to populate menu choices.

These proposed requirements for authoring tools are new to the 508 Standards and 255 Guidelines. The Advisory Committee discussed authoring tools and offered recommendations on certain provisions, but did not achieve consensus on others. See TEITAC Report, Part 7, Subpt. C, Rec. 7. Industry is already trending toward providing mainstream document creation tools that facilitate accessible output. For example, two mainstream authoring tools that support accessible document creation and accessibility checking tools are Adobe Acrobat® XI Pro and Microsoft® Office software products. Any cost increases for this requirement should be quite modest for products that already support accessibility. It is not uncommon for developers of niche products to first learn about Section 508 because their product exports reports to PDF, and government customers are likely to encounter end-user complaints when such reports are inaccessible. In this way, while a particular authoring tool may be used only by a small number of people, its outputs—such as government reports—may be widely distributed to the public.

Benefits of accessible content created or edited with authoring tools conforming to proposed 504.1 would accrue to a wide range of disabilities, and the costs associated with making such tools capable of producing accessible output are likely to be minimal. Developers already understand how to make electronic documents accessible in commonly used formats (i.e., HTML, PDF, MS-Word), and it is typically much less expensive to “build in” accessibility when an authoring tool is first developed as opposed to remediating after a product has been developed.

504.2 Content Creation or Editing (Section-by-Section Analysis)

This section proposes to require authoring tools to include at least one mode of operation for creating or editing content that conforms to WCAG 2.0 Success Criteria for all features and formats supported by the authoring tool. Additionally, authoring tools must provide users with the option of overriding information required for accessibility to provide flexibility during the authoring process. A proposed exception would exempt authoring tools from compliance when authoring tools are used to directly edit plain text source code (e.g., Emacs and Windows Notepad). This exception is needed because plain text is fundamentally limited in its ability to encode accessibility features.

504.2.1 Preservation of Accessibility Information in Format Conversion (Section-by-Section Analysis)

This section proposes that authoring tools, when converting content or saving content in multiple formats, must preserve information required for accessibility to the extent supported by the destination format. This proposed requirement is similar to § 1194.23(j) in the existing 508 Standards. Because not all authoring tools support different file formats, this provision would only apply when such a tool provides a file conversion feature.

504.3 Prompts (Section-by-Section Analysis)

This proposed section would require authoring tools to proactively support the creation of accessible content by providing a mode of operation that prompts users—either during initial content creation or when content is saved—to create accessible content that conforms to all applicable Level A and AA Success Criteria in WCAG 2.0. This requirement is intended to ensure that users have access to accessibility features supported by their authoring tools.

504.4 Templates (Section-by-Section Analysis)

This proposed section would require that, where authoring tools provide templates, templates that facilitate the creation of accessible content conforming to all applicable WCAG 2.0 Level A and Level AA Success Criteria must be provided for a range of template uses. It is much easier to start with an accessible template as compared to adding accessibility features to otherwise finished content. Remediating accessibility problems after content development increases the cost and time necessary to produce accessible content.

Chapter 6: Support Documentation and Services (Section-by-Section Analysis)

Chapter 6 covers accessibility requirements for ICT support documentation and services. This section also would require support services such as help desks, call centers, training services, and automated self-service technical support systems that provide documentation to make available (in accessible formats) the documentation regarding accessibility and compatibility features. Support services would also be required to accommodate the communication needs of individuals with disabilities.

The proposed requirements in this chapter are largely consistent with existing 508 Standards § 1194.41 and existing 255 Guidelines § 1193.33, but would enhance specifications, as discussed below, for certain types of support documentation and services. The Advisory Committee recommended inclusion of provisions on support documentation and services in the proposed rule. See TEITAC Report, Part 6, Subpt. D, Rec. 1.

601 General (Section-by-Section Analysis)

This is an introductory section.

601.1 Scope (Section-by-Section Analysis)

This section proposes that the technical requirements for support documentation and services in this chapter be applied where either (a) required by 508 Chapter 2 or 255 Chapter 2, or (b) where otherwise referenced in any other chapters.

602 Support Documentation (Section-by-Section Analysis)

This is an introductory section.

602.1 General (Section-by-Section Analysis)

This section proposes to require documentation supporting the use of ICT to conform to the requirements in the accompanying subsections concerning identification of accessibility and compatibility features (602.2), electronic support documentation (602.3), and alternate formats for non-electronic support documentation (602.4). These proposals for accessible support documentation are derived from §§ 1194.41 and 1193.33 of the existing 508 Standards and 255 Guidelines respectively, but the requirement that electronic documentation comply with WCAG 2.0 or PDF/UA-1 would be new to both the standards and the guidelines. Requiring that comprehensive product information be available to users with disabilities is important because product installation and configuration can often impact its accessibility.

602.2 Accessibility and Compatibility Features (Section-by-Section Analysis)

This section provides specifications for ICT documentation in terms of accessibility and compatibility features that assist users with disabilities. Such documentation includes installation guides, user guides, online support, and manuals that describe features of a product and how it is used. All formats of documentation are covered, including printed and electronic documents, and Web-based product support pages.

Proposed 602.2 would require documentation to identify, as well as explain how to use, accessibility features that are required by the 508 Standards or 255 Guidelines. The requirements of this section derive from §§ 1194.41(b) and 1193.33 of the existing 508 Standards and 255 Guidelines, respectively, and are essentially unchanged.

This provision is proposed because some users with disabilities have complained about a lack of information available to help them understand the accessibility and compatibility features of some ICT. Documentation of accessibility features may include, for example, instructions on use of the voice guidance system of a multifunction office machine, or guidance on using software designed for compatibility with commonly used assistive technologies (such as screen readers, refreshable braille displays, and voice recognition software).

602.3 Electronic Support Documentation (Section-by-Section Analysis)

This section proposes to require documentation in electronic formats—including Web-based self-service support and electronic documents—to conform to all Level A and AA Success Criteria and Conformance Requirements in WCAG 2.0 or ISO 14289-1 (PDF/UA-1), which are each incorporated by reference in 508 Chapter 1 and 255 Chapter 1. This proposal for accessible electronic support documentation is derived from §§ 1194.41 and 1193.33 of the existing 508 Standards and 255 Guidelines respectively, but the requirement that electronic documentation comply with WCAG 2.0 or PDF/UA-1 would be new to both the standards and the guidelines. The purpose of this requirement is to ensure that support documentation is held to the same accessibility requirements as other types of covered content. The Board included similar provisions in the 2010 and 2011 ANPRMs, and received no adverse comments objecting to this approach.

Question 34. The Board requests that telecommunications equipment manufacturers provide information on the costs associated with producing documentation on the accessible features of products in a format consistent with the WCAG 2.0 Success Criteria. Is it readily achievable to provide this information in an accessible format? If not, how would it be provided?

602.4 Alternate Formats for Non-Electronic Support Documentation (Section-by-Section Analysis)

This section proposes that, where documentation is provided in written (i.e., hard copy) format, such documentation must also be made available, upon request, in alternate formats usable by individuals who are blind or have low vision. This proposed requirement is taken from §§ 1194.41(a) and 1193.33(a)(2) of the existing 508 Standards and 255 Guidelines, respectively, with minor editorial changes.

603 Support Services (Section-by-Section Analysis)

This is an introductory section.

603.1 General (Section-by-Section Analysis)

This section addresses the accessibility of ICT support services, such as help desks, call centers, training centers, and automated self-service technical support. Such support services would be required to conform to the requirements concerning information on accessibility and compatibility features (603.2), as well as accommodation for the communication needs of persons with disabilities (603.3). These proposed requirements for accessible support services are drawn from §§ 1194.41 and 1193.93 of the existing 508 Standards and 255 Guidelines respectively, but have been revised—as supported by the Advisory Committee—to specify methods of delivery for support services. See TEITAC Report, Pt. 6, Subpt. D, Recs. 1.1-A & 1.2-A.

603.2 Information on Accessibility and Compatibility Features (Section-by-Section Analysis)

This proposed section complements the product documentation requirements in section 602 by proposing that ICT support services include information on the accessibility and compatibility features for which documentation is required under proposed 602.2.

603.3 Accommodation of Communication Needs (Section-by-Section Analysis)

This proposed section would permit compliant support services to be delivered through either of two methods: directly to the user or through referral to a point of contact. This section also would require ICT support services to accommodate the communication needs of individuals with disabilities. The portion of this proposal relating to two specific methods for delivery of support services is based on existing 255 Guidelines §§ 1193.33(a)(3) and 1193.33(b), and would be new to the 508 Standards. The portion of the proposal relating to accommodation of communication needs derives from §§ 1194.41(c) and 1193.33 of the 508 Standards and 255 Guidelines, respectively.