36 CFR Part 1194 Electronic and Information Technology Accessibility Standards (Section 508 Standards) - Preamble

Subpart B -- Technical Standards (Formerly Subpart B -- Accessibility Standards in the NPRM) (Preamble, Section-by-Section Analysis)

Comment. Subpart B of the proposed rule contained four sections: §1194.21 (General Requirements); §1194.23 (Component Specific Standards); §1194.25 Standards for Compatibility; and §1194.27 (Functional Performance Criteria). The Board sought comment in the proposed rule on the organization of Subpart B in general and §1194.21 (General Requirements), §1194.23 (Component Specific Requirements) and §1194.25 (Requirements for Compatibility) in particular. A number of commenters found the application of the proposed rule to be confusing due to the manner in which the rule was organized. Commenters questioned whether a specific product need only comply with the provisions under a specific heading in §1194.23 (Component Specific Requirements) or whether they must also look to the provisions in §1194.21 (General Requirements), as well as §1194.25 (Compatibility). Commenters further questioned whether multiple provisions within a specific section would apply. For example, making electronic forms accessible was addressed under §1194.23(b) (Non-embedded software applications and operating systems). Provisions for web sites were addressed separately in §1194.23(c) (Web-based information or applications). Since electronic forms are becoming very popular on web sites, the commenters questioned whether the provisions for electronic forms under the software section should also be applied to web sites even though the section on web sites did not specifically address electronic forms. Another commenter pointed out that some provisions under §1194.21 (General Requirements) actually addressed specific components such as touch screens, which were addressed under General Requirements in the proposed rule. Finally, other commenters noted that several provisions under §1194.23 (Component Specific Requirements) were really compatibility concerns, such as §1194.23(b) (Non-embedded software).

Response. A product must comply with the provisions under each applicable section in Subpart B. For example, a telecommunications product that has computer, software and operating systems, a keyboard, and web browser will have to comply with each of the relevant sections in Subpart B. The Board has reorganized Subpart B in the final rule as follows:

The title of Subpart B has been changed from "Accessibility Standards" to "Technical Standards".

Subpart B has been reorganized so that each section addresses specific products. For example, §1194.21 addresses software applications, §1194.22 addresses web-based intranet and internet information and applications, and so on. Each technical provision that applies to a product is located under that product heading. As a result, there is some redundancy in this section. However, the Board believes that this format will help clarify the application of the standards for each type of product. For example, the provision prohibiting the use of color alone to indicate an action applies not only to web page design, but also to software design and certain operating systems. In the final rule, it is addressed in §1194.21(i) (Software applications and operating systems), §1194.22(c) (Web-based intranet and internet information and applications), as well as §1194.25(g) (Self contained, closed products).

The provisions contained in §1194.21 (General Requirements), §1194.23 (Component Specific Requirements) and §1194.25 (Requirements for Compatibility with Assistive Technology) of the proposed rule have been moved to the new subpart B (Technical Standards) in the final rule.

Also, the provisions in the proposed rule under §1194.27 (Functional Performance Criteria) have been redesignated as Subpart C (Functional Performance Criteria) in the final rule. Subpart C provides functional performance criteria for overall product evaluation and for technologies or components for which there is no specific provision in subpart B. The substance of each of the provisions in the final rule are discussed below.

Section 1194.21 Software Applications and Operating Systems (Preamble, Section-by-Section Analysis)

Paragraphs (a) through (l) address provisions for software applications and operating systems. Electronic and information technology products operate by following programming instructions referred to as software. Software refers to a set of logical steps (or programming instructions) that control the actions or operations of most forms of electronic and information technology products. For instance, when a pager receives a radio signal, the software embedded inside the pager determines whether the signal is a "page" and how it should display the information it receives. The circuitry inside the pager, including the display unit, merely follows the instructions encoded in the software. Software can be divided into two broad categories: software that is embedded in a chip mounted in a product and non-embedded software that is loaded onto a storage device such as a hard disk and can be erased, replaced, or updated. For instance, a word processing program that is installed onto a computer's hard drive and which may be easily erased, replaced, or updated is typically "non-embedded" software. By contrast, the set of instructions installed on a chip inside a pager and which cannot be erased, replaced, or updated is typically embedded software. The proposed rule included provisions for non-embedded software. However, as pointed out by commenters, as technology changes, the distinction between embedded software and non-embedded software is increasingly becoming less clear. These provisions apply to all software products.

Paragraph (a) requires that when software is designed to run on a system that has a keyboard, the software shall provide a way to control features which are identifiable by text, from the keyboard. For example, if a computer program included a "print" command or a "save" command (both can be readily discerned textually), the program must provide a means of invoking these commands from the keyboard. For people who cannot accurately control a mouse, having access to the software's controls through keyboard alternatives is essential. For example, rather than pointing to a particular selection on the screen, a user may move through the choices in a dialogue box by pressing the tab key. (See §1194.23(a)(4) and §1194.23(b)(1) in the NPRM.)

Comment. The NPRM required that products must provide logical navigation among interface elements through the use of keystrokes. Commenters questioned the meaning of "logical" and whether the provisions, as proposed, were requiring that each system have a keyboard. Commenters were concerned that requiring that all features of every software program be accessible from a keyboard was not feasible because some programs that allow an individual to draw lines and create designs using a mouse could not be replicated with keystrokes.

Response. This provision applies to products which are intended to be run on a system with a keyboard. It does not require that a keyboard be added. The term "logical navigation" has been deleted. Only those actions which can be discerned textually are required to be executable from a keyboard. For example, most of the menu functions in common drawing programs that allow a user to open, save, size, rotate, and perform other actions on a graphic image can all be performed from the keyboard. However, providing keyboard alternatives for creating an image by selecting a paintbrush, picking a color, and actually drawing a design would be extremely difficult. Such detailed procedures require the fine level of control afforded by a pointing device (e.g., a mouse) and thus cannot be discerned textually without a lengthy description. Accordingly, in the final rule, keyboard alternatives are required when the function (e.g., rotate figure) or the result of performing a function (e.g., save file confirmation) can be represented with words.

Paragraph (b) prohibits applications from disrupting or disabling activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer. The application programming interface refers to a standard way for programs to communicate with each other, including the operating system, and with input and output devices. For instance, the application programming interface affects how programs have to display information on a monitor or receive keyboard input via the operating system.

Many commercially available software applications and operating systems have features built-into the program that are labeled as access features. These features can typically be turned on or off by a user. Examples of these features may include, reversing the color scheme (to assist people with low vision), showing a visual prompt when an error tone is sounded (to assist persons who are deaf or hard of hearing), or providing "sticky keys" that allow a user to press key combinations (such as control-C) sequentially rather than simultaneously (to assist persons with dexterity disabilities). This provision prohibits software programs from disabling these features when selected. (See §1194.23(b)(2) in the NPRM.)

Comment. The proposed rule only specified that software not interfere with features that affect the usability for persons with disabilities. Commenters from industry noted that the provision in the NPRM did not provide any method of identifying what features are considered access features and further stated that this provision was not achievable. These commenters pointed out that it was impossible for a software producer to be aware of all of the features in all software packages that could be considered an access feature by persons with disabilities. Sun Microsystems recommended that this provision address access features that have been developed using standard programming techniques and that have been documented by the manufacturer.

Response. This provision has been modified in the final rule to reference access features which have been developed and documented according to industry standards. No other changes have been made in the final rule.

