As discussed below (see pages 43-53), agencies’ self-evaluations of specific web pages indicate that emerging technologies, such as plug-ins, scripts, and applets, create many of the serious accessibility problems on federal agency web pages. While some of these technologies are currently inaccessible, they continue to be popular because they add interest to agencies’ web pages. Other technologies can be used to create accessible or inaccessible web pages, depending on how they are used. Agencies that use these technologies should incorporate appropriate guidance into their web accessibility guidelines and implementing procedures.

The Department asked, “If you have established web accessibility guidelines, please indicate which, if any, of the following topics are addressed by those guidelines (check as many as apply):” (Agency Question C-5)

1. N/A. We don’t have any web accessibility guidelines.
2. Adobe Acrobat Files (pdf's)
3. Microsoft PowerPoint files
4. Macromedia Flash content
5. Macromedia Shockwave content
6. JavaScript or other scripting languages
7. Java applets

In some instances, agencies selected more than one response. The numbers below reflect the total number of responses within each agency category.

• Some agencies indicated that they have not adopted any web accessibility guidelines. This includes 6 out of 18 (14.63% *) responses from large agencies; 2 out of 76 (2.63% *) responses from mid-sized agencies; 11 out of 32 (34.38% *) responses from small agencies; and 8 out of 25 (32.00% *) responses from very small agencies.

• Many agencies have adopted web accessibility guidelines that address Adobe Acrobat’s Portable Document Format (pdf) technology. This includes 8 out of 41 (19.51% *) responses from large agencies; 16 out of 76 (21.05% *) responses from mid-sized agencies; 9 out of 32 (28.13% *) responses from small agencies; and 7 out of 25 (28.00% *) responses from very small agencies.

• Some agencies have adopted web accessibility guidelines that address Microsoft’s Power Point technology. This includes 3 out of 41 (7.32% *) responses from large agencies; 7 out of 76 (9.21% *) responses from mid-sized agencies; 2 out of 32 (6.25% *) responses from small agencies; and 2 out of 25 (8.00% *) responses from very small agencies.

• Some agencies have adopted web accessibility guidelines that address Macromedia’s Flash technology. This includes 6 out of 41 (14.63% *) responses from large agencies; 10 out of 76 (13.16% *) responses from mid-sized agencies; 2 out of 32 (6.25% *) responses from small agencies; and 1 out of 25 (4.00% *) responses from very small agencies.

• Some agencies have adopted web accessibility guidelines that address Macromedia’s Shockwave technology. This includes 2 out of 41 (4.88% *) responses from large agencies; 11 out of 76 (14.47% *) responses from mid-sized agencies; 1 out of 32 (3.13% *) responses from small agencies; and 1 out of 25 (4.00% *) responses from very small agencies.

• Many agencies have adopted web accessibility guidelines that address Java Script or other programming languages. This includes 8 out of 41 (19.51% *) responses from large agencies; 15 out of 76 (19.74% *) responses from mid-sized agencies; 4 out of 32 (12.50% *) responses from small agencies; and 3 out of 25 (12.00% *) responses from very small agencies.

• Many agencies have adopted web accessibility guidelines that address Java applets. This includes 5 out of 41 (12.20% *) responses from large agencies; 14 out of 76 (18.42% *) responses from mid-sized agencies; 2 out of 32 (6.25% *) responses from small agencies; and 2 out of 25 (8.00% *) responses from very small agencies.

• A few agencies have adopted web accessibility guidelines that do not address any of these technologies. This includes 3 out of 41 (7.32% *) responses from large agencies; 1 out of 76 (1.32% *) responses from mid-sized agency; 1 out of 32 (3.13% *) responses from small agencies; and 1 out of 25 (4.00% *) responses from very small agencies.

While many agencies have accessibility guidelines, relatively few address the accessibility of advanced web page design issues, such as plug-in technologies, Java applets, scripts, or non-HTML file formats, the most popular of which is Adobe Acrobat’s Portable Document Format (pdf). Agencies should use the growing library of information that is available from industry to maximize the accessibility of web pages created using these technologies and incorporate relevant information into their web accessibility guidelines and implementation procedures.

5. Testing with Text-Only Browser Prior to Posting (Agency Question C-6)

Findings _____________________________________________________________________ Agencies do not consistently test web pages using a text-only browser prior to posting, although many agencies have created a timetable to do so.

Web developers without disabilities often have a difficult time understanding how their pages appear to users with disabilities, such as people who are blind and who use screen readers. One way to roughly simulate a blind user’s experience is to view the page through a text-only browser, such as the public domain browser “Lynx.” This step will give the viewer a basic indication of what text information would be conveyed to someone using a screen reader.

Most text-only browsers do not contain many of the same features as the latest versions of screen readers, however. For instance, text-only browsers generally cannot support scripting, which is commonly used to make web pages dynamic or interactive. Text-only browsers usually have trouble with web content beyond basic HTML, such as plugs-ins, which are specifically created to work with the most popular graphical browsers. Finally, some text-only browsers have difficulty with complex layouts, such as tables, in a document.

While viewing web pages through a text-only browser prior to posting is not a perfect indicator of whether the pages are accessible to people with disabilities, it is an easy way to double check some important accessibility features. For instance, it allows a web master to check whether all graphical elements have text associated with them and whether the text is sufficiently descriptive so as to be meaningful even when the graphics cannot be viewed.

Tip If possible, agencies should encourage web developers to test their web pages prior to posting with a text-only browser - such as the public domain "Lynx" browser. Such testing should not, however, replace a thorough understanding and implementation of good web design principles for accessibility.

The Department asked, “Does your agency have a policy requiring that prior to posting, web pages are "tested" using text-only browsers – such as the public domain “Lynx” browser – commonly used by people with disabilities?” (Agency Question C-6)

• Some agencies indicated that they have a policy to test pages using text-only browsers prior to posting those pages. This includes 4 of 18 large agencies (22.22% *); 7 of 21 mid-sized agencies (33.33% *); 6 of 21 small agencies (28.57% *); and 4 of 16 very small agencies (25.00% *).

• Some agencies indicated that while they do not currently have any such policy in place, they have established a timetable to develop one. This includes 5 of 18 large agencies (27.78% *); 3 of 21 mid-sized agencies (14.29% *); 10 of 21 small agencies (47.62% *); and 10 of 16 very small agencies (62.50% *).

• Some agencies indicated that they have no plans to develop such a policy. This includes 3 of 18 large agencies (16.67% *); 7 of 21 mid-sized agencies (33.33% *); 5 of 21 small agencies (23.81% *); and 1 of 16 very small agencies (6.25% *).

• Some agencies indicated that some portions of their agency test pages using text-only browsers prior to posting them, while others do not. This includes 6 of 18 large agencies (33.33% *); 4 of 21 mid-sized agencies (19.05% *); and 1 of 16 very small agencies (6.25% *).
Most agencies do not consistently test their web pages with a text-only browser prior to posting, but many agencies have established a timetable for setting up such a process. While the Department believes that testing with a text-only browser is a valuable step, it is generally more important that web developers have a keen understanding of agency-wide design principles that facilitate making web pages conform to the Section 508 Standards.⁴

6. Testing by Users with Disabilities (Agency Question C-7)

Finding _____________________________________________________________________ Agencies do not have consistent policies of testing web pages for accessibility using screen readers or other assistive technologies.

The most effective way to determine whether a web page is accessible to people with disabilities is to involve them in the testing process. The Department asked, “Does your agency have a policy requiring that prior to posting, web pages are “tested” using screen readers or other assistive technologies commonly used by people with disabilities?” (Agency Question C-7).⁵

• Some agencies have established policies that require web pages to be tested using screen readers or other assistive technologies prior to posting. This includes 6 of 18 large agencies (33.33% *); 8 of 21 mid-sized agencies (38.10% *); 4 of 21 small agencies (19.05% *); and 5 of 16 very small agencies (31.25% *).

• Some agencies have not adopted such policies, but have established a timetable for doing so. This includes 3 of 18 large agencies (16.67% *); 5 of 21 mid-sized agencies (23.81% *); 10 of 21 small agencies (47.62% *); and 6 of 16 very small agencies (37.50% *).

• Some agencies have no plans to adopt such a policy. This includes 4 of 18 large agencies (22.22% *); 5 of 21 mid-sized agencies (23.81% *); 6 of 21 small agencies (28.57% *); and 5 of 16 very small agencies (31.25% *).

• Some agencies have components that have adopted such policies and others that have not. This includes 5 of 18 large agencies (27.78% *); 3 of 21 mid-sized agencies (14.29% *); and 1 of 21 small agencies (4.76% *).

Tips Where possible, agencies should adopt policies that require that web pages are tested by people with disabilities familiar with the use of screen readers or other assistive technologies. Such testing should be performed either prior to posting new web pages or randomly through “spot checking” new web pages.

Most agencies do not uniformly test their web pages with screen readers or other assistive technologies prior to posting. Many of these agencies, however, have indicated that they have established a timetable for performing such testing. When agencies develop such procedures, they should, within agency constraints, enlist people with disabilities who are thoroughly familiar with assistive technologies to do the testing. It is very difficult to learn how to use screen readers and other types of assistive technologies properly. Accordingly, it is generally not advised for a non-disabled person who is unfamiliar with assistive technology to use this technology as an evaluation mechanism. For this reason, many agencies may decide to institute policies of periodic “spot-testing” of randomly selected web pages by experienced screen-reader users prior to posting, rather than having a screen reader user evaluate each and every new web page.

7. Providing Information About Accessibility to Users with Disabilities (Agency Question C-8)

Findings _____________________________________________________________________ Some agencies have provided accessibility features on their web pages that extend beyond the requirements of the Section 508 Standards, but these features may not be well-advertised to users with disabilities. Agencies do not consistently provide information to users with disabilities for using their web pages. Recommendations _____________________________________________________________________ Agencies should provide clear and detailed information about the accessibility of their web pages for users with disabilities. Where agencies use technologies that can set different options for improving the accessibility of their web pages, these options should be clearly identified and detailed information should be provided.

The Access Board’s section 508 web accessibility provisions, 36 C.F.R. § 1194.22, ensure a minimal level of accessibility for people with disabilities. There are many additional steps agencies can take to optimize a web site’s appearance or performance for people with disabilities. If agencies go beyond what is required by strict adherence to the Access Board’s Standards, they should communicate the availability of advanced web accessibility features to web page visitors.

The Department asked, “Does your agency provide clear and detailed information or options for improving the accessibility of your web sites for persons with disabilities?” (Agency Question C-8). A few agencies provide clear and detailed information or options for improving the accessibility of their web sites on all component-level home pages and on their agency-wide home page. This includes 4 of 18 large agencies (22.22% *); 6 of 20 mid-sized agencies (30.00% *); 2 of 21 small agencies (9.52% *); and 1 of 16 very small agencies (6.25% *).

• More agencies include such information on their agency-level home page, but not on component-level home pages. This includes 3 of 18 large agencies (16.67% *); 2 of 20 mid-sized agencies (10.00% *); 1 of 21 small agencies (4.76% *); and 2 of 16 very small agencies (12.50% *).

• Only one large agency (5.56% *) provides such information on component-level home pages, but not on its agency-wide home page.

• Many agencies do not include such information, but have established a timetable for doing so. This includes 3 of 18 large agencies (16.67% *); 4 of 20 mid-sized agencies (20.00% *); 11 of 21 small agencies (52.38% *); and 13 of 16 very small agencies (81.25% *).

• Many agencies have no plans to include such information on their web pages. This includes 2 of 18 large agencies (11.11% *); 4 of 20 mid-sized agencies (20.00% *); and 7 of 21 small agencies (33.33% *)

• A few agencies have parts that post such information and others that do not. This includes 5 of 18 large agencies (27.78% *); and 4 of 20 mid-sized agencies (20.00% *).

Agencies vary considerably in the amount of information provided to users with disabilities for using the agency web pages. Some agencies, particularly mid-size agencies, provide such information on all component-level home pages and on the agency-wide home page, while slightly fewer agencies in most categories provide such information only on their agency-level home page. Many of the mid-size and smaller agencies have established plans for providing such information.

While Agency Question C-8 was intended to help identify agencies that have used innovative technologies to deliver enhanced web page accessibility to people with disabilities, many agencies interpreted it to address communication of web accessibility remediation efforts. The wide variation in responses may be due to Agency Question C-8's ambiguity.

8. Permitting Users to Report Accessibility Problems (Agency Question C-9)

Findings _____________________________________________________________________ Most agencies provide e-mail addresses on their web sites to assist users with disablities. Recommendation _____________________________________________________________________ Agencies should designate and advertise an e-mail address to allow people with disabilities to inform them of accessibility problems encountered on agency web sites. Agencies should also use these requests to determine which older web pages should be updated and made accessible.

Agencies should establish an easy method for people with disabilities to request alternate format materials and to inform them of accessibility problems encountered on agency web sites. Even the most diligent agency personnel – committed to the full implementation of section 508 – may inadvertently post web pages that pose some accessibility problems. Furthermore, a lot of agency web pages were posted long before the Access Board’s web accessibility standards were published⁶. There is a high probability, therefore, that many pages encountered by people with disabilities – despite an agency’s best efforts – may not be fully accessible. The most effective way to address this concern is to post an e-mail address on each web site that people with disabilities can use to inform an agency of any accessibility problems encountered on that site and to request alternate formats of the materials, if appropriate.

To limit the possibility that these addresses will not be used by members of the public as general information “help” contacts, thus overwhelming agency webmasters with questions far beyond their responsibilities, agencies are encouraged to use language that is sufficiently tailored to elicit disability-related concerns. An “accessibility information” link on the Department of Justice’s own home page tells readers:

If you have a disability and the format of any material on our website interferes with your ability to access some information contained on our site, please email the Department of Justice webmaster at webmaster@usdoj.gov. The webmaster will refer your request to the appropriate Department component. The component will respond promptly to you by providing you with an alternate format of the requested material. To enable us to respond in a manner that will be of most help to you, please indicate the nature of the accessibility problem, your preferred format (electronic format (ASCII, etc.), standard print, large print, etc.), the web address of the requested material, and your full contact information so we can reach you if questions arise while fulfilling your request.

http://www.usdoj.gov/01whatsnew/accessibility_info.htm

The Department asked, “Has your agency designated and advertised an e-mail address to allow people with disabilities to inform you of accessibility problems encountered on your web site?” (Agency Question C-9)

• Some agencies already post an e-mail address and instructions for its use on agency web sites to enable people with disabilities to inform the agency of accessibility problems encountered on the web site. This includes 6 of 18 large agencies (33.33% *); 5 of 20 mid-sized agencies (25.00% *); 10 of 21 small agencies (47.62% *); and 6 of 16 very small agencies (37.50% *).

• Most of the remaining agencies have established a timetable to do so. This includes 9 of 18 large agencies (50.00% *); 14 of 20 mid-sized agencies (70.00% *); 9 of 21 small agencies (42.86% *); and 8 of 16 very small agencies (50.00% *).

• A few agencies have no such plans. This includes 1 of 20 mid-sized agencies (5.00% *); 2 of 21 small agencies (9.52% *); and 2 of 16 very small agencies (12.50% *).

• Three of 18 large agencies (16.67% *) indicated that some parts of their agency have taken this step, while others have not.

The data indicate that almost all of the agencies have already designated and advertised an e-mail address to allow people with disabilities to inform them of accessibility problems encountered on their web sites or have established a timetable for doing so.

While all agencies should post such e-mail addresses on their web sites, they do not have to post it on every such page. For instance, it may not be necessary to provide this information on all component home pages. Because agencies have differing levels of control over how their components develop their web pages, agencies should have some discretion in how this information is provided. For instance, an agency with a single portal-style web site that maintains tight control over the presentation of web content developed by all of its components may find it sufficient to provide the e-mail address only on the portal’s home page. By contrast, a large organization with many autonomous components may find that it must post the information on each of its components’ home pages, in order for people with disabilities to find it.

Communication between agencies and end users about accessibility, however, should be a two-way process. Agencies may reduce much of the frustration felt by users (and potentially many complaints), if they post information describing their plans for revising their web pages to improve accessibility for people with disabilities. Agencies should be as forthcoming as possible with their plans for improving the accessibility of their services. This simple step helps users with disabilities develop reasonable expectations and offers them a chance to provide input into an agency’s priorities. Increased input from the disability community may assist agencies in assigning priorities to their remediation efforts.

B. Surveys of Popular Web Pages

To assess the accessibility of federal agency web pages, the Department of Justice asked all agency components ⁷ to evaluate each of their 20 most popular web pages, using survey documents created by the Department. In total, agencies submitted evaluations for 5,600 web pages. The Department’s Web Accessibility Survey asked 27 questions (Web Questions), including basic questions about each web page (including the number of times it was accessed each week, the function of the web page, and whether the web page was publicly available), as well as specific information about the page’s accessibility features. The questions related to accessibility were based on the web accessibility technical provisions promulgated by the Access Board, 36 C.F.R. § 1194.22. The data from these self-evaluations allowed the Department to identify weaknesses and strengths within federal agency web pages based on a number of different criteria. Using the information about web page "hits," the Department was able to assess agency responses both in terms of the number of responses received (“unweighted” data) and based on actual usage through hits ("weighted" data).⁸

The first four questions (Web Questions 1-4) solicit background information and methodology.

In accessing a web site, someone who operates a computer uses browser software (e.g., Internet Explorer, Netscape Navigator) that receives specially encoded web pages and processes them to be viewable on a computer screen. To receive information from a federal agency’s web site, the user's computer makes a request over the Internet to an agency computer called a web server, which responds to the request by sending the encoded web page back to the user. The user's browser makes the web page viewable on a computer monitor or other device. To make sure that the correct web page is requested, each web page has a unique identifier, much like a specific telephone number. Like a telephone number, the web page identifier follows a standard protocol – in the case of web pages, a Uniform Resource Locator (URL) or the Uniform Resource Identifier (URI). The URL or URI is usually displayed at the top of the browser software each time a web page is accessed. For instance, almost all federal agencies maintain a home page. Typing in the URL for this page will take the user to the agency's home page.

Example II-1:Typing in http://www.usdoj.gov will take you to the U.S. Department of Justice's home page.⁹

In addition to a home page, agencies will maintain many other pages identified by different URL's.

Example II-2: Typing in http://www.usdoj.gov/crt/508/index.html will take you to the U.S. Department of Justice's section 508 web page.

To identify precisely the web pages that components evaluated, the Department asked, “What is the URL/URI of the web page?” (Web Question 1).

In addition to knowing the identity of each of the page components surveyed, the Department tried to determine the nature of those pages. The Department asked, “What is the best description for the purpose of the page?” (Web Question 2). Components were asked to select the most appropriate description of each page, from a list of categories. The Department used this information to identify strengths and weaknesses in the accessibility of different types of federal web pages.

Of the 5,600 web pages evaluated by the agencies, the total number of web pages in each of these categories is as follows:

• Web-based applications (403)
• Online form for receipt of services or benefits (50)
• Other online form (80)
• Instructions for receipt of services or benefits (255)
• Description of activities of your component (2,748)
• Employment postings (105)
• Inherently graphical content (54)
• Other (1,905)

Another distinction between categories of web pages is whether they are deployed on components’ or agencies’ intranet pages, on the Internet, or both. In general, intranet web pages can only be accessed from computers within an agency. Intranet web pages allow agencies to distribute information to their employees without disseminating this information publicly. Agencies commonly use intranet pages for making job announcements or to provide other information that may affect an employee’s ability to perform his or her job. By contrast, Internet pages can be accessed from any computer, including a computer outside the agency.¹⁰ Simply because a web page is part of the agency’s intranet (and thus inaccessible to the public) does not mean that the web page is not frequently accessed. For instance, many agencies now use web-distributed applications, which are computer programs that use a web-based interface. For instance, an agency may choose to use a computer program to let a large number of clerks collect information submitted on paper forms from the public in an agency database. To simplify this process, the agency may choose to deploy a web-based application over the agency’s intranet. In that case, employees at the agency may input information into the database through their web-browser. The advantage of this approach is that special software does not have to be installed on each individual workstation computer. The accessibility of the web-based application may directly affect an employee’s ability to perform his or her job.

In order to determine whether web accessibility barriers are more likely to affect federal employees or members of the public, the Department had to determine the intended audience for the surveyed web pages. The Department asked, “Is the page available on the Internet, an agency Intranet, or some combination?” (Web Question 3).

Of the 5,600 web pages evaluated by the agencies, the total number of web pages in each of these categories is as follows:

• Internet (447)
• Intranet (4,919)
• Combination (234)

Finally, the Department sought to compare the impact of different kinds of web accessibility barriers by determining the relative popularity of the pages containing those barriers. The Department asked, “On a weekly basis, how many times (approximately) is this page accessed by users?” (Web Question 4). The number of hits for each web page can identify its relative popularity. The data reflect that the 5,600 surveyed web pages accounted for a total of 211,257,848 weekly hits, with the number of weekly hits for any individual web page ranging from 1 hit to 58,000,000 hits.¹¹

To understand the Access Board’s web-related technical provisions and, consequently, the Department’s 2001 web accessibility questions, it is helpful to have a basic understanding of HTML (HyperText Markup Language). As noted above, the user’s browser interprets specially coded web pages and displays the content on the computer's screen. The page itself is generally coded in HTML, which is simply a standard way of representing the format and content of all information (other than text) on a web page with regular keyboard characters. ¹² HTML is often referred to as a “tag-based language,” because a web designer uses "tags" to determine the format or appearance of web page contents, such as boldface font, text aligned into tables, or images (which are separate computer files) inserted at specific locations on a web page. Generally, “tags” refer to a broad category of functions and must be used in conjunction with tag “attributes” that specify the exact features of the tag or page content affected by the tag. For instance, the <FONT> tag lets a user specify a special typeface for text in a web page:

<FONT face=”Time New Roman”>Time New Roman text</FONT>

In this example, the opening <FONT> and closing </FONT> tags specify that all text appearing in them will appear in a specific typeface. The word “face” is a tag “attribute”— in this case, it indicates that the <FONT> tag will be used for setting font to Time New Roman typeface. Together, the different combinations of “tags” and “attributes” comprise HTML. Although HTML is not complicated, many web designers use authoring tools (e.g., Microsoft FrontPage, Macromedia DreamWeaver, etc.) to facilitate rapid web page development. Using one of these programs lets web designers quickly write HTML pages that include carefully aligned graphics and consistent font selection.¹³ In the analysis below, a discussion of basic HTML is included to assist the reader in understanding each question and the basic design principles needed for accessibility.¹⁴

The remaining questions (Web Questions 5-25) solicit information regarding specific accessibility features of agency web pages.

1. Accessibility of Non-Text Elements (Web Question 5)

Findings _____________________________________________________________________ While most agency web pages include text for non-text elements, a large number of web pages do not. This lack of alternative text is a more signifcant problem with Internet pages than intranet pages. Recommendation _____________________________________________________________________ Because the lack of alternative text poses one of the most formidable barriers to users with disabilities, all agencies should devote considerable attention to eliminating this easily-solved problem.

Section 1194.22(a) of the Access Board’s Standards provides, “A text equivalent for every non-text element shall be provided (e.g., via 'alt', 'longdesc', or in element content).” 36 C.F.R. §1194.22(a)

Screen readers and other assistive technology devices usually require web page content to have underlying text in order to be accessible to persons with disabilities. For instance, screen readers, which read aloud the contents of a web page, and Braille displays, that convert the text on a web page into line-by-line Braille, both require a text-based output. Non-text elements, such as images and pictures, do not have “built-in” textual description. For instance, a picture of a Matisse painting on an agency web site does not, by itself, include a textual description of its image. Moreover, non-text elements are extremely pervasive in web site design, as web developers take advantage of carefully designed graphics for buttons, logos, and agency seals.¹⁵

Solving this major accessibility problem is extremely easy even for novice web developers. Furthermore, adding text to non-text elements can be done in a way that will not affect the “look and feel” of a web site. To give some idea of the simplicity of creating such alternative text, consider a web page that includes an image, such as the image of the Department of Justice’s seal shown in Example II-3.



To incorporate this image into a web page, the web designer uses a “tag” that creates a link to a separate computer file that actually stores the image.

<IMG SRC=”dojseal.jpg” border=0>

Rewriting this tag to include alternative text involves nothing more than simply adding the boldfaced language:

<IMG SRC=”dojseal.jpg” border=0 ALT=”Department of Justice Seal”>

This simple change is all that is required to make this image understandable to persons using screen readers or Braille displays. A person who is blind using a screen reader would then encounter the words, “Department of Justice Seal” and would know that the graphic was the Department seal instead of a map of the United States or other graphical content.

Tip In almost all cases, providing alternative text simply involves providing an alt attribute in most HTML tags supporting non-text content.

The Department asked, “Does each non-text element on the page have a text equivalent via “alt” (alternative text attribute) or does the page otherwise include a meaningful description of the non-text element in the text accompanying the non-text element?”

• The data indicate that while a large majority of component web pages meet this technical provision, many others do not. Overall, 4,250 of 5,600 (75.9%) web pages surveyed included text descriptions for all non-text elements.

• The weighted data is even more favorable: 85.1% of the “hits” for component web pages surveyed were on pages that either did not include any graphics or other non-text elements that would need a meaningful text label, or they included alternative text for all such non-text elements.

Both the weighted and unweighted data indicate that the lack of meaningful text labels for non-text elements appears more frequently on Internet pages than intranet pages.¹⁶ Because non-text images that are posted without alternative text pose one of the biggest, but most easily resolved, problems for users with disabilities, agencies should assign a high priority to correct this deficiency wherever it occurs.

2. Accessibility of Multimedia Content (Web Questions 6 and 7)

Findings _____________________________________________________________________ Most agencies do not include multimedia presentations in their web pages. Few web pages including multimedia content include features to assist users with disabilities Recommendation _____________________________________________________________________ As discussed below, funding is necessary to spur the development of accessible technologies, including applets, plug-ins, and other executable content. As multimedia is displayed using these technologies, such funding will facilitate the development of accessible multimedia technologies.

As the Internet continues to evolve, web page content continues to change from basic HTML (for laying out and formatting text) to content including multimedia technologies. These new technologies allow web designers to include presentations, short movies, or other content with synchronized audio and video tracks. By definition, multimedia presentations require the use of more than one sense for a complete experience of the page. While multimedia content may make web pages more interesting for people without disabilities, people with disabilities affecting one of the requisite senses face new barriers to understanding a page's content.

Section 1194.22(b) of the Access Board’s regulation provides, “Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.” For instance, if a multimedia presentation includes a narrator describing an event, it is not necessary to include as an audio description, "The narrator is wearing a blue sweater and brown pants,” as this information is not essential to understanding the content of the presentation. By contrast, if a multimedia presentation demonstrates the assembly of a mechanical device and the narrator states, “before turning the transverse bolt one-quarter turn counterclockwise, make sure that the axial screw is not loose,” the video demonstration of a user first checking the tightness of the axial screw before loosening the transverse bolt one-quarter turn would likely require an audio description in order to understand the meaning of the presentation. ¹⁷ Such audio descriptions are usually selectable, so that a non-disabled user can choose not to turn them on.

To ensure that multimedia presentations are accessible to users who are deaf or hard of hearing, section 1194.22(b) of the Access Board’s regulation requires that agencies provide text captioning to convey in text any important audio information (unless an exception exists). Such captioning can be included as part of the video track of the presentation and can also be selectable.

By itself, HTML does not provide a convenient way to display multimedia in a web page. Most web developers incorporating multimedia elements in their web pages make extensive use of third-party plug-ins that work in conjunction with the user’s browser software and which must be downloaded and installed separately. Thus, the solution for providing access to multimedia content will lie in improving the accessibility of plug-ins, applets, and other executable content— a topic which is discussed in length separately below.

To determine the accessibility of multimedia presentations on federal web sites, the Department asked, “For any multimedia content, is text captioning provided for all audible output and audible output provided for all important visual information?” (Web Question 6)

To determine that the accessibility features are appropriately synchronized on federal web sites, the Department asked, “Are all audio descriptions and text captions synchronized with their associated dynamic content?” (Web Question 7)

• The data indicate that little multimedia content is contained on federal web pages. Of the 5,600 page surveyed, only 95 (1.7%) included multimedia content. Of those 95 pages, however, most of them contain multimedia content that has not been made accessible to users with disabilities.

• Only 24 of these 95 pages included audible output for visual information and text captioning for audible output that is completely synchronized with changes in the content. Eight of the 95 pages failed to include text captioning synchronized with the audible output and 13 of the 95 pages failed to include audio descriptions synchronized to visual content. Finally, 50 of 95 pages provided both text captioning and audible output, but failed to synchronize either one with the content.

3. Appropriate Use of Color (Web Question 8)

Findings _____________________________________________________________________ Most agencies do not use color inappropriately on their web pages. While not a significant problem, improper use of color is a slightly greater problem in intranet web pages than Internet web pages.

Good web page design often makes full use of color. Relying exclusively on color to communicate important information, however, will affect persons who find it impossible or difficult to discern or differentiate colors, such as persons who are blind, or who have limited sight or color-blindness. For instance, if a web page has one green button and one red button that are identical except for color, the web page should not state, "click on the green button to go to the next page or click on the red button to start over." Making this element accessible merely requires the buttons to be labeled: "green" and "red," or "next" and "start over."

Section 1194.22(c) of the Access Board’s regulation provides, “Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.”

The Department asked, “Is the page capable of being understood and navigated even if users do not have the ability to identify specific colors or differentiate between colors?” (Web Question 8).

• The data indicate that reliance on color alone is not a significant problem for federal agency web pages. Of the 5,600 pages surveyed, only 153 (2.73%) relied on color alone as the way of conveying important information.

• The weighted data shows that a higher proportion of intranet-only web pages are affected by this problem. Of the 7,175,265 hits received by intranet web pages, 527,867 (7.4%) involved web pages where color was not used properly. By contrast, of the 195,937,961 hits for Internet web pages, only 1,164,716 (1%) were to web pages where color was not used properly.

4. Style Sheets (Web Questions 9 and 10)

Finding _____________________________________________________________________ Most agency web pages can be successfully viewed without support for style sheets.

One of the practical problems faced by webmasters maintaining a web site is keeping a consistent "look and feel" for the visitor. Because the appearance of a web page is controlled by a myriad of HTML tags (such as <b> for boldface, <i> for italics for basic character fonts), creating a multi-page web site that has a consistent style can be challenging, particularly when subtle changes are made to different pages by different developers over time. At the same time, keeping a consistent appearance within and between different pages is important to create a clean, professional look and to reduce clutter and confusion.

HTML has evolved to meet this challenge. Style sheets allow web designers to create a basic set of rules governing specified web pages that determine how those pages appear to visitors. More specifically, style sheets allow a web designer to specify rules of document style (e.g., fonts, margins, colors, etc.) once and have these rules applied to elements of document structure (e.g.,
headings, paragraphs, tables, lists, etc.). For instance, a web designer can specify in a single style sheet that:

• all major section headings will appear in large, boldface, blue font
• all paragraph headings will appear in boldface, black font
• all paragraph text will appear in small, italic, black font

When the web designer decides to change the look of the associated web pages - for instance, changing all paragraph headings to blue font - the web designer need only make a single change in a style sheet to effect the change throughout those pages.¹⁸

Because style sheets are a relatively modern technology, a potential problem created by style sheets is that only the most modern browsers can display a page using style sheets correctly. In some cases, people with disabilities use older browsers that work well with their assistive technologies. If a web page can only be understood or used by visitors using the latest browsers
that support style sheets, some people with disabilities may be unable to use those pages.

Therefore, web designers must ensure that their web pages are usable when style sheets are not supported or when support for style sheets is turned off.

Tip If developers prefer to use style sheets, judicious use of external style sheets may cause the fewest problems for users with disabilities.

The Access Board’s Standards address this concern. Section 1194.22(d) provides, “Documents shall be organized so they are readable without requiring an associated style sheet.” The Department’s corresponding question asked, “If the page uses cascading style sheets or JavaScript style sheets, is it viewable without style sheets or with style sheets turned off or not supported by the browser?” (Web Question 9).

• Of the 5,600 web pages surveyed by the agencies, only 90 (1.6%) were not viewable with style sheet support turned off or by browsers that did not support style sheets.

• The few problematic web pages were not widely used, accounting for only 454,773 weekly hits of the 211,257,848 total weekly hits (0.22%). Within this small sample size, the problem appears to be slightly greater for intranet web pages than Internet pages.

While style sheets can pose problems for some users with disabilities, style sheets can actually increase the accessibility of web pages for other people with disabilities. Some browsers enable style sheet users to set their own preferences for how pages are displayed. For instance, a user with low vision may use a style sheet so that regardless of what web pages he visits, all text is displayed in an extra large font with white characters on a black background. If designers set up their pages to override user-defined style sheets, people with disabilities may not be able to use those pages. For accessibility reasons, therefore, it is critical that designers ensure that their web pages do not interfere with user-defined style sheets.

The Department asked, “If the page uses cascading style sheets or JavaScript style sheets, is it designed so that it does not interfere with style sheets set by the browser?” (Web Question 10)

• Only 57 (1.02%) of the 5,600 web pages surveyed by the components interfered with any style sheets set by the browser. These few web pages were not widely used, accounting for only 458,327 weekly hits out of 211,257,848 total weekly hits (0.22%).

The data suggest that style sheets on federal web pages do not currently pose a wide-spread barrier for people with disabilities.

5. Image Maps (Web Questions 11, 12, and 13)

Findings _____________________________________________________________________ Server-side image maps on agency web pages are not a significant barrier, as few agency web pages include server-side image maps and even most of these maps were accessible through the use of redundant text links. While the large majority of client-side image maps are accessible, many are not. Recommendation _____________________________________________________________________ Agencies should add alternative text to ensure that all client-side image maps are accessible to users with disabilities.

Image maps are graphic images that respond to user actions. For instance, image maps can link to other web pages, trigger server-side programs that can generate a web page, or initiate scripts within the same page. Image maps are not just “maps,” but can include any type of image where different locations in the image create links to different web pages. Some web designers put text links in images to present a very clean look to their web pages or to embed text messages inside of icons. Example II-4 is used by the Department of Justice to help visitors to the Department’s web site quickly find home pages of different sections or divisions within the Department’s organizational structure. See Example II-4.



Although the image used in Example II-4 is not a geographic map, it is nevertheless considered an image map for purposes of this survey.

In general, there are two types of image maps: server-side image maps and client-side image maps. When a user selects an area of one of the older server-side image maps, the vertical and horizontal coordinates of the cursor location are transmitted back to the web page's server, which then calculates in which region of the image the user's cursor was located when the mouse was clicked and responds appropriately. By contrast, newer client-side image maps employ the user's browser to determine which region the user has selected. In general, server-side image maps are far less efficient because the web server, which may already be overburdened serving web pages to other users, must calculate how to respond based on the exact coordinates of where a user clicked his or her mouse button within an image.

Tip In client-side image maps, each map region is identified using an tag. As this tag accepts the alt attribute, which is an easy accessibility solution, agencies should ensure that all client-side image maps include alternative text in their client-side image maps.

It is very easy to design accessible client-side image maps. To make client-side image maps accessible, each region within the map can be assigned an alt attribute that can be read by a screen reader or other assistive technology device in exactly the same straightforward manner described in the analysis accompanying Web Question 5, above. Unfortunately, the same cannot be said of server-side image maps, which require redundant text links for accessibility. For instance, if an agency created a server-side image map, which was activated by clicking on any state in the map, a duplicate listing of links for every state would have to be provided to make the map accessible. ¹⁹ Because it is so much easier for client-side image maps to be made fully accessible to people with disabilities, the Access Board's final rule requires that agencies use client-side image maps instead of server-side image maps, except when the map regions cannot be defined with an available geometric shape. For instance, the code supporting a client-side image map may appear as,

<IMG src=”navigation.gif” border=”0" usemap=”#thismap”>
<MAP name=”thismap”>
<area shape="rect" coords="0,2,64,19" href="general.htm" alt="about us">
<area shape="rect" coords="65,2,166,20" href="jobs.htm" alt="jobs">
<area shape="rect" coords="167,2,212,19" href="faq.htm" alt="FAQ">
<area shape="rect" coords="214,2,318,21" href="location.htm" alt="Directions">
<area shape="rect" coords="319,2,399,23" href="contact.htm" alt="Phone Number">

Although this code may appear complicated, it is easy for web designers to understand. Most importantly, the only difference between a fully-accessible client-side image map and an inaccessible map are the boldfaced alt attributes above. The <IMG> tag identifies a picture that will include the regions of the “map.” The tag’s usemap attribute identifies the set of instructions for dividing the image into different regions. The <IMG> tag then encloses those instructions (note that the <IMG> tag’s usemap attribute and the <MAP> tag’s name attribute both have the same content). Finally, the <AREA> tags inside the <MAP> tags identify each region of the map that will trigger different actions. Because each region triggers a different action, each <AREA> tag accepts a separate alt attribute that describes what happens if that region is selected. ²⁰ The technical assistance materials in Appendix II-A provide further information about image maps.

Section 1194.22(e) of the Access Board’s regulation states, “Redundant text links shall be provided for each active region of a server-side image map.” To determine whether existing federal agency web pages satisfy this provision, the Department asked, “If the page includes any server-side image maps, are duplicate text links provided for all links within the server-side image maps?” (Web Question 11).

• Of the 5,600 web pages surveyed, only 259 (4.6%) included server-side image maps at all.

• Of these, only 159 (2.8%) failed to include redundant text links for all regions of the map and only 110 (2%) failed to include any redundant text links.

• Web pages with server-side image maps account for only 3,353,902 weekly hits out of 211,257,848 total weekly hits (1.6%). Most of these hits (2,148,395 or 1.02%) include accessible server-side image maps.

The data suggest that server-side image maps do not pose a prevalent barrier to people with disabilities accessing popular federal web pages.

Section 1194.22(f) of the Access Board’s regulation states, “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.” The Department asked, “If the page includes any server-side image maps, have you established a timetable to replace the server-side image maps with client-side image maps, except where the regions cannot be defined with an available geometric shape?” (Web Question 12)

• Of the 259 web pages that included server-side image maps, 112 are expected to be replaced with client-side image maps. Of these, 108 were identified as being inaccessible server-side image maps in Web Question 11.

Finally, the Department asked, “If the page includes one or more client-side image maps, does each map region have a text equivalent via "alt" (alternative text attribute) or does the page otherwise include a meaningful description of the non-text element in the text accompanying it?” (Web Question 13).

• Of the 5,600 web page surveyed, 1,189 (21.2%) included client-side image maps. Of these, 1,189 pages, 316 (26.6%) did not include alternative text for all map regions.

• Client-side image maps with accessibility problems accounted for 29,250,279 weekly hits (13.85%).

The data suggest that use of client-side image maps is already much more popular than use of server-side image maps among federal webmasters. While most component web pages that include client-side image maps are accessible, a large portion of these pages do not include alternative text for each map region. Web masters can make these image maps accessible simply by adding alternative text to each map region.

6. Tables (Web Question 14)

Findings _____________________________________________________________________ Many agency web pages include data tables that are not accessible to users with disabilities. Fortunately, however, the impact of this problem is slightly reduced in light of the usage of these web pages. Web-based applications, which likely rely on dynamically-generated tables, present greater accessibility problems for users with disabilities. Recommendations _____________________________________________________________________ Agencies should ensure that data tables are accessible, using either the combination of header and id attributes or the scope attribute. Agencies should concentrate on ensuring that scripts or other server-side programmatic elements that generate tables are programmed to incorporate these accessibility features. Agencies should avoid use of pre-formatted data tables created using the <PRE> tag

Many federal web pages contain data tables. Tables are grid-like presentations of information laid out in rows and columns. They are commonly used to display numeric or statistical information, where numbers or other data occupy cells located along specific horizontal rows and under specific vertical columns. For instance,

		Wages for Summer 2001
	June	July	August
Mark	$360.30	$720.59
Judy	$720.59	$360.30
Trina	$720.59	$720.59
Bill		$720.59	$720.59

Example II-5

Improperly designed tables can present unique problems for people with disabilities who use screen readers and refreshable Braille displays. Assistive technology devices typically represent information in one dimension (e.g., as a stream of text), while tables rely on their two-dimensional structure to convey information. In order to make a table intelligible, the screen reader or other device must be able to convey information about each cell’s position in the overall structure of the table. Most screen readers and refreshable Braille displays read one line at a time, from left to right, top to bottom, depriving the user of the relational information necessary to put the cell’s contents into context. If someone using a screen reader accesses the table in Example II-5, he or she would likely hear:

Wages for Summer 2001 June July August Mark $360.30 $720.59 Judy $720.59, $360.30, Trina $720.59 $720.59, Bill $720.59 $720.59

For larger tables, this lack of relational context becomes even more significant.

Tip Making tables accessible is easier using the scope attribute in table header cells than using the id attribute in header cells and the header attribute in all data cells.

Web developers can use several HTML attributes to make most HTML tables accessible to people who use screen readers and other types of assistive technologies. One solution is to use the "id" and "header" attributes to identify table rows and headers within each cell. Another solution, which is much simpler to implement, is to use the “scope” attribute only in those cells along the border of the table that identify each row and column. ²¹ For instance, if the scope attribute is used in just seven of the cells (June, July, August, Mark, Judy, Trina, and Bill), the table suddenly becomes much more understandable. A user with a screen reader who encounters the modified table would likely hear:

Wages for Summer 2001
Mark	$360.30 (Mark, June) $720.59 (Mark, July)
Judy	$720.59 (Judy, June) $360.30 (Judy, July)
Trina	$720.59 (Trina, June) $720.59 (Trina, July)
Bill	$720.59 (Bill, July) $720.59 (Bill, August)

Although lengthy, this stream of text is fully understandable, because the screen reader can make meaningful associations between columns (June, July, August) and rows (Mark, Judy, Trina, Bill) that identify each cell in the table. Moreover, web developers making this or similar tables accessible do not have to significantly change the way that they design their tables, because the screen reader is able to provide the row and header information once the web developers have identified which row and header information (here, months and names of workers) are relevant. Although not all screen readers are currently able to make use of these attributes, more sophisticated screen readers that can do so are being introduced. ²²

Another type of table is a preformatted table created using the <PRE> tag. HTML browsers do not ordinarily render "whitespace" (e.g., spaces, tabs, carriage returns, etc.) in an HTML document as anything other than a single space. Most of the time, this feature makes page layout very easy. Web developers can freely insert spaces and extra lines between words and tags without disturbing the ultimate appearance of the page. Occasionally, however, web developers want greater control over spacing in a document and may create tables by simply adding extra spaces between column entries. HTML's <PRE> and </PRE> tags facilitate this process by formatting everything between these tags as preformatted text. Thus, extra spaces will be interpreted as extra spaces. Tables are much simpler to create – merely by adding extra spaces between <PRE> tags, instead of requiring careful use of <TABLE> tags (and table row and table cell tags). The disadvantages of this approach are that screen readers cannot be told anything about the structure of the table and the tables are visually far less appealing because all table content must appear in monospace font. For instance, to create the following table:

Wages for Summer 2001
June		July	August
Mark	$360.30	$720.59
Judy	$720.59	$360.30
Trina	$720.59	$720.59
Bill	$720.59		$720.59
	Example II-6

The HTML code appears as:

<PRE>
Wages for Summer 2001
June		July	August
Mark	$360.30	$720.59
Judy	$720.59	$360.30
Trina	$720.59	$720.59
Bill	$720.59		$720.59
</PRE>
	Example II-7

Using the <PRE> tag to make tables renders them inaccessible to people who use screen readers and other types of assistive technology, because there is no indication to the users that the contents are, in fact, in a table. Furthermore, there is no way to meaningfully associate the information in each "cell" with a particular "column." Someone using a screen reader to access the table in Example II-7 would hear:

Wages for Summer 2001 June July August Mark $360.30 $720.59 Judy $720.59, $360.30, Trina $720.59 $720.59, Bill $720.59 $720.59

To avoid this problem, web developers should not use the <PRE> tag to create tables.

The Section 508 Standards contemplate both of these problems. Section 1194.22(g) of the Access Board’s Standards states, “Row and column headers shall be identified for data tables.” 36 C.F.R. §1194.22(g). In addition, section 1194.22(h) states, “markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.” 36 C.F.R. § 1194.22(h).

The Department asked, “If the page includes data in tables (either HTML tables or preformatted text tables using the <PRE> tag), and if any of the tables has two or more rows (including header or data cells), does each cell provide identification of row and column headers?” (Web Question 14)

• Of the 5,600 pages surveyed, 734 (13.11%) included data tables without information identifying columns and rows.

• Weighted data shows that 11,833,717 weekly hits of 211,257,848 total weekly hits (5.6%) were for web pages that included data tables without information identifying columns and rows.

Web-based applications, which act like software programs deployed through the Internet, rely on server-based computer programs to generate content. Because any tables in those web-based applications are likely to be created “on-the-fly” by a computer program, it is particularly easy to include the HTML “markup” necessary for accessibility. The data suggest that federal employees with disabilities may be disproportionately affected by this problem:
• Within the sub-category of web-based applications, inaccessible data tables comprise 4,418,678 weekly hits of 12,659,115 total weekly hits (34.9%).

• Web pages used by federal employees are most at risk. The weighted data based on deployment method show that a significant number of weekly hits (2,168,377 of 8,144,622 - or 26.6%) for “combination” web pages (deployed on the Internet, but having portions available only on agency terminals) included inaccessible tables.

The survey results for Web Question 14 indicate that the way tables are currently used by federal web masters creates a significant problem for users with disabilities.

Updates: Many statistical agencies rely heavily on large and complex tables for organizing and presenting information. When these agencies published this information to their web pages, they once faced a difficult task in making this information readily accessible to and usable by individuals with disabilities. FedStats, an interagency group of over 100 federal statistical agencies, hosted a workshop focusing on this issue in 2002 and anticipates releasing a white paper that all agencies should consult in making large and complex table accessible to persons with disabilities. The Department of Justice and Access Board both participated in the development of this work.

7. Frames (Web Question 15)

Finding _____________________________________________________________________ Frames do not create a major barrier to accessibility. The large majority of web pages do not use frames. Those web pages that do use frames are designed in a way to be generally accessible to users with disabilities.

Although once almost ubiquitous, frames have become less popular for formatting information as developers have incorporated new ways of presenting information. Most commonly, frames are used to divide the browser screen into separate regions, with each area presenting different, but usually related, information. For instance, as shown below, a developer may use frames to place navigational links on the left side of the screen (Navigation Section, in this example) and the substance in a larger frame on the right (First Page Section, in this example):



In this way, a user can more easily navigate different areas of a web site while keeping track of where he or she is in relation to the overall web site. ²³

Tips Use the title attribute to help make frames conform to the Section 508 Standards. Provide text in each frame identifying the contents of the frame.

To ensure that web pages using frames are accessible to people with disabilities, designers should provide meaningful titles to each of the frames so that users can properly orient themselves. Otherwise, those who use screen readers or other types of assistive technologies will be unable to fully understand the relationships among multiple frames on the same page. Incorporating titles for different frames is extremely easy. For instance, simply adding the boldfaced language in the following line of code to the tags helps create an accessible 2-frame web page:

<FRAMESET cols=”30%, 70%”>
<FRAME src=”nav.htm” name=”navigation” title=”navigation frame”>
<FRAME src=”content.htm” name=”content” title=”content frame”>
</FRAMESET>

The <FRAMESET> tags act as a container for <FRAME> tags and establish how each frame will appear within it. For instance, here the col attribute indicates that the frames will be laid out in columns and that the first frame will occupy 30% of the screen width and that the second frame will occupy 70% of the screen’s width. Each of the tags then uses attributes to (a) specify the file that will be displayed in that frame (src attribute), (b) a shorthand name that can be used to identify which frame’s contents will be changed (name attribute), and (c) a title for the frame for assistive technology (title attribute). The only features separating accessible frames from inaccessible frames is the presence of the title attribute in the <FRAMESET> tag.

While the HTML 4.0 specification includes the title attribute as a means of making each frame within a web page accessible, the title attribute is not yet widely supported by assistive technology. Therefore, web designers interested in making frames accessible should also include a textual description of the frames content in the HTML source for each frame. For instance, in Example II-8, above, textual descriptions of “Navigation Section” and “First Page Section” has been provided in the text of the frame’s content.

The Access Board’s provision section 1194.22(i) states, “Frames shall be titled with text that facilitates frame identification and navigation.”

The Department asked, “If the page uses frames, does each frame have a title that meaningfully describes it?” (Web Question 15)

• Of the 5,600 web pages surveyed, only 398 used frames.

• Of the 398 that used frames, 236 (59.3%) included titles that meaningfully described them.

• Based on usage, web pages without frames accounted for 183,381,449 weekly hits of a total of 211,257,848 weekly hits (86.8%).

• Web pages that included frames without meaningful titles accounted for 14,427,230 weekly hits of a total of 211,257,848 weekly hits (6.8%).

• In the sub-category of federal agency employment postings, 111,000 out of 933,614 weekly hits (11.9%) contained frames that did not have meaningful titles.

• In the sub-category of “other” web pages, 12,967,600 out of 45,222,557 weekly hits or 28.68% were for web pages that contained frames that did not have meaningful titles.

The data suggest that the use of untitled frames poses a barrier for users with disabilities, but one that is less prevalent than some of the other barriers surveyed.

8. Screen Flicker (Web Question 16)

Finding _____________________________________________________________________ Screen flicker is not a significant problem in agency web pages.

Some individuals with photosensitive epilepsy may have seizures triggered by displays which flicker or flash, particularly if the flash has a high intensity and is within a certain frequency range. Seizures can be triggered by flickering or flashing in the 2 to 55 flashes per second (Hertz) range. Developers should avoid using strobe light effects - abrupt changes from light to dark - or using flashes in any color range at a rate of 2 to 55 flashes per second. Flashing or flickering elements are usually added through technologies such as animated gif's, Java applets, or third-party plug-ins or applications. Java applets and third-party plug-ins can be identified by the presence of <APPLET> or <OBJECT> tags. Animated gif's are images that download in a single file (like ordinary image files), but have content that changes over short periods of time. Like other images, however, they are usually incorporated through the use of the <IMG> tag.

Subsection 1194.22(j) of the Access Board’s Standards states, “Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.” 36 C.F.R. §1194.22(j).

The Department asked, “Does the page include content (such as applets or content requiring plug-ins) that may cause the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz?” (Web Question 16)

• Of the 5,600 web pages surveyed by the agencies, only 42 (0.75%) included content that caused the screen to flicker with a frequency of greater than 2 Hz and lower than 55 Hz.

• Web pages with prohibited flicker accounted for only 1,168,378 weekly hits out of a total of 211,257,848 total weekly hits (0.55%).

The data suggest that flickering content is not currently a significant problem for component web pages.

9. Scripting (Web Question 17)

Findings _____________________________________________________________________ While scripts are very common on agency web pages, most uses of scripts do not create accessibility problems for users with disabilities. Inaccessible scripts created a more significant problem for web-based applications than other types of agency web pages.

When a web page is requested from a server, the page is usually processed on the web server. Even in those cases where a web page is generated by a computer program (e.g., search engines), the web page that is ultimately delivered to the browser usually does not change once it is rendered on the user’s browser. In other words, the web page is static once it is delivered to the user.

Anyone who regularly uses the Internet is aware, however, that many modern web pages are anything but “static.” Instead, web pages are becoming increasingly dynamic, in the sense that they respond immediately to users’ actions. Sometimes, these dynamic features are simple and subtle, like a feature that highlights a button when the user passes his or her mouse over the button’s image. Other times, the effects are less dramatic, such as a feature that immediately displays an error message if the user does not enter a credit card number on an online order form. In both cases, the web page uses some form of client-side processing, because the programming necessary for invoking these actions take place on the user’s computer and not on the powerful servers that deliver the web page. For the user, the web page is more satisfying because it reacts much more quickly and there is no need to wait for a new page to download. For the agency or online company, the burden on its web server is greatly reduced because routine processing is now shared with the user’s computer.

Client-side processing (also known as dynamic web pages) may be generated through the use of scripts, plug-ins, or other programmatic objects. Each of these methods of generating dynamic content poses some accessibility challenges. ²⁴

Scripts are simply sets of computer instructions that are embedded in a web page's HTML coding. They are typically used by web designers to perform relatively rudimentary functions such as verifying the contents of a form or changing images on a screen when a user passes a cursor over the image. They can be easily identified by reviewing a page's HTML source coding for a tag that begins with the word "script." For instance, the following code is a strong indication that the web page is using scripting:

<SCRIPT language="JavaScript1.2">

This line of code identifies JavaScript as the language for the script. JavaScript is an object-oriented programming language that was specifically designed for dynamic web page content. ²⁵Most modern browsers provide support for JavaScript, although there are subtle variations between browsers and the amount of support that they offer for JavaScript. Recently, Macromedia Flash, a popular software program for developing dynamic web page content, has included scripting technology roughly similar to JavaScript. This technology may hold the promise of extremely graphical, user-friendly, dynamic content for computer users.

In the past, scripts presented two common difficulties for people with disabilities. First, scripts can be used to change elements - such as when "rollover gif’s" are activated. A rollover gif changes an image on the screen when the user moves his or her mouse over the image. Such scripts are inaccessible because the script is used to change an element that does not have functional text associated with it. If a script changes the content of a page without somehow indicating (through text readable by a screen reader) that it has changed the content of the page, the script cannot be made accessible.

Subsection 1194.22(l) of the Access Board’s technical provisions states, “When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.” 36 C.F.R. § 1194.22(l).

The Department asked, “If the page uses scripts, such as JavaScript or scripts in Macromedia Flash content, and if the scripts affect any content displayed to the user, is there equivalent text provided by the page or the script that is accessible to a screen reader?” (Web Question 17)

• The data indicate that scripts are very commonly used by the agencies, accounting for 1,325 (23.7%) of a total 5,600 web pages surveyed. In most cases, functional text or some text equivalent was provided to make the script accessible to a screen reader.

• Ultimately, only 314 of 5,600 (5.6%) were completely inaccessible.

• The weighted data indicate that there are wide-spread problems with scripts, with pages containing inaccessible scripts accounting for a total of 10,639,225 weekly hits out of 211,257,848 total weekly hits (5%).

• In the sub-category of web-based applications, 2,500,977 weekly hits out of 12,659,115 total weekly hits (19.8%) were for pages that contained inaccessible scripts.

Tip Agencies should be aware that event handlers may also cause accessibility problems not addressed in the Section 508 Standards. For instance, event handlers triggered by mouse movements can be inaccessible to blind users while possibly complying with section 1194.22(l) of the Standards.

The second common difficulty posed by scripts for people with disabilities arises when the event handler triggering the script cannot be activated through the keyboard. For example, rollover gif's can often only be activated through mouse movement. People with disabilities who cannot functionally use a computer mouse - such as those who are blind or those who are quadriplegic cannot access the rollover gif. Fortunately, most event handlers have recently become accessible through keyboard commands, due to improvements in the assistive technology used by people with disabilities. Neither the Access Board’s Standards nor the Department’s questionnaire directly addresses this concern.

10. Applets, Plug-Ins, and Other Executable Content (Web Questions 18 - 20)

Findings While few agencies use applets or content requiring plug-ins, the applets and content requiring plug-ins that are currently used are generally inaccessible to users with disabilities. Adobe Acrobat (pdf) files are commonly used on agency web pages and many of these files are inaccessible to users with disabilities. Recommendations Developers interested in deploying Java applets should make sure to include the accessibility features currently available from Sun Microsystems. Congress should authorize and fund the use of limited challenge grants by agencies to spur the development of accessible technologies, including applets, plug-ins, and other executable content, in web pages and other areas. These grants should be administered by the General Services Administration and overseen by the interagency Section 508 Steering Committee. Agencies should be sure that pdf files deployed through their web pages are created using the latest version of Adobe Acrobat. Personnel responsible for development of any pdf content for agencies should be sure that such files are created in accordance with the recommendations of Adobe for creating accessible content.

Apart from scripts, there are other technologies that depart from basic HTML in providing content to a user’s browser. Subsection 1194.22(m) of the Access Board’s technical provisions states, “When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).” 36 C.F.R. §1194.22(m). There are significant differences among the accessibility implications for applets, plug-ins, and other applications.

