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

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.