Paragraph (c) requires that software applications place on the screen a visual indication of where some action may occur if a mouse click or keystroke takes place. This point on a screen indicating where an action will take place is commonly referred to as the "focus". This provision also requires that the focus be readable by other software programs such as screen readers used by computer users who are blind. (See §1194.23(b)(3) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Paragraph (d) requires that software programs, through the use of program code, make information about the program's controls readable by assistive technology. Simply stated, this paragraph requires that information that can be delivered to or received from the user must be made available to assistive technology, such as screen reading software. Examples of controls would include button checkboxes, menus, and toolbars. For assistive technology to operate efficiently, it must have access to the information about a program's controls to be able to inform the user of the existence, location, and status of all controls. If an image is used to represent a program function, the information conveyed by the image must also be available in text. (See §1194.23(b)(4) and §1194.23(b)(5) in the NPRM.) No substantive comments were received and no changes have been made to this section, other than editorial changes.

Paragraph (e) requires that when bitmap images are used by a program to identify programmatic features, such as controls, the meaning of that image shall not change during the operation of a program. "Bitmap images" refer to a type of computer image commonly used in "icons" (e.g., a small picture of a printer to activate the print command). Most screen reading programs allow users to assign text names to bitmap images. If the bitmap image changes meaning during a program's execution, the assigned identifier is no longer valid and is confusing to the user. (See §1194.23(b)(6) in the NPRM.)

Comment. As proposed, this provision did not identify which images had to remain consistent during the application. The AFB commented that the provision should be modified to indicate the type of image that needs to hold a consistent meaning during the running of an application. AFB noted that this provision should apply only to those bitmaps that represent a program function, and not to all images.

Response. The final rule applies the provision to those images which are used to identify controls, status indicators, or other programmatic elements. No other changes have been made to this section in the final rule.

Paragraph (f) provides that software programs use the functions provided by an operating system when displaying text. The operating system is the "core" computer software that controls basic functions, such as receiving information from the keyboard, displaying information on the computer screen, and storing data on the hard disk. Other software programs use the standard protocols dictated by the operating system for displaying their own information or processing the output of other computer programs. When programs are written using unique schemes for writing text on the screen or use graphics, other programs such as software for assistive technology may not be able to interpret the information. This provision does not prohibit or limit an application programmer from developing unique display techniques. It requires that when a unique method is used, the text be consistently written throughout the operating system. (See §1194.23(b)(7) in the NPRM.)

Comment. The proposed rule did not specify that software programs must use the functions provided by an operating system when displaying text. The NPRM required that the text would be provided through an application programming interface that supported interaction with assistive technology or that it would use system text writing tools. Commenters raised several concerns regarding this provision. Some commenters were concerned that without a recognized interface standard, there was no assurance that assistive technology would be able to access the text provided by an application. Software producers felt that the provision should not unduly restrict how programs create or display text. Baum Electronics and GW Micro pointed out that the only way to ensure that both assistive technology and applications are using a common interface, was to use the text displaying functions of the operating system.

Response. The Board agrees that using operating system functions is one approach that would be available to all programmers. The final rule has been modified to require that textual information be provided through the operating system functions so that it will be compatible with assistive technology. This provision does not restrict programmers from developing unique methods of displaying text on a screen. It requires that when those methods are used, the software also sends the information through the operating systems functions for displaying text.

Paragraph (g) prohibits applications from overriding user selected contrast and color selections and other individual display attributes. As described above, the operating system provides the basic functions for receiving, displaying, transmitting, or receiving information in a computer or similar product. Thus, the operating system would appear the logical choice for "system-wide" settings that would be respected by all computer programs on a computer. Many modern operating systems incorporate the ability to make settings system-wide as an accessibility feature. This permits, for instance, users to display all text in very large characters. Often, persons with disabilities prefer to select color, contrast, keyboard repeat rate, and keyboard sensitivity settings provided by an operating system. When an application disables these system-wide settings, accessibility is reduced. This provision allows the user to select personalized settings which cannot be disabled by software programs. (See §1194.23(b)(9) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Paragraph (h) addresses animated text or objects. The use of animation on a screen can pose serious access problems for users of screen readers or other assistive technology applications. When important elements such as push-buttons or relevant text are animated, the user of assistive technology cannot access the application. This provision requires that in addition to the animation, an application provide the elements in a non-animated form. (See §1194.23(b)(11)in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Paragraph (i) prohibits the use of color as the single method for indicating important information. For instance, a computer program that requires a user to distinguish between otherwise identical red and blue squares for different functions (e.g., printing a document versus saving a file) would not comply with this provision. Relying on color as the only method for identifying screen elements or controls poses problems, not only for people with limited or no vision, but also for those people who are color blind. This provision does not prohibit the use of color to enhance identification of important features. It does, however, require that some other method of identification, such as text labels, be combined with the use of color. (See §1194.21(a) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Paragraph (j) requires software applications to provide users with a variety of color settings that can be used to set a range of contrast levels. (See §1194.23(b)(8) in the NPRM.)

Comment. The NPRM specified a minimum number of color settings. Some commenters were concerned that the proposed provision was too specific, while others felt it was too general because it failed to measure how different levels of contrast would be produced. Several commenters suggested requiring "a wide variety" of color settings as recommended by the EITAAC. One commenter noted that, as proposed, the provision forbids a monochrome display. Commenters also stated that some systems do not provide users with color selection capabilities.

Response. The provision in the final rule is limited to those circumstances where the system allows a user to select colors. This provision requires more than just providing color choices. The available choices must also allow for different levels of contrast. Many people experience a high degree of sensitivity to bright displays. People with this condition cannot focus on a bright screen for long because they will soon be unable to distinguish individual letters. An overly bright background causes a visual "white-out". To alleviate this problem, the user must be able to select a softer background and appropriate foreground colors. The provision has been revised as a performance standard rather than a specific design standard by removing the requirement for 8 foreground and 8 background color selections.

Paragraph (k) limits the flashing or blinking rate of screen items. (See §1194.21(c) in the NPRM.)

Comment. The Trace Center expressed concern that research supported a limit of 3 Hz, not 2 Hz as described in the NPRM. Trace suggested that the flash or blink rate avoid any flickering between (but not including) 3 Hz and 55 Hz, which is the power frequency for Europe.

Response. This provision is necessary because some individuals with photosensitive epilepsy can have a seizure triggered by displays which flicker or flash, particularly if the flash has a high intensity and is within certain frequency ranges. The 2 Hz limit was chosen to be consistent with proposed revisions to the ADA Accessibility Guidelines which, in turn, are being harmonized with the International Code Council (ICC)/ANSI A117 standard, "Accessible and Usable Buildings and Facilities", ICC/ANSI A117.1-1998 which references a 2 Hz limit. The Board agrees that an upper limit is needed, since all electrically powered equipment, even an incandescent light bulb, has a "flicker" due to the alternating current line voltage frequency (60 Hz in the U.S., 55 Hz in Europe). There does not appear to be any significant incidence of photosensitive seizures being induced by the line voltage frequency of ordinary lights. Therefore, the provision has been changed to prohibit flash or blink frequencies between 2 Hz and 55 Hz.

Paragraph (l) requires that people with disabilities have access to electronic forms. This section is a result of the reorganization of the final rule and is identical to section 1194.22(n) discussed below. (See §1194.23(b)(10) in the NPRM.)

Section 1194.22 Web-based Intranet and Internet Information and Applications (Preamble, Section-by-Section Analysis)

In the proposed rule, the Board indicated that the EITAAC had recommended that the Board's rule directly reference priority one and two checkpoints of the World Wide Web Consortiums' (W3C) Web Accessibility Initiative's (WAI) Web Content Accessibility Guidelines 1.0 (WCAG 1.0). Rather than reference the WCAG 1.0, the proposed rule and this final rule include provisions which are based generally on priority one checkpoints of the WCAG 1.0, as well as other agency documents on web accessibility and additional recommendations of the EITAAC.

Comment. A number of comments were received from the WAI and others expressing concern that the Board was creating an alternative set of standards that would confuse developers as to which standards should be followed. WAI was further concerned that some of the provisions and preamble language in the NPRM were inaccurate. On the other hand, a number of commenters, including the ACB and several members of the EITAAC, supported the manner in which web access issues were addressed in the proposed rule.

Response. The final rule does not reference the WCAG 1.0. However, the first nine provisions in §1194.22, paragraphs (a) through (i), incorporate the exact language recommended by the WAI in its comments to the proposed rule or contain language that is not substantively different than the WCAG 1.0 and was supported in its comments.

Paragraphs (j) and (k) are meant to be consistent with similar provisions in the WCAG 1.0, however, the final rule uses language which is more consistent with enforceable regulatory language. Paragraphs (l), (m), (n), (o), and (p) are different than any comparable provision in the WCAG 1.0 and generally require a higher level of access or prescribe a more specific requirement.

The Board did not adopt or modify four of the WCAG 1.0 priority one checkpoints. These include WCAG 1.0 Checkpoint 4.1 which provides that web pages shall "[c]learly identify changes in the natural language of a document's text and any text equivalents (e.g., captions)."; WCAG 1.0 Checkpoint 14.1 which provides that web pages shall "[u]se the clearest and simplest language appropriate for a site's content."; WCAG 1.0 Checkpoint 1.3 which provides that "[u]ntil user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation."; and WCAG 1.0 Checkpoint 6.2 which provides that web pages shall "[e]nsure that equivalents for dynamic content are updated when the dynamic content changes."

Section 1194.23(c)(3) of the proposed rule required that web pages alert a user when there is a change in the natural language of a page. The "natural language" referred to the spoken language (e.g., English or French) of the web page content. The WAI pointed out that the preamble to the NPRM misinterpreted this provision. The preamble suggested that a statement such as "the following paragraph is in French" would meet the provision. WAI responded by noting that this was not the intent of the provision. The WCAG 1.0 recommend that web page authors embed a code or markup language in a document when the language changes so that speech synthesizers and Braille displays could adjust output accordingly.

The Trace Center advised that only two assistive technology programs could interpret such coding or markup language, Homepage Reader from IBM and PwWebspeak from Isound. These programs contain the browser, screen reading functions, and the speech synthesizer in a single highly integrated program. However, the majority of persons who are blind use a mainstream browser such as Internet Explorer or Netscape Navigator in conjunction with a screen reader. There are also several speech synthesizers in use today, but the majority of those used in the United States do not have the capability of switching to the processing of foreign language phonemes. As a result, the proposed provision that web pages alert a user when there is a change in the natural language of a page has been deleted in the final rule.

The Board also did not adopt WCAG 1.0 Checkpoint 14.1 which provides that web pages shall "[u]se the clearest and simplest language appropriate for a site's content." While a worthwhile guideline, this provision was not included because it is difficult to enforce since a requirement to use the simplest language can be very subjective.

The Board did not adopt WCAG 1.0 Checkpoint 1.3 which provides that "[u]ntil user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation." Although the NPRM did not propose addressing this issue in the web section, there was a similar provision in the multi-media section of the NPRM.

The Board did not adopt WCAG 1.0 Checkpoint 6.2 which provide that web pages shall "[e]nsure that equivalents for dynamic content are updated when the dynamic content changes." The NPRM had a provision that stated "web pages shall update equivalents for dynamic content whenever the dynamic content changes." The WAI stated in its comments that there was no difference in meaning between the NPRM and WCAG 1.0 Checkpoint 6.2. The NPRM provision has been deleted in the final rule as the meaning of the provision is unclear.

A web site required to be accessible by section 508, would be in complete compliance if it met paragraphs (a) through (p) of these standards. It could also comply if it fully met the WCAG 1.0, priority one checkpoints and paragraphs (l), (m), (n), (o), and (p) of these standards. A Federal web site that was in compliance with these standards and that wished to meet all of the WCAG 1.0, priority one checkpoints would also have to address the WAI provision regarding using the clearest and simplest language appropriate for a site's content (WCAG 1.0 Checkpoint 14.1), the provision regarding alerting a user when there is a change in the natural language of the page (WCAG 1.0 Checkpoint 4.1), the provision regarding audio descriptions (WCAG 1.0 Checkpoint 1.3), and the provision that web pages shall "ensure that equivalents for dynamic content are updated when the dynamic content changes (WCAG 1.0 Checkpoint 6.2).

The Board has as one of its goals to take a leadership role in the development of codes and standards for accessibility. We do this by working with model code organizations and voluntary consensus standards groups that develop and periodically revise codes and standards affecting accessibility. The Board acknowledges that the WAI has been at the forefront in developing international standards for web accessibility and looks forward to working with them in the future on this vitally important area. However, the WCAG 1.0 were not developed within the regulatory enforcement framework. At the time of publication of this rule, the WAI was developing the Web Content Accessibility Guidelines 2.0. The Board plans to work closely with the WAI in the future on aspects regarding verifiability and achievability of the Web Content Accessibility Guidelines 2.0.

Paragraph (a) requires that a text equivalent for every non-text element shall be provided. As the Internet has developed, the use of photographs, images, and other multimedia has increased greatly. Most web pages are created using HTML, or "HyperText Markup Language." A "page" in HTML is actually a computer file that includes the actual text of the web page and a series of "tags" that control layout, display images (which are actually separate computer files), and essentially provide all content other than text. The tags are merely signals to the browser that tell it how to display information and many tags allow web designers to include a textual description of the non-textual content arranged by the tag. The provision is necessary because assistive technology cannot describe pictures, but can convey the text information to the user. Currently, most web page authoring programs already provide a method for web designers to associate words with an image and associating text with non-textual content is easy for anyone familiar with HTML. This provision requires that when an image indicates a navigational action such as "move to the next screen" or "go back to the top of the page," the image must be accompanied by actual text that states the purpose of the image, in other words, what the image is telling you to do. This provision also requires that when an image is used to represent page content, the image must have a text description accompanying it that explains the meaning of the image. Associating text with these images makes it possible, for someone who cannot see the screen to understand the content and navigate a web page. (See §1194.23(c)(1) in the NPRM.)

Comment. In the NPRM, §1194.23(c)(1) required text to be associated with all non-textual elements, and prescribed the use of specific techniques, such as "alt" and "longdesc," to accomplish that requirement. WAI commented that, while the use of specific techniques was provided in WCAG 1.0 as examples of methods to use, the proposed rule was limiting the manner in which text could be associated with non-textual elements to two techniques. The result was that other approaches to providing text tags in web languages other than HTML were prohibited.

Other commenters pointed out that many images on a web page do not need text tags. They noted that some images are used to create formatting features such as spacers or borders and that requiring text identification of these images adds nothing to the comprehension of a page. These images were, in their view, textually irrelevant. One commenter suggested that this provision should address "every non-text element" because such features as buttons, checkboxes, or audio output were covered by other provisions in the proposed rule.

Response. This provision incorporates the exact language recommended by the WAI in their comments to the proposed rule. Non-text element does not mean all visible elements. The types of non-text elements requiring identification is limited to those images that provide information required for comprehension of content or to facilitate navigation. Web page authors often utilize transparent graphics for spacing. Adding text to identify these elements would produce unnecessary clutter for users of screen readers.

The Board also interprets this provision to require that when audio presentations are available on a web page, because audio is a non-textual element, text in the form of captioning must accompany the audio, to allow people who are deaf or hard of hearing to comprehend the content. (See §1194.23(c)(1) in the NPRM.)

Paragraph (b) provides that equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. This would require, for example, that if an audio portion of a multi-media production was captioned as required in paragraph (a), the captioning must be synchronized with the audio. (See §1194.23(c)(12) and (e)(3) in the NPRM.)

Comment. Comments from organizations representing persons who are deaf or hard of hearing strongly supported this provision. One commenter from the technology industry raised a concern that this provision would require all live speeches broadcast on the Internet by a Federal agency to be captioned. The commenter noted that an alternative might be to provide a transcript of the speech which could be saved, reviewed, and searched.

Response. This provision uses language that is not substantively different than the WCAG 1.0 and was supported in the WAI comments to the proposed rule. There are new techniques for providing realtime captioning which are supported by new versions of programs like RealAudio. Providing captioning does not preclude posting a transcript of the speech for people to search or download. However, commenters preferred the realtime captioning over the delay in providing a transcript. No substantive changes have been made to this provision in the final rule.

Paragraph (c) prohibits the use of color as the single method for indicating important information on a web page. When colors are used as the sole method for identifying screen elements or controls, persons who are color blind as well as those people who are blind or have low vision may find the web page unusable. This provision does not prohibit the use of color to enhance identification of important features. It does, however, require that some other method of identification, such as text labels, must be combined with the use of color. (See §1194.23(c)(2) in the NPRM.)

Comment. The WAI expressed concern that as proposed, the provision did not capture the intent of the provision as addressed in the WCAG 1.0. The intent of such a requirement, according to WAI, was to have web page designers use methods other than color to indicate emphasis such as bold text.

Response. This provision incorporates the exact language recommended by the WAI in their comments to the proposed rule. This provision addresses not only the problem of using color to indicate emphasized text, but also the use of color to indicate an action. For example, a web page that directs a user to "press the green button to start" should also identify the green button in some other fashion than simply by color.

Paragraph (d) provides that documents must be organized so they are readable without requiring browser support for style sheets. Style sheets are a relatively new technology that lets web site designers make consistent appearing web pages that can be easily updated. For instance, without style sheets, making headings appear in large font while not affecting the surrounding text requires separate tags hidden in the document to control font-size and boldface. Each heading would require a separate set of tags. Using style sheets, however, the web site designer can specify in a single tag that all headings in the document should be in large font and boldface. Because style sheets can be used to easily affect the entire appearance of a page, they are often used to enhance accessibility and this provision does not prohibit the use of style sheets. This provision requires that web pages using style sheets be able to be read accurately by browsers that do not support style sheets and by browsers that have disabled the support for style sheets. (See §1194.23(c)(4) in the NPRM.) This requirement is based on the fact that style sheets are a relatively new technology and many users with disabilities may either not have computer software that can properly render style sheets or because they may have set their own style sheet for all web pages that they view.

Comment. The WAI commented that while the provision was consistent with WCAG 1.0, the preamble inaccurately noted that this provision would prohibit the use of style sheets that interfere with user defined style sheets. The WAI noted that a browser running on a user's system determines whether or not style sheets associated with pages will be downloaded.

Response. The WAI correctly noted that this provision does not prohibit the use of style sheets that interfere with user-defined style sheets because the use of style sheets is controlled by a user's browser. This provision uses language that is not substantively different than WCAG 1.0 and was supported in the WAI comments to the proposed rule. No substantive changes have been made to this provision in the final rule.

Paragraph (e) requires web page designers to include redundant text links for each active region of a server-side image map on their web pages. An "image map" is a picture (often a map) on a web page that provides different "links" to other web pages, depending on where a user clicks on the image. There are two basic types of image maps: "client-side image maps" and "server-side image maps." With client-side image maps, each "active region" in a picture can be assigned its own "link" (called a URL or "uniform resource locator") that specifies what web page to retrieve when a portion of the picture is selected. HTML allows each active region to have its own alternative text, just like a picture can have alternative text. See §1194.22(a). By contrast, clicking on a location of a server-side image map only specifies the coordinates within the image when the mouse was depressed - which link or URL is ultimately selected must be deciphered by the computer serving the web page. When a web page uses a server-side image map to present the user with a selection of options, browsers cannot indicate to the user the URL that will be followed when a region of the map is activated. Therefore, the redundant text link is necessary to provide access to the page for anyone not able to see or accurately click on the map. (See §1194.23(c)(6) in the NPRM.) No substantive changes have been made to this provision in the final rule.

Paragraph (f) provides that client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape. As discussed above, there are two general categories of image maps: client-side image maps and server-side image maps. When a web browser retrieves a specific set of instructions from a client-side image map, it also receives all the information about what action will happen when a region of the map is pressed. For this reason, client-side image maps, even though graphical in nature, can display the links related to the map, in a text format which can be read with the use of assistive technology. (See §1194.23(c)(7) in the NPRM.)

Comment. The WAI suggested that the final rule include an exception for those regions of a map which cannot be defined with an available geometric shape.

Response. This provision incorporates the exact language recommended by the WAI in their comments to the proposed rule.

Paragraphs (g) and (h) permit the use of tables, but require that the tables be coded according to the rules for developing tables of the markup language used. When tables are coded inaccurately or table codes are used for non-tabular material, some assistive technology cannot accurately read the content. Many assistive technology applications can interpret the HTML codes for tables and will most likely be updated to read the table coding of new markup languages. (See §1194.23(c)(8-9) in the NPRM.) The Board will be developing technical assistance materials on how tables can comply with this section. In addition to these specific provisions, the technical assistance materials will address all of the provisions in this part.

Comment. Commenters were concerned by the preamble discussion in the NPRM which advised against the use of table tags for formatting of non-tabular material.

Response. The Board understands that there are currently few alternatives to the use of tables when trying to place items in predefined positions on web pages. These provisions do not prohibit the use of table codes to format non-tabular content. They require that when a table is created, appropriate coding should be used. Paragraph (g) incorporates the exact language recommended by the WAI in their comments to the proposed rule. Paragraph (h) uses language that is not substantively different than WCAG 1.0 and was supported in the WAI comments to the proposed rule. No substantive changes have been made to this provision in the final rule.

Paragraph (i) addresses the use of frames and requires that they be titled with text to identify the frame and assist in navigating the frames. "Frames" are a technique used by web designers to create different "portions" or "frames" of their screen that serve different functions. When a web site uses frames, often only a single frame will update with information while the other frames remain intact. Because using frames gives the user a consistent portion of the screen, they are often used for navigational toolbars for web sites. They are also often faster because only a portion of the screen is updated, instead of the entire screen. Frames can be an asset to users of screen readers and other assistive technology if the labels on the frames are explicit. Labels such as top, bottom, or left, provide few clues as to what is contained in the frame. However, labels such as "navigation bar" or "main content" are more meaningful and facilitate frame identification and navigation. (See §1194.23(c)(10) in the NPRM.) This provision uses language that is not substantively different than WCAG 1.0. No substantive changes have been made to this provision in the final rule.

Paragraph (j) sets limits on the blink or flicker rate of screen elements. This section is a result of the reorganization of the final rule and is similar to section 1194.21(k) discussed above. (See §1194.21(c) in the NPRM.) This provision is meant to be consistent with WCAG 1.0 Checkpoint 7.1 which provides that, "[u]ntil user agents allow users to control flickering, avoid causing the screen to flicker." This provision uses language which is more consistent with enforceable regulatory language.

Paragraph (k) requires that a text-only web page shall only be provided as a last resort method for bringing a web site into compliance with the other requirements in §1194.22. Text-only pages must contain equivalent information or functionality as the primary pages. Also, the text-only page shall be updated whenever the primary page changes. This provision is meant to be consistent with WCAG 1.0 Checkpoint 11.4 which provides that "[i]f, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page."

Paragraph (l) requires that when web pages rely on special programming instructions called "scripts" to affect information displayed or to process user input, functional text shall be provided. It also requires that the text be readable by assistive technology such as screen reading software. Scripts are widely used by web sites as an efficient method to create faster or more secure web communications. A script is a programmatic set of instructions that is downloaded with a web page and permits the user's computer to share the processing of information with the web server. Without scripts, a user performs some action while viewing a web page, such as selecting a link or submitting a form, a message is sent back to the "web server", and a new web page is sent back to the user's computer. The more frequently an individual computer has to send and receive information from a web server, the greater chance there is for errors in the data, loss of speed, and possible violations of security. Also, when many users are simultaneously viewing the same web page, the demands on the web server may be huge. Scripts allow more work to be performed on the individual's computer instead of on the web server. And, the individual computer does not have to contact the web server as often. Scripts can perform very complex tasks such as those necessary to complete, verify, and submit a form and verify credit information. The advantage for the user is that many actions take place almost instantly, because processing takes place on the user's computer and because communication with the web server is often not necessary. This improves the apparent speed of a web page and makes it appear more dynamic. Currently, JavaScript, a standardized object-oriented programming language, is the most popular scripting language, although certain plug-ins (see below) support slightly different scripting languages. This provision requires web page authors to ensure that all the information placed on a screen by a script shall be available in a text form to assistive technology. (See §1194.23(c)(11) in the NPRM.)

Comment. The NPRM was more specific in its application, providing that pages must be usable when scripts, applets, or other programmatic objects are turned off or are not supported. The NPRM permitted the use of an alternative accessible page. Several commenters found the proposed provision too restrictive. They noted that, as proposed, it could severely discourage innovation both for web page developers and for designers of assistive technology. It was argued that if producers of assistive technology know that a web page would never require access to scripts, there would be no incentive to develop better access to these features. It was also pointed out that discussing scripts, applets, and plug-ins in the same provision was not appropriate, because plug-ins were actual programs that run on a user's machine and do not necessarily originate on the web page. Scripts, on the other hand, are downloaded to a user's system from the web page (or an associated file) and, unlike applets or plug-ins, operate completely inside the browser without any additional software. Therefore, as scripts directly affect the actual content of a web page, the web page designer has control over designing a script but does not have control over which plug-in a user may select to process web content.

Response. The final rule has two separate provisions for scripts (l), and applets and plug-ins (m). Web page authors have a responsibility to provide script information in a fashion that can be read by assistive technology. When authors do not put functional text with a script, a screen reader will often read the content of the script itself in a meaningless jumble of numbers and letters. Although this jumble is text, it cannot be interpreted or used. For this reason, the provision requires that functional text, that is text that when read conveys an accurate message as to what is being displayed by the script, be provided. For instance, if a web page uses a script only to fill the contents of an HTML form with basic default values, the web page will likely comply with this requirement, as the text inserted into the form by the script may be readable by a screen reader. By contrast, if a web page uses a script to create a graphic map of menu choices when the user moves the pointer over an icon, the web site designer may be required to incorporate "redundant text links" that match the menu choices because functional text for each menu choice cannot be rendered to the assistive technology. Determining whether a web page meets this requirement may require careful testing by web site designers, particularly as both assistive technology and the JavaScript standard continue to evolve.

Paragraph (m) is, in part, a new provision developed in response to comments received on §1194.23(c)(11) of the NPRM and discussed in the preceding paragraph. While most web browsers can easily read HTML and display it to the user, several private companies have developed proprietary file formats for transmitting and displaying special content, such as multimedia or very precisely defined documents. Because these file formats are proprietary, they cannot ordinarily be displayed by web browsers. To make it possible for these files to be viewed by web browsers, add-on programs or "plug-ins" can be downloaded and installed on the user's computer that will make it possible for their web browsers to display or play the content of the files. This provision requires that web pages which provide content such as Real Audio or PDF files, also provide a link to a plug-in that will meet the software provisions. It is very common for a web page to provide links to needed plug-ins. For example, web pages containing Real Audio almost always have a link to a source for the necessary player. This provision places a responsibility on the web page author to know that a compliant application exists, before requiring a plug-in. (See §1194.21(c)(11) in the NPRM.)

Paragraph (n) requires that people with disabilities have access to interactive electronic forms. Electronic forms are a popular method used by many agencies to gather information or permit a person to apply for services, benefits, or employment. The 1998 Government Paperwork Elimination Act requires that Federal agencies make electronic versions of their forms available on-line when practicable and allows individuals and businesses to use electronic signatures to file these forms electronically. (See §1194.23(b)(10) in the NPRM.) At present, the interaction between form controls and screen readers can be unpredictable, depending upon the design of the page containing these controls. Some developers place control labels and controls in different table cells; others place control labels in various locations in various distances from the controls themselves, making the response from a screen reader less than accurate many times.

Comment. Adobe Systems expressed concern that completing some forms requires a script or plug-in and interpreted the proposed rule as prohibiting such items. They pointed out that there are other methods of completing a form that would not require scripts or plug-ins, but those methods require the constant transfer of information between the client and server computers. Adobe noted that that method can be extremely inefficient and can pose a security risk for the individual's personal data.

Response. This provision does not forbid the use of scripts or plug-ins and many of the existing products support these features. If a browser does not support these features, however, paragraphs (l) and (m) require that some other method of working with the web page must be provided. As assistive technologies advance, it is anticipated that the occasions when the use of scripts and plug-ins are not supported will diminish significantly. No substantive changes have been made to this provision in the final rule.

Paragraph (o) provides that a method be used to facilitate the easy tracking of page content that provides users of assistive technology the option to skip repetitive navigation links. (See §1194.23(c)(13) in the NPRM.) No substantive comments were received on this provision and no changes were made, other than editorial changes.

Paragraph (p) addresses the accessibility problems that can occur if a web page times-out while a user is completing a form. Web pages can be designed with scripts so that the web page disappears or "expires" if a response is not received within a specified amount of time. Sometimes, this technique is used for security reasons or to reduce the demands on the computer serving the web pages. A disability can have a direct impact on the speed with which a person can read, move around, or fill in a web form. For this reason, when a timed response is required, the user shall be alerted and given sufficient time to indicate that additional time is necessary. (See §1194.21(d) in the NPRM.)

Comment. The proposed rule prescribed specific settings for increasing the time-out limit based on a default setting. The Board sought comment on whether a system was commercially available that would allow a user to adjust the time-out. The Board also sought information on whether the proposed provision would compromise security. Commenters responded that security would be an issue if the time-out period was extended for too long and information with personal data was left exposed. Other commenters raised the point that specifying specific multiples of the default was unrealistic and arbitrary. The Multimedia Telecommunications Association (MMTA) stated that the default was not built-into a system. Rather, it was generally something that was set by an installer or a system administrator. They also noted that in order for a user to know that more time is needed, the user must be alerted that time is about to run out.

Response. The provision has been revised as a performance standard rather than a specific design standard by removing the reference to a specified length of time for users to respond. The Board agrees that it would be difficult for a user to know how much more time is needed even if the time-out could be adjusted. The final rule requires only that a user be notified if a process is about to time-out and be given an opportunity to answer a prompt asking whether additional time is needed.

Section 1194.23 Telecommunications Products (Preamble, Section-by-Section Analysis)

Paragraph (a) requires that telephone equipment shall provide a standard non-acoustic connection point for TTYs. A TTY is a device that includes a keyboard and display that is used to transmit and receive text over a telephone line using sound. Originally, TTY's used acoustic connections and the user placed the telephone handset on the TTY to transfer the sound signals between the TTY and the telephone. Handsets on many modern telephones do not fit well with many TTY acoustic couplers, allowing interference from outside noise. Individuals who use TTYs to communicate must have a non-acoustic way to connect TTYs to telephones in order to obtain clear TTY connections, such as through a direct RJ-11 connector, a 2.5 mm audio jack, or other direct connection. When a TTY is connected directly into the network, it must be possible for the acoustic pickup (microphone) to be turned off (automatically or manually) to avoid having background noise in a noisy environment mixed with the TTY signal. Since some TTY users make use of speech for outgoing communications, the microphone on/off capability must be automatic or easy to switch back and forth or a push-to-talk mode should be provided. In the Telecommunications Act Accessibility Guidelines (36 CFR Part 1193), the Board recognized that direct-connect TTYs are customer premises equipment (CPE) subject to section 255 of that Act. Since CPE is a subset of electronic and information technology, it is similarly covered by this rule. This provision was adopted from the Board's Telecommunications Act Accessibility Guidelines so that manufacturers of telecommunications and customer premises equipment covered by section 255 of the Telecommunications Act wishing to sell products to the Federal government would have a consistent set of requirements. (See §1194.23(d)(1) in the NPRM.)

Comment. The MMTA commented that providing a direct connection to an analog telephone may be as simple as providing an RJ-11 jack, but that digital phones pose additional problems. It noted that most multi-line business phones operating through a PBX are digital phones. However, it also stated that TTY connectivity can be accomplished by adding an analog line similar to what would be provided for a fax machine. The MMTA further suggested that TTY manufacturers should share the burden for compatibility. Another comment suggested that the Board require the provision of a shelf and outlet for a TTY.

Response. In some cases, the addition of an RJ-11 connector will be the easiest solution. In other cases, the addition of a "smart" adapter may be necessary, similar to the dataports available on many hotel phones. Some adapters and converters have circuitry which determines the nature of the line and plug-in equipment and makes the adjustment automatically while others are manual. There is merit, however, in viewing this provision from the standpoint of the capabilities of a system as opposed to the capabilities of a single desktop unit. There may be cases in which the connection is best made at the PBX level by installing analog phone lines where necessary. The final provision has been modified to allow for either option.

With respect to the suggestion that the standards require a shelf and outlet for a TTY, these standards apply to the electronic and information technology products themselves, not the furniture they occupy. Therefore, these standards do not address auxiliary features such as shelves and electrical outlets.

Paragraph (b) requires that products providing voice communication functionality be able to support use of all commonly used cross-manufacturer, non-proprietary, standard signals used by TTYs. Some products compress or alter the audio signal in such a manner that standard signals used by TTYs are not transmitted properly, preventing successful TTY communication. This provision is consistent with the Telecommunications Act Accessibility Guidelines. (See §1194.23(d)(2) in the NPRM.)

Comment. Comments from industry suggested that the Board should clarify the standard referred to as U.S. standard Baudot communications protocol. They noted that there are several standards in use in Europe. Some European products support more than one of these standards, but not the common U.S. standard. The comments said that such products would arguably comply with the provision but would not meet the intent of section 508.

Response. The proposed rule required that products must support all cross-manufacturer, non-proprietary protocols, not just one or two. Of course, that included the common U.S. Baudot protocol (ANSI/TIA/EIA 825). ASCII is also used, especially on dual mode TTYs, but it is less common. Compliance with international standard ITU-T Recommendation V.18 would meet this provision, but products complying with the ITU standard may not be commercially available. It is important that products and systems support the protocol used by most TTYs currently in use to avoid a disenfranchisement of the majority of persons who are deaf or hard of hearing. However, the intent of this provision is to require support of more than just Baudot or just ASCII. At present, only these two are commonly used in the U.S., but others may come into use later. While the Board does not want to disenfranchise users of current devices, neither does it want to exclude those who buy newer equipment, as long as such devices use protocols which are not proprietary and are supported by more than one manufacturer. Of course, like all the requirements of these standards, this provision is subject to commercial availability. Accordingly, the provision has been changed in the final rule by adding the phrase "commonly used."

Paragraph (c) provides that TTY users be able to utilize voice mail, auto-attendant, and interactive voice response telecommunications systems. Voice mail systems are available which allow TTY users to retrieve and leave TTY messages. This provision does not require that phone systems have voice to text conversion capabilities. It requires that TTY users can retrieve and leave TTY messages and utilize interactive systems. (See §1194.23(d)(3) in the NPRM.)

Comment. One commenter suggested that the Board encourage developers to build-in direct TTY decoding so that external TTYs are not required. For example, if an employee had voice mail with TTY functionality built-in, that employee would be able to read TTY messages through the computer system directly, without needing to attach an external TTY. The commenter noted that this would be beneficial to Federal agencies having telephone communication with members of the public who have speech or hearing disabilities. The agency could then have direct communication rather than being required to use an external TTY device or utilizing a relay service. Another said telecommunications systems should be required to have TTY decoding capability built-in, to the maximum extent possible. Another commenter pointed out that voice mail, voice response, and interactive systems depend on DTMF "touch tones" for operation and that many TTYs do not provide this function. Also, one commenter noted that automatic speech recognition (ASR) is not yet mature, but requested that a requirement for ASR be reviewed every two years to determine the feasibility of including such capabilities in products based on the rapid change of technology.

Response. This provision requires that voice mail, auto-attendant, and interactive voice response systems be usable with TTYs. It is desirable that computers have built-in TTY capability and there are currently systems which can add such functionality to computers. This provision is a performance requirement and the Board does not feel it would be useful to be more specific at this time. The current problems with voice mail and voice response systems are not necessarily susceptible to a single solution and there are several ways to comply, including voice recognition in some cases, depending on the system. Many voice mail systems could record a TTY message, just like a voice message, but the outgoing message needs to include a TTY prompt letting TTY users to know when to start keying. A requirement for a quick response to menu choices is the most frequently reported barrier for relay users. The ability to "opt out" of a menu and connect with an operator or transfer to a TTY system are also ways to make these services available and usable without highly sophisticated decoding technology.

Paragraph (d) addresses access problems that can arise when telecommunications systems require a response from a user within a certain time. Due to the nature of the equipment, users of TTYs may need additional time to read and respond to menus and messages. This provision is identical to section 1194.22(p) discussed above. (See §1194.21(d)(4) in the NPRM.)

Comment. The proposed rule prescribed specific settings for increasing the time-out limit based on a default setting. Commenters raised the point that specifying specific multiples of the default was unrealistic and arbitrary. The MMTA stated that the default was not built-into a system. Rather it was generally something that was set by an installer or a system administrator. It also noted that in order for users to know that more time is needed, they must be alerted that time is about to run out.

Response. The provision has been changed to a performance standard rather than a specific design standard by removing the reference to a specified length of time for users to respond. The Board agrees that it would be difficult for a user to know how much more time is needed even if the time-out could be adjusted. The final rule requires only that a user be notified if a process is about to time-out and be given an opportunity to answer a prompt asking whether additional time is needed.

Paragraph (e) requires that functions such as caller identification must be accessible for users of TTYs, and for users who cannot see displays. (See §1194.23(d)(5) in the NPRM.)

Comment. One commenter thought the reference to telecommunications relay services in the NPRM implied that caller identification information must somehow be transmitted directly to the end-user.

Response. Since the end-users in a telecommunications relay service are not directly connected, passing along caller identification information is not commonly done, therefore, the reference to relay services has been deleted to avoid confusion.

Paragraph (f) requires products to be equipped with volume control that provides an adjustable amplification up to a minimum of 20 dB of gain. If a volume adjustment is provided that allows a user to set the level anywhere from 0 to the upper requirement of 20 dB, there is no need to specify a lower limit. If a stepped volume control is provided, one of the intermediate levels must provide 12 dB of gain. The gain applies to the voice output. (See §1194.23(d)(6) in the NPRM.)

Comment. Several commenters supported the provision for a 20 dB gain, but some supported a 25 dB requirement, pointing out that many persons who are hard of hearing need more than 20 dB amplification. Others urged the Board to adopt the current Federal Communications Commission's (FCC) requirement for a minimum of 12 dB and a maximum of 18 dB. Some commenters said amplifying a poor quality signal would not be useful and that the amplification may itself introduce distortion.

Response. The proposed level of amplification was different from that required under the FCC regulations implementing the Hearing Aid Compatibility Act (47 CFR 68.317 (a)). The FCC requires volume control that provides, through the receiver in the handset or headset of the telephone, 12 dB of gain minimum and up to 18 dB of gain maximum, when measured in terms of Receive Objective Loudness Rating.

The Board's provision is consistent with the 1998 ANSI A117.1 document, "Accessible and Usable Buildings and Facilities." ANSI is the voluntary standard-setting body which issues accessibility standards used by the nation's model building codes. The Board has issued a separate NPRM to harmonize the existing ADAAG provision with the ANSI standard. The FCC originally selected its requirement to be consistent with the ADA Accessibility Guidelines now being proposed for amendment. This provision is consistent with the proposed ADA and Architectural Barriers Act Accessibility Guidelines and the Telecommunications Act Accessibility Guidelines. No changes were made to this provision in the final rule.

Paragraph (g) requires that an automatic reset be installed on any telephone that allows the user to adjust the volume higher than the normal level. This is a safety feature to protect people from suffering damage to their hearing if they accidentally answer a telephone with the amplification turned too high. (See §1194.23(d)(7) in the NPRM.)

Comment. Most commenters supported the provision for an automatic reset. One commenter said the reset would be a problem for an individual user who would be required to constantly readjust his or her telephone to a usable level.

Response. The provision is adopted from the ADA Accessibility Guidelines, where it applies to public phones used by many people. The FCC's Part 68 rules require an automatic reset when the phone is hung up if the volume exceeds 18 dB gain. To provide the ability to override the reset function would require a waiver from the FCC since the standards require a 20 dB gain. No changes have been made to this section in the final rule.

Paragraph (h) requires telephones, or other products that provide auditory output by an audio transducer normally held up to the ear, to provide a means for effective wireless coupling to hearing aids. Many hearing aids incorporate "T-coils" that generate sounds based on magnetic signals received from earpieces that can generate the appropriate magnetic field. Generally, this provision means the earpiece generates sufficient magnetic field strength to induce an appropriate field in a hearing aid T-coil. The output in this case is the direct voice output of the transmission source, not the "machine language" such as tonal codes transmitted by TTYs. For example, a telephone must generate a magnetic output so that the hearing aid equipped with a T-coil can accurately receive the message. This provision is consistent with the Telecommunications Act Accessibility Guidelines. (See §1194.23(d)(8) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Paragraph (i) requires that interference to hearing technologies be reduced to the lowest possible level that allows a user of hearing technologies to utilize a telecommunications product. Individuals who are hard of hearing use hearing aids and other assistive listening devices, but they cannot be used if products introduce noise into the listening aids because of electromagnetic interference. (See §1194.23(d)(9) in the NPRM.)

Comment. The American National Standards Institutes (ANSI) is developing methods of measurement and defining the limits for hearing aid compatibility and accessibility to wireless telecommunications. At the time of the proposed rule, the ANSI C63.19 ANSI/IEEE Standard for Hearing Aid Compatibility with Wireless Devices was not completed. The NPRM noted that the Board may ultimately incorporate the standard when it is completed. Several commenters recommended referencing the work of the ANSI committee.

Response. The ANSI committee has recently completed its work. No changes have been made to this provision in the final rule and the provision continues to be a performance standard rather than a specific design standard. However, compliance with the ANSI C63.19 ANSI/IEEE Standard for Hearing Aid Compatibility with Wireless Devices would meet this provision.

Paragraph (j) provides that all products that act as a transport or conduit for information or communication shall pass all codes, translation protocols, formats, or any other information necessary to provide information or communication in a usable format. In particular, signal compression technologies shall not remove information needed for access or shall restore it upon decompression. Some transmissions include codes or tags embedded in "unused" portions of the signal to provide accessibility. For example, closed captioning information is usually included in portions of a video signal not seen by users without decoders. This section prohibits products from stripping out such information or requires the information to be restored at the end point. (See §1194.25(a) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Paragraph (k) addresses controls that require some physical force to activate. It is the application of force to these controls that distinguishes them from touch sensitive controls where the mere presence of a hand or finger is detected and reacted to by the product. (See §1194.23(a) in the NPRM.)

Comment. As proposed, this provision addressed mechanically operated controls, keyboard, and keypads. Commenters were concerned that the provisions were too general. Some commenters said that it was possible to interpret this section as applying to touchscreens, and that making touchscreen controls compliant with these provisions was not possible. Commenters also raised the question of whether the proposed standards would require every product to have a keyboard.

Response. This provision has been amended to clarify its application to mechanically operated controls. The provision only applies to products which have mechanically operated controls or keys and therefore does not require every product to have a keyboard. This provision was not intended to apply to touchscreens as touchscreens do not have mechanically operated controls.

Paragraph (k)(1) provides that mechanically operated controls and keys shall be tactilely discernible without activating the controls or keys. Tactilely discernible means that individual keys can be located and distinguished from adjacent keys by touch. To comply with this provision, controls that must be touched to activate, must be distinguishable from each other. This can be accomplished by using various shapes, spacing, or tactile markings. Because touch is necessary to discern tactile features, this provision provides that the control should not be activated by mere contact. For example, the standard desktop computer keyboard would meet this provision because the tactile mark on the "j" and "f" keys permits a user to locate all other keys tactilely. The geographic spacing of the function, "numpad" and cursor keys make them easy to locate by touch. In addition, most keyboards require some pressure before they transmit a keystroke. Conversely, "capacitance" keyboards that react as soon as they are touched and have no raised marks or actual keys would not meet this provision. A "membrane" keypad with keys that must be pressed can be made tactilely discernible by separating keys with raised ridges so that individual keys can be distinguished by touch. (See §1194.23(a)(1) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Paragraph (k)(2) provides that mechanically operated controls shall be accessible to persons with limited dexterity. Individuals with tremor, cerebral palsy, paralysis, arthritis, or artificial hands may have difficulty operating systems which require fine motor control, assume a steady hand, or require two hands or fingers to be used simultaneously for operation. Individuals with high spinal cord injuries, arthritis, and other conditions may have difficulty operating controls which require significant strength. The provision limits the force required to five pounds and is based on §4.27.4 of the ADA Accessibility Guidelines and is consistent with the Telecommunications Act Accessibility Guidelines. (See §1194.23(a)(3) in the NPRM.)

Comment. The ITIC was concerned about requiring that all controls be easily activated. They pointed out that on many pieces of equipment the on/off switch is purposely set so that it is hard to activate. This is done to prevent accidental shut-down of equipment such as with a network server. They felt it was unreasonable to require changing that type of control.

Response. The Board has addressed this issue by adding §1194.3(f) which exempts such controls from these standards. The on/off switch on a network server for example, would be operated only when maintenance of the equipment was required and would not be for normal operation. No changes have been made to this section in the final rule.

Paragraph (k)(3) establishes provisions for key repeat rate where an adjustable keyboard repeat rate is supported. It requires that the keyboard delay before repeat shall be adjustable to at least two seconds per character. (See §1194.23(a)(5) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Paragraph (k)(4) provides that the status of toggle controls such as the "caps lock" or "scroll lock" keys be determined by both visual means and by touch or sound. For example, adding audio patterns such as ascending and descending pitch tones that indicate when a control is turned on or off would alleviate the problem of a person who is blind inadvertently pressing the locking or toggle controls. Also, buttons which remain depressed when activated or switches with distinct positions would meet this provision. (See §1194.23(a)(2) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Section 1194.24 Video and Multimedia Products (Preamble, Section-by-Section Analysis)

Paragraph (a) requires that television displays 13 inches and larger, and computer equipment that includes television receiver or display circuitry be equipped with the capacity to decode and display captioning for audio material. (See §1194.23(e)(1) in the NPRM.)

Comment. Commenters supported this provision in general, but provided suggestions for clarification. They noted that the FCC defines "television receiver" as a device that can receive and display signals from broadcast, satellite, cable transmission, or other similar transmission sources. The commenters recommended that the provision should also address television monitors that are used with video cassette recorders (VCRs), digital video disks (DVDs), or direct video input, but do not include tuners. These non-receiver displays are commonly used throughout the government and in educational institutions and therefore, should have the capability to decode closed captions. According to commenters, the provision should reference analog television's "line-21, NTSC" or "EIA-608" caption data decoding capabilities. Many DVD presentations already include line-21 captions and commenters expressed frustration with their inability to see these captions on their desktop or laptop computers. Commenters noted that subtitles are not a substitute for captions, as captions convey more than just dialog. One commenter stated that the provision should apply to screens 10 inches or larger; while another said that digital television (DTV) will allow usable captions on smaller screens and the Board should reference the digital captioning standard EIA-708.

Response. This provision has been clarified to cover all television displays, not just those defined as a receiver under the FCC definition. The 13-inch display size was chosen because it is consistent with the Television Decoder Circuitry Act of 1990. The term "analog" added to this provision clarifies the application of the provision.

At the time of the issuance of the NPRM, the FCC was considering a rule on digital television, but had not completed its rulemaking. On July 21, 2000, the FCC issued an order on decoder circuitry standards for DTV. That standard will take effect on July 1, 2002. Devices covered under the FCC rules include DTV sets with integrated "widescreen" displays measuring at least 7.8 inches vertically, DTV sets with conventional displays measuring at least 13 inches vertically, and stand-alone DTV tuners, whether or not they are marketed with display screens. The provision in the final rule has been changed to reflect the FCC regulation.

Paragraph (b) requires that television tuners, including tuner cards for use in computers, have the ability to handle a secondary audio track used for audio description of visual material. The secondary audio channel is commonly used for audio description. An "audio description" is a verbal description of the visual content of a presentation. Audio descriptions are important for persons who are blind or who have low vision because they provide a description of the visual content of a presentation synchronized with verbal information. (See §1194.23(e)(2) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Paragraph (c) requires the captioning of audio material in certain multimedia presentations. (See §1194.23(e)(3) in the NPRM.)

Comment. The NPRM limited the provision for captioning to productions that were procured or developed for repeated showings to audiences that may include people who are deaf or hard of hearing. Commenters were concerned that agencies would avoid this provision by saying that they did not anticipate having members of the audience who were deaf or hard of hearing. Commenters noted that in many instances providing an interpreter may not be a suitable alternative. They also pointed out that subtitles are not an effective substitute for captioning multimedia presentations because subtitles do not display the environmental sounds, descriptions of music, or additional text that conveys a richer content than mere translation of the spoken dialogue.

Response. As proposed, the provision was intended to require captioning whenever the audience might include a person who was deaf or hard of hearing. The final rule has been modified to require that all training and informational video and multimedia presentations that contain speech or other audio information necessary for the comprehension of the content and which supports an agency's mission, shall be open or closed captioned regardless of the anticipated audience. This provision would not require that a videotape recorded by a field investigator to document a safety violation be captioned or audio described, for example. On the other hand, if such a videotape were subsequently used as part of a training or informational presentation, it would have to be captioned and audio described. A video of a retirement celebration would not be in support of an agency's mission and would thus not be required to be captioned. Also, this provision applies only to video and multimedia presentations which contain speech or other audio information necessary for the comprehension of the content. A video that is not narrated would not be required to be captioned since it does not contain speech. The NPRM asked a question about the availability of software products that could be used to provide captioning or description to multimedia computer presentations. Information supplied by commenters suggests such products are readily available.

Paragraph (d) requires that certain multimedia presentations provide an audio description of visual material. (See §1194.23(e)(4) in the NPRM.)

Comment. The proposed rule limited the provision for audio description to productions that were procured or developed for repeated showings to audiences that may include people who are blind or who have low vision. Similar to (c) above, commenters were concerned that agencies may use the limitation to avoid providing the audio description.

Response. This provision has been modified to require audio description regardless of the anticipated audience. The final rule has been modified to require that all training and informational video and multimedia productions which support the agency's mission, regardless of format, that contain visual information necessary for the comprehension of the content, shall be audio described. A video or multimedia presentation that does not support an agency's mission would not be required to be audio described. Also, this provision applies only to videos or multimedia presentations which contain visual information necessary for the comprehension of the content. A "talking heads" video does not generally contain visual information necessary for the comprehension of the content and would therefore not be required to be audio described.

Paragraph (e) provides that the captioning and audio description required in (c) and (d) above must be user selectable unless permanent. (See §1194.23(e)(5) in the NPRM.)

Comment. The National Center for Accessible Media (NCAM) at public television station WGBH indicated that unlike captioning, audio descriptions can only be hidden and then activated on request on broadcast or cablecast video. The videotape format VHS commonly used by consumers and many companies cannot encode audio description for later activation like closed captions. Videos in the VHS format must have their descriptions permanently recorded as part of the main audio program. As a result, the audio descriptions on VHS cannot be turned off. As a solution, NCAM suggested that it may be desirable to have a separate videotape available that was not described, along with a described version to allow a user to choose which version they wish to present. Unlike the VHS format, CD-ROMs, DVDs and other multimedia can support alternate audio channels for descriptions (or alternate languages). The means of choosing those alternate tracks varies by the medium, but usually involves selection from an on-screen menu. Those menus must be made audible or otherwise readily selectable so that people who are blind or visually impaired can independently select and gain access to those audio descriptions.

Response. While the displaying of captioning is user selectable, there may be instances where the audio description would be considered permanent. The provision provides that when permanent, the user selectability provision does not apply. No changes have been made to this section in the final rule.

Section 1194.25 Self Contained, Closed Products (Preamble, Section-by-Section Analysis)

Sections 1194.25 (a) through (j) apply to those products that generally have embedded software and are commonly designed in such a fashion that a user cannot easily attach or install assistive technology. This section is a result of the reorganization of the final rule. In some instances, a personal computer with a touch-screen will be enclosed in a display and used as an "information kiosk. Self contained, closed products include, but are not limited to, information kiosks and information transaction machines, copiers, printers, calculators, fax machines, and other similar types of products. A definition of self contained, closed products has also been added.

Paragraph (a) provides that access features must be built-into a self contained, closed product rather than requiring users to attach an assistive device to the product. Personal headsets are not considered assistive technology and may be required to use the product. (See §1194.23(f)(1) in the NPRM.)

Comment. Though discussed in the preamble, the text of the proposed rule did not address the issue of personal headsets. The preamble noted that personal headsets were not considered assistive technology. The ITIC urged the Board to make this clear in the text of the rule.

Response. The Board has modified this provision by clarifying that personal headsets are not considered assistive technology. No other changes were made to this provision.

Paragraph (b) addresses access problems that can arise when self contained, closed products require a response from a user within a certain time and is identical to §1194.22 (p) and §1194.23 (d) which are discussed in detail above. (See §1194.21(d) in the NPRM.) The final rule requires only that a user be notified if a process is about to time-out and be given an opportunity to answer a prompt asking whether additional time is needed.

Paragraph (c) requires that when a product utilizes touchscreens or contact-sensitive controls, a method of operating the product be provided that complies with the provisions for controls in §1194.23 (k) (1) through (4). (See §1194.21(f) in the NPRM.)

Comment. The proposed rule required that touchscreens or touch-operated controls be operable without requiring body contact or close human body proximity. Commenters found the proposed provision to be confusing. One commenter noted that the proposed rule required all touchscreens to be operable by a remote control. Several commenters expressed concern that accessibility to touchscreens for individuals who are blind or who have low vision was not adequately addressed.

Response. Touchscreens and other controls that operate by sensing a person's touch pose access problems for a range of persons with disabilities. This provision does not prohibit the use of touchscreens and contact sensitive controls, but, as modified, the final rule requires a redundant set of controls that can be used by persons who have access problems with touchscreens.

Paragraph (d) addresses the use of biometric controls. Biometric controls refer to controls that are activated only if particular biological features (e.g., fingerprint, retina pattern, etc.) of the user matches specific criteria. Using retinal scans or fingerprint identification may become a common practice as a method of allowing an individual to gain access to personal data from an information transaction type of machine. (See §1194.21(e) in the NPRM.)

Comment. In the proposed rule, the Board sought comment on the best approach to accessibility issues raised by biometric forms of identification and controls. Commenters responded that asking a system to have multiple forms of biometric identification could be prohibitively expensive. Most commenters were in agreement that biometric controls provide the most security. However, they also agreed that when such a system needs to be accessed by a person with a disability and that disability prohibits the use of a specific biometric feature, a non-biometric alternative should be provided that does not compromise security.

Response. The provision does not require a specific alternative. That selection is left up to the agency, which may choose a less expensive form of identification. No changes were made to this provision in the final rule.

Paragraph (e) requires that when products use audio as a way to communicate information, the auditory signal will be available through an industry standard connector at a standard signal level. Individuals using personal headphones, amplifiers, audio couplers, and other audio processing devices need a place to plug these devices into the product in a standard fashion. This gives the user the ability to listen privately to the information. The product must also provide a method to pause, restart, and interrupt the flow of information. (See §1194.23(f)(2) and §1194.25(d) in the NPRM.) No substantive comments were received on this provision and no changes were made, other than editorial changes.

Paragraph (f) provides that when products deliver voice output, they shall provide incremental volume control with output amplification up to a level of at least 65 dB. Where the ambient noise level of the environment is above 45 dB, a volume gain of at least 20 dB above the ambient level shall be user selectable. According to the Occupational Safety and Health Administration, and the American Speech, Language, and Hearing Association, 65 dB is the volume level for normal speech. This provision requires that audio output from a kiosk type product shall have a minimum level of 65 dB. For people with reduced hearing, voice levels must be 20 dB above the surround sound level to be understandable. This means that as long as the noise level in the surrounding environment is below 45 dB, the 65 dB output level would be sufficient. If the product is in an environment with a high noise level, the user must be able to raise the volume to a setting of 20 dB higher than the ambient level. (See §1194.23(f)(3) in the NPRM.) A feature has been required to automatically reset the volume to the default level after every use. This is consistent with a similar provision addressing telecommunications products. No substantive comments were received and no other changes have been made to this section in the final rule.

Paragraph (g) addresses the use of color prompting and is identical to section 1194.21(i) discussed above. (See §1194.21(a) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

Paragraph (h) addresses color selection and contrast settings and is identical to section 1194.21(j) discussed above. (See §1194.23(b)(8) in the NPRM.)

Paragraph (i) addresses the use of flashing objects and is identical to section 1194.21(k) discussed above. (See §1194.21(c) in the NPRM.)

Paragraphs (j) (1) through (4) provide provisions for the physical characteristics of large office equipment including reach ranges and the general physical accessibility of controls and features. Examples of these products, include but are not limited to, copiers, information kiosks and floor standing printers. These provisions are based on the Americans with Disabilities Act Accessibility Guidelines (ADAAG 4.2 Space Allowance and Reach Ranges). Two figures are provided to help explain the application of these provisions. (See §1194.21(b)(1) through (4) in the NPRM.) No substantive comments were received on these provisions and no changes were made in the final rule.

Section 1194.26 Desktop and Portable Computers (Preamble, Section-by-Section Analysis)

This section is a result of the reorganization of the final rule. Paragraphs (a) through (d) contain provisions that apply to desktop and portable computers. The provisions in §1194.21 for software address the accessibility of programs and operating systems that run on a computer. In contrast, the provisions in this section address physical characteristics of computer systems including the design of controls and the use of connectors. This section was previously addressed in §1194.21 (General requirements), §1194.23 (Component specific requirements) and §1194.25 (Requirements for compatibility with assistive technology) in the NPRM.

Paragraph (a) addresses keyboards and other mechanically operated controls. These provisions are addressed further in sections 1194.23 (k) (1) through (4) above. (See §1194.23(a) in the NPRM.)

Paragraph (b) provides that systems using touchscreen technology must also provide controls that comply with sections 1194.23 (k) (1) through (4) discussed above. (See §1194.21(f) in the NPRM.) Similar to §1194.25 (c), this provision was modified in the final rule to require redundant controls.

Paragraph (c) requires that when biometric forms of identification are used, an alternative must also be available. This provision is identical to §1194.25 (d) discussed above.

Paragraph (d) requires that products have standard ports and connectors. This means that the connection points on a system must comply with a standard specification that is available to other manufacturers. This provision assures that the designers of assistive technology will have access to information concerning the design of system connections and thus be able to produce products that can utilize those connections. (See §1194.25(b) in the NPRM.)

Comment. In the proposed rule, this provision was addressed in §1194.25(b) under the requirements for compatibility with assistive technology. A commenter noted that this provision was more specific to computer products and not to all products.

Response. As noted, this provision has been modified to apply to computer products.