Applets. Applets are special programs written in Java, an object-oriented programming language developed by Sun Microsystems. Java’s most unique feature is that it allows the same program to be run on different machines supporting it. Thus, a Java program written for a Windows computer can run easily on a UNIX, LINUX, or Macintosh computer without any reprogramming. Java accomplishes this task through the use of a Java Virtual Machine (JVM), which is a program developed for each different computer platform that provides a common “computer within a computer” on which the Java program can run. Because web pages are displayed on a variety of different computers, the Internet provided a natural application for Java. Most modern browsers include a JVM that will run applets, which are small rudimentary Java programs customized for delivery through web pages. Applets are different from scripts because they are not included in the HTML content of the web page and are partially compiled to run faster on the user's computer. Applets are also different from content developed for plug-ins because they are written in Java and do not normally require the addition of third-party software to operate. The JVM used in most current browsers does not work with the special accessibility features developed by Sun Microsystems for Java, and most Java applet developers do not make use of these special features when creating applets. ²⁶ Specifically, Java programs and applets can be made accessible if they use the so-called Swing components, which grew out of Sun Microsystem’s work on the so-called Java Foundation Classes (first announced in 1997). Because browser support for the Swing components requires a separate software download from Sun Microsystems and is not included in the browser software shipped by most companies, many web developers using Java do not include them in their applets. ²⁷ At the time the Department’s survey was distributed, information about making accessible applets was not as widely available as it is now. At that time, the Department advocated that web developers should provide text alternatives. ²⁸ Since then, the Department has gained much greater insight into the accessibility of Java applets and applications. The Department now recommends that web developers who use Java applets should investigate information provided by Sun Microsystems for developing accessible content.

The Department asked, “If the web page uses applets, such as downloadable Java applets, does it also contain the same information and functionality in an accessible format?” (Web Question 18)

• Of the 5,600 web pages surveyed by the components, only 147 (2.6%) included Java applets.

• While inaccessible pages accounted for only 73 of the total pages (1.3%), this figure represents almost half (49.7%) of the pages containing applets.

• In the subcategory of federal agency employment postings, 110,140 weekly hits of a total 933,614 weekly hits (11.8%) were for pages that included inaccessible applets.

The data indicate that few agency web pages use applets, but that a significant number of those applets are inaccessible to people with disabilities. The problem is most prevalent on pages containing federal agency employment postings.

Plug-ins are third-party "add ons" to a computer browser that allow third-party companies to develop special content not normally available using basic HTML. For instance, the multimedia and streaming videos that are available in many commercial information service web sites use plug-ins to enable web pages to provide real-time broadcasts of radio and television programs. Plug-ins are really separate computer software applications created by third-party manufacturers. As such, they must meet the Access Board’s software accessibility technical requirements for web pages at 36 C.F.R. pt. 1194.21. Plug-ins can usually be detected by examining a page's HTML for the presence of an <OBJECT> tag. Some plug-in manufacturers, however, may require the use of more specialized or proprietary tags.

The Department asked, “If the page uses other programmatic objects (such as Flash, Shockwave, RealAudio, or RealVideo content), or otherwise requires the use of plug-ins or programmatic support for the browser, does the page include a link to the plug-in or programmatic item required for accessing the content of the page and is that plug-in or programmatic item itself accessible to people with disabilities?” (Web Question 19)

• Of the 5,600 web pages surveyed by the agencies, only 232 used any kind of plug-in technology at all (4.1%).
• Of these 232 web pages, 122 (56.7%) included significant accessibility problems for users with disabilities.
• Of the 211,257,848 total weekly hits, 64,996,566 weekly hits (30.8%) involved pages with inaccessible plug-in content.
• In the subcategory of web pages that describe components’ activities, pages containing inaccessible plug-in content accounted for 61,231,565 weekly hits out of 145,093,263 total weekly hits (42.2%).
• In the subcategory of Internet web pages (as opposed to intranet pages), those requiring plug-ins that were inaccessible accounted for 61,880,623 weekly hits of 195,937,961 weekly hits (31.6%).
• For those “combination” web pages that were distributed both on the Internet and through an intranet, web pages requiring plug-ins that were inaccessible accounted for 3,115,849 of 8,144,622 total weekly hits (38.7%).

Just as agencies have not made extensive use of applets, federal agencies have not widely adopted plug-in technologies. Unfortunately, the weighted data indicate that some of these plug-in technologies pose significant difficulties for users with disabilities, especially on web pages that describe components’ activities, Internet pages, and “combination” pages.

The Department recognizes that plug-in technologies may be extremely important for some agencies to fulfill their missions. Plug-in technologies allow industry to develop new and innovative ways of delivering information through the Internet. Multimedia presentations and vivid graphics can convey powerful messages and explain ideas that may be difficult or impossible through other media. As many agencies educate and inspire us and future generations, it is important that they not allow the opportunities created by these currently inaccessible technologies to go unused. At the same time, section 508 and common sense requires us to make sure that we do not exclude people with disabilities from the opportunities created by this new technology.

Challenge Grants Some problems confronting users with disabilities involve modern technologies (including Java applets, plug-ins, and other content that extend beyond basic HTML) that are currently inaccessible to users with disabilities. For instance, “plug-in” technologies for dynamic or multimedia content, electronic forms, or precise document presentation are increasingly popular among agency web sites. In some cases, developing accessible versions of these technologies simply involves letting market forces encourage manufacturers to develop these technologies on their own. However, in these years of cost-cutting in the information technology industry, this approach may be insufficient. Targeted challenge grants would encourage the development of accessible cutting-edge technologies.

The next section includes a discussion of an exciting project spearheaded and funded by the General Services Administration (GSA). In an effort to make paper-based agency forms accessible to users with disabilities, GSA issued a grant of $275,000 to develop an accessible version of this technology. While technically successful, the project ultimately could not be publicly deployed for contractual reasons ²⁹, but it demonstrates the promise of obtaining huge improvements in accessibility, cost savings, and paperwork reduction by a small initial investment. It allowed complicated paper forms to become independently accessible to users with disabilities. As agencies work to implement section 508, the Department has often heard that many technology solutions are easily within reach, but the limited budgets of many assistive technology manufacturers and other small companies delay or stop them from developing them. Even large companies may be unwilling to commit funding, as they are under increasing demand for short-term profit. Ultimately, we all suffer. Agencies cannot fulfill their missions as effectively because they cannot use the features that modern technology provides, important messages are not effectively conveyed to the American public, and section 508 is viewed as a “creative straightjacket” on the federal agencies.

The Department recommends following GSA’s example by identifying problems that can be solved in a very short time through careful and targeted funding. Manufacturers and developers should be able to seek grants from federal agencies for very limited funding for research and development of feasible solutions to accessibility problems. If these manufacturers and developers believe that they can successfully bring such a solution to market within one year, then additional grants may be appropriate. These funds should be contingent upon successful delivery of such technologies within one year. ³⁰ Because section 508 presents challenges to all federal agencies, these grants should be administered centrally by GSA. Proposals should be evaluated by and grants issued based upon the ecommendations of the current Section 508 Steering Committee. ³¹ The Department recommends that GSA develop a proposal for a government-wide challenge grant program and seek limited appropriations from Congress to fund this program. This proposal should be based on real-world problems identified by federal agencies, private industry, and disability rights organizations and should be reviewed by all agencies in the current Section 508 Steering Committee.

Adobe Acrobat's Portable Document Format (pdf). Many agencies have turned to Adobe Acrobat's portable document format (pdf) to ensure a more controlled presentation of documents posted to their web sites than is available with basic HTML. Because HTML is not designed for extremely precise representations of data on a computer screen or printer, it permits some flexibility that can benefit users with disabilities. For instance, as most browsers permit users to increase the size of the font displayed on their screens, a user with limited vision can often increase the font size and the web page will reformat itself to meet the new specifications. On the other hand, HTML's lack of precision can be frustrating for users or web designers who want web-transmitted documents to look exactly like printed documents. For instance, HTML cannot ensure that fonts, margins, and page breaks will occur at exactly the same location on every computer screen every time a document is viewed. Similarly, if a handwritten signature must always appear at the same location, HTML cannot be used reliably.

Adobe Acrobat's Portable Document Format (pdf) addresses this lack of precision of presentation. A document created in pdf will be identical in appearance, regardless of which computer monitor or printer is used to render it. Page breaks, margins, fonts, and even the placement of graphics will be the same as in the original document. While Adobe has announced that it has incorporated new accessibility features in the latest version of Acrobat (the program used for creating pdf documents), the process of making content accessible with pdf is not well-understood. To view a pdf document, a web browser must have the Adobe Acrobat Reader plug-in installed on the computer. Thus, whether a web page containing a pdf file complies with the Access Board’s Section 508 Standards depends on the accessibility of the plug-in. However, designing pdf content that is easily usable by users with disabilities requires some expertise with the Adobe Acrobat program. As the availability of an accessible plug-in is not within the control of the agencies, our survey focused on the number of web pages that included pdf files and whether those files were designed in a way that maximized usability by persons with disabilities.

Recently, Adobe Systems Incorporated, the makers of Adobe Acrobat, released version 5.0 of Acrobat and announced that it included many new features to overcome the previous accessibility problems of Acrobat files. Since then, many agencies have reported good results >using assistive technology with pdf documents created using Acrobat 5.0. ³² We recommend that all agencies interested in using Acrobat 5.0 to create pdf files take special care to ensure that their pdf documents are created properly. This need is particularly important because pdf files are commonly used to memorialize important federal agency documents and thus tend to persist for a very long time on agency web sites. Specifically, we recommend that all agencies take the following steps when using pdf files:

• Ensure that all documents are created using Acrobat 5.0 or later versions of Acrobat.
• Ensure that all personnel responsible for the creation of pdf files are familiar with Adobe’s recommendations, How to Create Accessible Adobe PDF Files, available at http://access.adobe.com/booklet1.html
• Be aware that, in addition to following the general guidelines in the How to Create Accessible Adobe PDF Files booklet, agencies should also follow the recommendations in Appendix A: Troubleshooting section of the booklet when pdf files are password-protected, encrypted, or include complex layout, tables, or graphical images.
• Regularly consult with Adobe’s web page for accessibility at http://access.adobe.com for the latest recommendations and tips for improving the accessibility of pdf files.

The Department asked, “If the page includes links to pdf (Adobe Acrobat's portable document format) files, were those pdf files created in a way that is likely to maximize their usability for people with disabilities?” (Web Question 20)

• Of the 5,600 pages surveyed by the agencies, 1,752 pages (31.3%) included pdf files.

• While most of these web pages were created in a manner to maximize their usability (1,331 pages of 1,752 total pages or 76%), many were not.

• Pages that include pdf files are a large number of some of the most popular web pages, accounting for a total of 35,335,152 weekly hits of 211,257,848 total weekly hits (16.7%).

• In the subcategory of pages containing instructions for receipt of services or benefits, 617,849 weekly hits of a 3,175,447 total weekly hits (19.5%) were for pages that used inaccessible pdf files.

• In the subcategory of pages containing agency employment postings, 118,850 weekly hits of 933,614 total weekly hits (12.7%) were for pages that used inaccessible pdf files.

The data indicate that pdf files are widely used on federal agency web pages. Significantly, inaccessible pdf files are included on web pages supporting some of the most important functions of the agencies.

11. Electronic Forms (Web Questions 21 - 22)

Findings Non-HTML forms vary considerably and may be difficult to make accessible. Large numbers of agency forms are inaccessible to users with disabilities, particularly among those forms for receipt of services or benefits and other online forms. Many inaccessible online forms do not include links to accessible alternatives. Recommendations Agencies should ensure that web developers developing HTML forms are aware of how to use the <LABEL> tag to improve their accessibility. Agencies should closely monitor the work of the General Services Administration in the development of the accessible plug-in for converting paper forms to electronic format that is accessible to users with disabilities.

Online forms appear on many federal agency web pages. One of their most common applications allows agencies to collect information from users. Thus, in addition to distributing information, the Internet provides agencies with an incredible resource for collecting information, as well. Unlike their paper counterparts, these online forms can be processed easily and inexpensively. The data collected on the forms can be stored automatically in a searchable electronic database for instant retrieval. Another type of online form includes web page search engines. Search engines allow users to type their search requests into a box and submits them. The web server receives the information on the form - the search request - and uses it to process an appropriate response. In addition to search engines, more complex forms are used on many web sites. For instance, when shopping online, users may be asked to submit their names, addresses, credit card numbers, and other information. Even more complicated online forms duplicate the exact appearance of their paper counterparts, yet provide all of the benefits of digital technology described above.

There are two different types of forms: those created with simple HTML and those using other technologies. In order for an online form rendered in HTML (HTML form) to be accessible, each input element, whether it be a text box, radio button, submission button, or other element, must be laid out in a way that makes sense to those who use screen readers and other types of assistive technologies. The HTML form's instructions must also be presented in an easy-to-use manner. HTML forms are often inaccessible because the text label identifying a particular radio button or other screen element does not appear contiguous to the element it describes or because the construction of the form is complicated enough to make non-visual navigation difficult or impossible. Someone who uses a screen reader may not be able to discern which of the buttons or elements would be an appropriate selection.

Tip Careful use of the <LABEL> tag in HTML forms greatly improves their accessibility.

The Department’s survey indicated that careful layout was the key to creating accessible HTML forms. In addition, agencies were recommended to have users with disabilities test the accessibility of their forms. Since then, however, the Department has worked closely with the Access Board and the Department of Education to yield straightforward recommendations for making online forms accessible. Each part of an online form can usually be reduced to a single tag within a <FORM> tag. For instance, the following stripped-down code displays a familiar text box for entering a user’s last name:

<FORM>
last name: <INPUT type=”text” name=”lname”>
</FORM>


The easiest way to make this form accessible is to simply modify it using <LABEL> tags and an id attribute. The revised code (with changes marked in bold) is simply:

<FORM>
<LABEL for=”1”>last name:</LABEL>
<INPUT type=”text” name=”lname” id=”1”>
</FORM>


Simply including a <LABEL> tag in HTML forms dramatically increased the usability of HTML forms for users with disabilities. In this example, using the label tag associates the words “last name:” with the actual text box for entering the last name — almost without regard to the ultimate layout of the page. Thus, it also allows developers to create extremely complicated forms in tables and columns, while ensuring that users with disabilities can adequately use the form. ³³

In addition to HTML forms, web developers can also create online forms using non-HTML technologies. As noted above, one significant limitation of HTML is that it does not easily provide extremely precise page layout. Thus, a number of other types of online forms have been developed to overcome the limited control HTML allows over page layout. HTML forms cannot be used where an online form is required to look exactly like its paper counterpart, as the appearance of HTML forms will vary slightly depending upon the user's computer hardware and software. Non-HTML forms designed to be completed and submitted online are used with plug-ins or special third-party software. ³⁴ Because non-HTML forms can use a variety of different technologies, specific guidance for all non-HTML form technology is currently unavailable.

Promising Development: Accessible Forms Project by the General Services Administration Recognizing that paper forms are an extremely inefficient way of conducting the government’s work, the General Services Administration sponsored the development of an electronic forms project. The goal was twofold. It sought to reduce paperwork by developing an electronic means for users to enter information and have that information instantly populate a database. This approach meant that government could be more responsive to the needs of a demanding public while reducing overhead and eliminating user error. It also was expected to eliminate many of the barriers for users with disabilities that currently exist with respect to electronic forms. With funding of only $275,000, the project was technically successful and, for the first time, made it very easy to make paper-based forms accessible to users with disabilities. Although it could not ultimately be publicly deployed for contractual reasons, this project demonstrated the potential promise of small investments in accessible technology. This kind of technology could eliminate most or all of the problems faced by users with disabilities using electronic forms. In addition, because it uses plug-in technology that lets users fill in a computer image of the paper-based form, it is more usable by people without disabilities. It would also be potentially easier to implement because the electronic forms are based on paper forms and could be scanned in once and quickly created.

Subsection 1194.22(n) of the Access Board’s technical provisions provides, “When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.” 36 C.F.R. §1194.22(n)

In Web Question 21, the Department asked, “If the page includes one or more electronic forms that is designed for completion online, does each form permit users of assistive technology to access the information, field elements, and functionality required for completion and submission of the form including all directions and cues?” (Web Question 21).

• Of the 5,600 pages surveyed by the agencies, 738 (13.2%) included forms.
• Only 167 (3.0% of the total pages; 22.6% of pages containing forms) of these pages included inaccessible forms.
• In the subcategory of “online forms for the receipt of services or benefits,” 311,646 weekly hits of 804,760 total weekly hits (38.7%) involved pages containing inaccessible forms.
• In the subcategory of “other online forms,” 426,841 weekly hits of 1,121,232 total weekly hits (38.1%) involved pages containing inaccessible forms.

Almost 25 percent of the online forms on popular federal agency web sites are inaccessible to people with disabilities. The subcategories of “online forms for the receipt of services or benefits” and “other online forms” have a significant percentage of inaccessible forms.

In Web Question 22, the Department asked, “If the page contains one or more forms that is designed to be completed online but that is inaccessible to people with disabilities in some respect, does the page include an alternate accessible form or a link to an alternate accessible form?” (Web Question 22).

• Of the 320 forms that agencies identified as including inaccessible forms, only 83 pages (25.9%) included alternative accessible forms or links to accessible forms. ³⁵
• The remaining 237 pages containing inaccessible forms (74.1%) did not have any accessible equivalent.
• In the subcategory of “online forms for receipt of services of benefits,” 14 of 50 (28%) pages containing inaccessible forms did not include any accessible alternative. The weighted data reflects that 338,809 weekly hits out of 804,760 total weekly hits (41.5%) in this subcategory were recorded for those web pages that included no alternative accessible forms or links to accessible forms.
• In the subcategory of “other online forms,” 333,809 weekly hits of 1,121,232 total weekly hits (42.6%) were for pages that contained inaccessible forms and did not include any accessible alternative.

The data suggest that online forms pose significant barriers to accessibility on popular federal agency web pages.

Many of the problems arising from inaccessible non-HTML forms may soon become a historical footnote when technologies similar to the accessible forms project of the General Services Administration become widely available. The Department believes that this work is an excellent example of how responsible funding of small businesses may help solve both the problems confronting federal agencies and users with disabilities. This solution also illustrates how accessibility has significant benefits, including reducing government paperwork and increasing government efficiency, in addition to helping users with disabilities. But, inaccessible forms are only one of several technological problems that federal agencies face in these early years of implementing section 508. The Department believes that additional carefully-targeted funding of promising accessibility practices should be made by federal agencies. Ultimately, the benefits will inure to users with disabilities and to our society as a whole. ³⁶

12. Skipping Repetitive Navigational Links (Web Question 23)

Tip Many agency web pages fail to include links to skip repetitive navigational links.

Web developers routinely place a host of repeated navigational links at a standard location often across the top, bottom, or side of a page. If a non-disabled visitor returns to a web page or site and knows that he or she wants to view the contents of that particular page instead of selecting a navigation link to go to another page, he or she may simply look past the links and begin reading wherever the desired text is located. Users of screen readers or other types of assistive technologies, however, are not as fortunate; it can be a tedious and time-consuming chore to wait for the assistive technology to work through and announce each of the standard navigational links before reaching the actual contents of the page. ³⁷ Subsection 1194.22(o) of the Access Board’s technical provisions addresses this issue and states, “A method shall be provided that permits users to skip repetitive navigation links.” 36 C.F.R. §1194.22(o).

Tip Creating a link to skip navigational links involves simply creating an anchor link, using either text or image, to jump to the main content.

Normally, skipping repetitious links involves nothing more than inserting a link at the beginning of the navigational links. In HTML, creating such a link is very easy. First, at the beginning of the main content of the page, the developer inserts an anchor by inserting the following code:

<A name=”content”>

Inserting this tag after the listing of the navigational link creates an invisible marker that has no effect on the presentation to the browser. Then, the web developer inserts one of the following two links immediately before the listing of links:

<A href=”#content”>Skip Navigational Links</A>

Or:

<A href=”#content”><IMG src=”clear.gif” alt=”skip links” height=”1" width=”1"></A>

Using the first line of code places only the words “Skip Navigational Links” immediately before the listing of navigational links. When the user selects this link, he or she will jump immediately to the main content for the page. The second example uses an image (clear.gif) as the basis for the link. In this case, the image should be a very small transparent image (a so-called ”transparent gif”). The height and width attributes further ensure that the image is small— here, only 1 pixel by 1 pixel. As discussed above, the alt attribute makes this image readable to a screen reader, but it remains invisible to the visual browser. This kind of link can be inserted into a web page without affecting the layout of the page at all. Therefore, even web developers highly focused on compelling graphic design can add a “skip navigational links” link without interfering with the layout of their pages.

The Department asked, “If the page includes navigational links to other web pages within the same web site, is there a link allowing users of screen readers to skip over those links?” (Web Question 23).

• Three thousand (3,000) of the 5,600 web pages surveyed by the agencies (53.6%) do not include a link for skipping repetitive navigational links.

This figure may be greatly overstated. Web Question 23 of the survey asked about links to skip over navigational links in the web pages— not repetitive navigational links as identified by the Section 508 Standards as being problematic. Because many agency web designers recognize the value of repetitious links, however, it is likely that most of the popular agency web pages include repeated navigational links.

13. Timed Responses (Web Question 24)

Finding Very few agency web pages include a time-out feature and most of these pages do not include a feature allowing a user to request additional time

For security reasons, some web pages are designed to "time out" automatically if a user does not take some action within a prescribed time period. For instance, commercial online banking services commonly use this technique to make sure that their customers do not leave sensitive financial information on their computer screens where others may view or tamper with that information. Pages that require users to navigate or negotiate elements within a fixed amount of time can present challenges to some people with disabilities. For instance, someone with extremely low vision may be a slower-than-average reader. A page may "time out" before he or she is able to finish reading it. Likewise, people with disabilities may require additional time to complete a form. When forms "time out" automatically, whatever data has been entered is deleted automatically. The result is that someone with a disability who is slow to enter data cannot complete the form.

Subsection 1194.22(p) of the Access Board’s technical provisions states, “When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.” 36 C.F.R. §1194.22(p).

The Department asked, “If the page requires users to respond within a fixed amount of time before the user is "timed out," is the user alerted that he or she will be timed out and given sufficient time to indicate that more time is required before actually being timed out?” (Web Question 24).

• Of the 5,600 web pages surveyed by the agencies, only 95 (1.7%) had a time out feature.

• Of these pages, 75 (78.9%) provided no features to give users additional time.

Few of the agency web pages surveyed by the agencies included time out features. Based on the extremely small sample size from the data, however, it is impossible to estimate the impact that such pages have on users with disabilities.

14. Text-Only Pages (Web Question 25)

Finding Where agencies have inaccessible web pages, they generally do not provide accessible alternative pages.

If a “mainstream” web page is inaccessible to people with disabilities and cannot be made accessible, the Access Board's Section 508 Standards require that the agency maintain an equivalent text-only web page. Subsection 1194.22(k) of the Access Board’s technical provisions states, “A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.” 36 C.F.R. §1194.22(k). Text-only alternatives to inaccessible pages allow people with disabilities to have full access to all information available to others.

The requirement that inaccessible web pages are permitted only “when compliance cannot be accomplished in any other way” reflects the practical reality that “text only” web pages are usually not updated as frequently as “mainstream” pages, thus providing users with disabilities outdated content that can often be misleading or confusing.

The Department asked, “Taking into consideration your responses to the previous questions, if the reviewed page likely contains barriers to access for people with disabilities, do you have an alternative text-only page that contains the same information and is updated as often as the reviewed page?” (Web Question 25).

• In most cases (3,926 of 5,600 pages or 70.1%), the components stated that their main page was not inaccessible.
• In some cases (518 or 13.2%), components provided a text-only web page even though the web page was reported as not creating barriers for users with disabilities.
• In those cases where components believed that their web pages created barriers for users with disabilities (1,674 pages out of 5,600 total pages or 29.9%), they indicated that current text-only pages with identical content was provided only with respect to 395 pages (23.6%).
• Of the 1,674 pages where components believed that their web pages created barriers for users with disabilities, outdated text-only pages were provided in 62 pages (3.7%), and no alternative text-only pages were provided in 1,217 instances (72.7%).
• In the subcategory of “online form for receipt of services or benefits,” components recorded a total of 804,760 total weekly hits. Of these pages, pages accounting for 682,228 weekly hits (84.8%) were identified as containing barriers. No alternative page was provided for pages totally 675,701 weekly hits (99% of inaccessible pages or 84% of weekly hits for all such pages).

Even where agencies have identified barriers to accessibility, relatively few provide accessible alternative pages. The most prevalent problem appears to be with respect to online forms.

C. Key Recommendations

The discussion above analyzes existing practices and the accessibility of agency web content. It also includes many findings and recommendations. The most important of these recommendations are summarized below.

1. The Access Board should coordinate an interagency effort for the development of model accessibility technical assistance that provide more detail than is offered by the Standards’ technical provisions, especially with respect to emerging technologies.

2. All agencies should continually update their web accessibility guidelines to ensure conformance with the latest guidance from the Access Board.

3. All agencies should develop strict internal control mechanisms to ensure that agency web accessibility guidelines are followed.

4. All agencies should provide information to assist users with disabilities (including plans for improving accessibility and remediating existing web pages) and should provide an e-mail address for reporting accessibility problems or seeking information in an accessible format. In addition to providing the information requested in a usable format, agencies should endeavor to make these pages accessible where possible.

5. Congress should authorize and fund challenge grants to industry or the research community to encourage the development of accessible cutting-edge technologies.