Federal Agencies' Web Pages(1)

The Internet has become enormously popular within the last decade. People now use the World Wide Web to find information, order books, and even buy their groceries. Most likely, this trend of information and commerce becoming increasingly "online" will continue for years to come. We have also witnessed the "look and feel" of the Internet changing dramatically within recent years. At first, the Internet provided minimal content--- mostly text and only an occasional picture. Then, interactive forms, "real-time" storm tracking weather maps, and audio recordings of historical speeches became available. With each passing day, the content of the Internet becomes richer.

Many of these changes make it easier for people with disabilities to apply for government jobs, pay taxes, apply for services or benefits, and take advantage of the huge amount of Federal Government information that is now online. Others do not.

Like the private sector, federal agencies have seized upon the Internet as a low-cost way of making its goods and services available to a wide audience. According to the Department of the Treasury, the Web site for the Internal Revenue Service is visited by over a million taxpayers each year. The National Aeronautics and Space Administration, an agency which has captured the imagination and dreams of so many Americans, now uses the Internet to reach and inspire a new generation of scientists and explorers. Given the relatively low cost of publishing information on the Internet, agencies now reach many more people at much lower cost than previous thought imaginable. The Internet will undoubtedly continue to grow as way of disseminating information to the public and to federal employees.

At the same time, making federal agencies' Web sites accessible to persons with disabilities is extremely easy and cost-effective. Persons with disabilities have historically been segregated and denied opportunities that nondisabled people take for granted. The Internet now provides an opportunity to fulfill the promise of including all Americans in this new information age.

For many agencies, the section 508 self-evaluation was the first time they focused on accessibility of their Web sites to people with disabilities. Agencies met this new challenge with enthusiasm, honestly evaluating the strengths and weaknesses of their Web pages and developing strategies for making this resource more accessible to everyone. Agencies reported on strategies that they used to make their Web sites more accessible and recommended others. The responses reflect a panoramic view of how different agencies -- some with only five employees and others with hundreds of thousands of employees or more -- met the challenge of accessibility.

Different communities of people with disabilities experience different barriers to access when using federal agencies' Web pages:

Generally, removal of barriers on federal agencies' Web sites is simply a matter of good design. It also benefits others, such as those who use low-end technology with lower modem speeds and people who use wireless Internet connections.

The Evaluation Tools

To evaluate the level of accessibility of Internet and intranet pages of federal agencies to persons with disabilities, each component was asked to evaluate 20 of its most popular(2) Web pages both objectively and subjectively. The objective evaluation tool was the "Web Page Accessibility Checklist" developed by the Department of Justice for this survey. The subjective element required evaluators to download and use Lynx, a text-based Web browser used by many people who are blind or who have low vision, to "experience" the Web page in the same manner that it would be experienced by someone who used a screen reader.

For each of its 20 most popular Web pages, the component was instructed to identify the page as follows:

Components were then instructed to evaluate each page using both the objective and subjective evaluation tools.

I. Objective Survey Tool: The "Web Page Accessibility Checklist."

The Department of Justice's "Web Page Accessibility Checklist" was based on the work of the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C).(3)

This resource formed the basis for our questions because of the current absence of accessibility standards for federal agencies' Web pages. The WAI works with other organizations for the development of Web accessibility standards (including guidelines for page authoring) and educates, researches, and develops Web accessibility standards.

As with the other "Accessibility Checklists" developed by the Department of Justice for the Section 508 Self-Evaluation, each question is phrased so that an affirmative response (a "yes" answer) indicates a greater decree of accessibility for persons with disabilities than a negative response (a "no" answer).(4)

For discussion purposes, specific questions from the Department's Web Page Accessibility Checklist are categorized as follows:(5)

A. Making visual information accessible through text or audio.

With the continuing evolution of the Internet, Web pages are providing more information for users. Although most of the content of the Internet originally included only plain text, Web pages now include graphic images.

Questions 1-8 of the Department's Web Page Accessibility Checklist are designed to measure whether text equivalents are provided for visual, non-text content (images, video, etc.).(6) As explained in the WAI Guidelines, providing text equivalency of non-text content is of paramount importance in making Web pages accessible to many types of persons with disabilities:

Text can be readily output to speech synthesizers and Braille displays, and can be presented visually (in a variety of sizes) on computer displays and paper. Synthesized speech is critical for individuals who are blind and for many people with reading difficulties that often accompany cognitive disabilities, learning disabilities, and deafness. Braille is essential for individuals who are both deaf and blind, as well as many individuals whose only sensory disability is blindness.

WAI Guidelines.

1. For all images, is alternative text provided? Note: This includes images used as spacers, bullets in lists, and links.

This question was asked first because of its paramount importance in providing access to persons with disabilities and the overwhelming ease with which images can be designed to be accompanied by text: it is both important and simple to do. Additionally, Web designers can write Web pages so that the alternative text is not displayed on the screen -- yet is available to screen readers and other assistive technology. This design feature allows Web designers to maintain a clean look while achieving a high degree of accessibility.

To give some idea of the simplicity of creating such alternative text, below is a familiar Web page that includes an image (Figure 1).

image of Bill Lann Lee Biographical Web Page

In writing the Web page that appears as Fig. 1, the Web designer must include a "link" to the image. That link is written as:

<IMG SRC="blee3.jpg" border=0>

Rewriting the Fig. 1 link to include alternative text involves nothing more than simply adding the boldfaced language:

<IMG SRC="blee3.jpg" border=0 ALT="Photograph of Bill Lann Lee">

This simple change is all that is required to make this image understandable to persons using a screen reader or Braille display. A blind person would then encounter the words "Photograph of Bill Lann Lee" (which would be read by his or her screen reader), and would know that the graphic was a photograph of Bill Lann Lee instead of a map of the United States or other graphic content.

Nevertheless, a large number of federal agencies' Web pages do not incorporate this simple change. Of the 3,028 total number of Web page surveyed, 881 -- or almost one-third -- do not include alternative text for their images. See Table 1.(7)

Most components whose self-evaluations revealed that they do not routinely include text alternatives for images have generally noted in their overall evaluations that they will change their policies and will begin to provide text alternatives on a regular basis.

2. For all applets, are alternative text and content provided?

An applet is a small computer program that is automatically downloaded through the Internet and run on the user's machine when the user visits a Web page that includes an applet. Because applets actually operate on a user's machine, they often make Web pages "feel alive" because a user doesn't have to wait for information to be transmitted back and forth across the Internet.(8) As these applets may provide video or audio output (or both), it is important that users with sensory disabilities have access to alternative text and content for this information, for the same reasons that they need access to alternative text to images. If a text description of an applet is too long to be integrated within the limited space available, an agency Web designer can set up a separate page and put a text link to this page next to the inaccessible applet.

An example of the appropriate use of alternative text to provide access to the contents of an applet appears on the Office of Personnel Management's home page (http://www.opm.gov). For users who are running Java-compatible browsers (i.e., Netscape Navigator with Java turned "on"), an applet runs near the top of the OPM page, appearing like a box containing scrolling headlines, along with the instruction "Click on the headline for the full story." Users who are not running Java will get a different screen that lists all of the headlines at one time, with the same instruction. This alternative screen is rendered in text and is accessible to those who use screen readers.

Components indicated that relatively few of the federal Internet pages contain applets, and the Department believes that the actual number is even lower. Of the 592 Web pages identified as containing applets,(9) components indicated that a relatively high number of them ­ 228 ­ do not include alternative text and content. In reviewing these Web pages, however, the Department found that few actually contain applets.(10) Thus, it is difficult to draw meaningful conclusions whether components using applets on their Web pages are ensuring that the information contained within them is accessible to all persons.

Given that there appears to be little current use of applets in federal Web pages, only a small amount of redesigning would be necessary to ensure that all currently-used applets are made accessible.

3. For all image map links, is alternative text provided?

4. If server-side image maps were used, are text links provided for each hotspot in the image map?

Many Web sites now incorporate image maps as a quick means of navigating within a site. The following Web page from the Office of Personnel Management (OPM) provides links to information about federal employee health benefits, broken down by state (Figure 2).

OPM Image Map of US

Although the geographical map used in Fig. 2 contains standard 2-letter abbreviations for each state, they are unreadable to screen readers and Braille displays because they are rendered graphically instead of with text. The Web designer, however, has chosen an easy way of making Fig. 2 fully accessible by providing a list of states -- in text format -- under the geographical map, where the name of each state would be the same link as is activated if the user were to "click" on the state in the map. Users of screen readers can bypass the inaccessible geographical map and select their states from the text list, thus proceeding to pages explaining health benefits in their area.

Another example of an image map is shown in Fig. 3, a graphic image of an automobile dashboard used by the National Highway Traffic Safety Administration (NHTSA).(11) Although not a traditional map like the one used by OPM in Fig. 2, the dashboard image is an "image map" because it permits users to choose different options by clicking on different portions of the image. The computer keeps track or "maps" where the cursor is located on the image ­ the location where the user ultimately hits the mouse button will determine the choice made by the user.

Image of NHTSA dashboard

Image maps are further broken down into two sub-categories. Server-side image maps track the exact coordinates where a user is pointing on an image. When the user click on a region in the map, only the map coordinates are sent back over the Internet. The server-side computer that generates the Web pages then has to calculate a response based on those coordinates. Since the coordinates are sent back over the Internet, alternative text cannot be used to provide accessibility because the user's computer is only aware of the coordinates, not the meaning assigned to those coordinates. Only the server-side computer that generates the Web pages can identify what those coordinates mean. Because alternative text cannot be used for server-side image maps, a separate listing of each of the "hotspots" of the map should be provided to ensure accessibility.

The second category of image maps are client-side image maps. For client-side image maps, the user's computer converts the coordinates of the mouse location into the "region" that the user is pointing towards. This region can then have its own alternative text. For instance, if a user is pointing at the state of Utah, the user's computer has identified that the user is pointing at a region called "Utah." Because the user's computer is "aware" of the different regions (as opposed to just the coordinates), alternative text can be provided. As long as the Web designer provides such alternative text, a separate listing of each "hotspot" of the map is not required for accessibility (although providing such a listing may provide even greater accessibility).

The self-evaluation responses to Question 3 revealed that of the 3,028 Web pages evaluated, 978 pages (32.3%) had image maps for which alternative text was provided, while 321 pages (10.6%) had image maps where alternative text was not provided. See Tables 2 and 4.

The responses to Question 4 indicated that 21.6% of the pages evaluated had server-side image maps, approximately two-thirds of which had text links provided for each hotspot in the image map (451), while one-third did not (203). See Tables 3 and 4.

5. For all graphical buttons, is alternative text provided?

Ordinarily, Web pages use buttons that have plain text associated with them. For instance, Fig. 4 shows a Web page that uses a non-graphical button with the text "submit:"

Image of non-graphical page

Many Web designers, however, consider plain-text "submit" buttons like the one used in Fig. 4 too unimaginative. To make their buttons appear more artistic, Web designers may use graphic images to create "graphical buttons," (Fig. 5):

Image of graphical page

In Fig. 5, the "search" button is actually an image, just like the photograph of Bill Lann Lee in Fig. 1. Similarly, the search button image in Fig. 5 is inaccessible to someone using a screen reader; thus the search function is inaccessible unless meaningful text is associated with the search button image. As before, the simple solution -- used here by the Department of Justice -- involves including alternative text (boldface text below) in the link to the image:

<input type=image src="../navimages/search.gif" width=116 height=22 border=0 alt="Search">

Most federal Web pages that were evaluated contain graphical buttons (71.9%). Unfortunately, a significant portion of these (352 of 2,177) contain graphical buttons that do not have meaningful text associated with them. See Table 5. Missing alternative text means that not only those buttons, but the functions they activate, are inaccessible to many people with disabilities.

6. Is there an absence of ASCII art, and, instead, are images and alternative text used?

So-called "ASCII" art refers to text characters and symbols that are combined to create a graphic image. A simple example is the smiling face "emoticon" :-). More complicated examples may include graphs or logos. For instance, the graph in Fig. 6 would be considered "ASCII art" and not a graphic image, because its "image" is actually comprised of plain keyboard characters:

Image of sample ASCII art graph

ASCII art presents several barriers to accessibility and should not be used where images and alternative text can be used instead.(12) First, because ASCII art is comprised of ordinary typographic characters that have meaning only based on their relative spacing near other characters, its meaning or purpose is unintelligible to users of screen readers or refreshable Braille displays. For instance, people who use screen readers and who come across the "smiling face" ASCII art would hear -- in synthesized speech -- "colon," "hyphen," "close paren," "period."

Second, because ASCII art often uses a large number of characters, it significantly delays the speed with which users of screen readers and Braille can negotiate Web pages. In more complex instances, such as the one shown in Fig. 6, it can take an extremely long time to parse through the ASCII art to get to the rest of the page's content. Since the person using a screen reader or refreshable Braille display is presented information one character at a time, he or she cannot easily "glance ahead" to see where the ASCII art starts and stops: much like a person listening to a recorded lecture on an audiotape, the only way to skip a particular section and get to something more meaningful or relevant is by trial and error, and repeatedly rewinding or fast forwarding until the desired portion of tape is located.

Of the 3,028 Web pages reviewed by components, only 156 pages reportedly contain ASCII art instead of images and alternative text. The Department's spot-check found that few of these 156 pages actually contained ASCII art. This relatively low use is consistent with an overall trend against using ASCII art as technologies make it easier to use more sophisticated graphics. Due to low usage, therefore, accessibility problems relating to ASCII art are likely to be minimal.

7. If OBJECT was used to incorporate an image, applet, or script into a page, is the information also conveyed in an alternative means in cases where the OBJECT cannot be perceived, such as with "title" or within the body of the OBJECT element?

As Web page design has evolved, Web designers have started to include images, applets, video clips, and programmatic elements into their pages. These features have made possible the introduction of multimedia and interactive elements into Web pages. To give Web designers flexibility in using new and evolving features in their pages, the "object" attribute was adopted as a "catch-all" means of referencing almost any script, image, applet, or multimedia source. For instance, OBJECT can be used to refer to a photograph that will then appear on a Web page at the desired location or OBJECT can be used to create a link to an applet that generates sound. To make these accessible to a wide variety of people with disabilities, however, meaningful alternative text must be associated with the OBJECT tag.

Few federal agencies' Web pages currently contain OBJECT tags. Although 170 of the 3,028 Web pages which components answered "no"to the question of whether alternative text or other means were used to convey the meaning of an OBJECT, a brief review of these Web pages indicates that few, if any, of these Web pages actually included OBJECT at all. Components indicated that the overwhelming percentage of Web pages (84%) did not include OBJECT (answering "not applicable"). Only 325 pages (11%) were identified as using OBJECT and making it accessible through alternative text or other means.

In terms of consequences for the overall accessibility of federal agencies' Web sites, if these sites grow in sophistication, as they are expected to do, more of them will incorporate images, applets, or scripts by using OBJECT. It will be important for those who design and maintain such pages to make these features accessible, through alternative text or other means. Currently, however, OBJECT is used only rarely. Inaccessible instances of its use are likely to be encountered currently only occasionally by people with disabilities.

8. Are long descriptions provided of all graphics that convey important information?

To do so: use "longdesc."

Until most browsers support "longdesc," also use a d-link (description link) or invisible d-link.

Graphics that convey complicated, difficult, or important information often cannot be explained without a lengthy description. Unfortunately, information about an image that is conveyed through an "alt" tag is usually limited to a short title of the graphic image. To convey more complicated or lengthy information, an entire page of text may be required. If a graphic image includes a color map of a metropolitan subway system, the image itself may provide enough information to allow a nondisabled visitor to understand how to travel between stations. Describing the same information without the assistance of a graphic image, however, may a longer narrative describing the different subway lines. If this information is too long to fit on the same page as the graphic, a Web page designer can use a description link ("longdesc") to create a link to a separate Web page on which the longer narrative would appear. Without such links, the information in the graphic image cannot be understood by users who cannot see or interpret graphics. Also, if information in the image is conveyed through the use of colors, then a descriptive link may assist people with color blindness.

With respect to 1,839 of the 3,028 (60%) Web pages reviewed in this survey, federal components answered "Not applicable" when posed the question of whether long descriptions were provided of all graphics that convey important information, likely indicating that these pages did not contain graphics that conveyed important information. Components indicated that 412 pages did appropriately include long descriptions under this circumstance, while 777 did not.

In other words, more than 25% of the federal Web pages surveyed contained inaccessible graphics that do not have long descriptions of their content. This routine use of inaccessible graphics is likely to have a substantial impact on the overall accessibility of federal agencies' Web sites. See Table 6.

12. For short animations such as animated "gifs" images, are alternative text and a long description provided, if needed?

Animated graphic image files (GIF's) and animations are typically image files that repeat or change from one image to the next. These animations can comprise either drawn images (as in cartoons) or photographic images. They usually do not include an audio component. Providing either alternative text or a long description is essential to making them accessible to persons who cannot see the animation. Only 15% of the Web pages surveyed contained GIF's, one-third of which were not accompanied by alternative text or long descriptions. See Table 7.

13. For movies, are auditory descriptions provided and synchronized with the original audio?

Unlike most animations and animated GIF's, movies have both visual and audio components. For the user to fully appreciate the content of the presentation, the audio component of a movie is synchronized with the visual component. In a television or movie theater movie, a character's speech is synchronized with the movement of their lips and gestures and a car's screeching tire is synchronized with the moving image of a car speeding away. Therefore, while a blind user may be able to hear the sounds of a movie, he or she may be unable to fully understand the content of the movie unless the video component is conveyed in an accessible manner. An auditory description is typically a description in human or synthesized voice of the key visual elements of a movie or other multimedia presentation and may include information about actions, body language, gestures, and scene changes. These auditory descriptions greatly benefit users who cannot see the presentation. Approximately 7% of the Web pages surveyed reportedly contain video clips. Of those, half were accessible while half were not. See Table 7.

B. Making audible elements accessible.

Although images may constitute the largest proportion of non-text content on Internet Web pages, sound files are becoming increasingly common. This trend reflects the increasing sophistication of computers (which now provide rich multimedia output) and developing standards for audible content on the Internet.

9. For stand-alone audio files, are textual transcripts of all words spoken or sung as well as all significant sounds provided?

In addition to containing images, Web pages can also include audio files. These audio files are sound recordings that will play on a user's computer when the user hits an icon or clicks on a link. Important sounds (such as spoken or sung words) can be made accessible through a text transcript or caption. In addition to people who are deaf or hard of hearing, transcripts and captions can assist people who have certain language, learning, or cognitive disabilities.

Only 190 of 3,028 surveyed Web pages contain audio clips. A majority of these (111) contain textual transcripts for stand-along audio files and significant sounds, while 79 do not. See Table 9.

10. For audio associated with video, are captions -- textual transcripts of dialogue and sounds -- synchronized with the video?

Although Web pages originally conveyed only graphic and textual information, technological changes have permitted Web site developers to incorporate multimedia content -- such as movies with sound -- directly into Web pages. Manufacturers of computer equipment and software are increasingly using these multimedia presentations on their Web pages to provide technical assistance or sales information about their products. However, having sound synchronized with video output is essential for these presentations. Moreover, a multimedia presentation describing how to connect a telephone line to a computer's internal modem may have a sound track that states, "now connect your telephone line to our computer's built-in modem connection." Simultaneously, the video presentation shows an actor's hand inserting a clear connector into an unmarked port on the back of the computer. In this case, having an audio description synchronized with a video presentation is critical to understanding both the location of the modem port on the computer and the orientation of the phone connector when inserting it into the computer. As useful as this multimedia presentation may be to most people, however, it is inaccessible to those who are deaf and can be a substantial impediment to persons who are hard of hearing. Multimedia presentations should include textual transcripts (i.e., captions) that are synchronized with the video presentation: a static plain text transcript may become unintelligible if it is not synchronized with the video presentation.

According to the survey, 166 of the 3,028 Web pages surveyed use audio associated with video, 77 of which do not have captions synchronized with video output. See Table 10.

11. Where sounds are played automatically, are visual notification and transcripts provided?

Many Web pages, particularly commercial Web pages, include audio or music files that are played automatically once a user loads that page into their browser. Although these sounds are often simply background music or other unessential audio materials, a Web page developer can also include valuable instructions or information as part of the audio file. Regardless of the importance of the audio output, however, a deaf user is not receiving the full benefits and information of the page without visual notification and text transcripts of the information provided.

Although components reported that 133 of 3,028 Web pages surveyed included sounds that are played automatically, and that more than half of these did not have visual notification and transcripts provided, a brief review of these Web pages indicates that few, if any, include sounds that are played automatically.

Using colors and contrast wisely.

In addition, poor color combinations can make it difficult or impossible for people with low vision to use. For someone with color blindness, it may be impossible to distinguish information that is conveyed only through the use of color. Proper contrast is also of critical importance for persons who have certain types of low vision, even those who are able to distinguish among colors may have difficulty using a Web page that has a very low contrast between its foreground and background colors. Additionally, some people with certain types of low vision -- such as macular degeneration -- are particularly sensitive to glare; high contrast color combinations may be difficult for them to read for a sustained period.

Fortunately, the issue is not as confusing for Web designers as it might appear. People with low vision can set personal color preferences on their operating systems. Web designers should ensure that their Web sites will not override the user's settings to make the sites accessible to users with low vision.

14. If color is used to convey information, is the information also clear from the markup and/or text? Hint: One way of testing this is to ask yourself whether the information is available if one is viewing it on a black and white screen.

15. Are foreground and background color combinations used that provide sufficient contrast when viewed by someone with color blindness or when viewed on a black and white screen?

Questions 14 and 15 address the Web site designer's use of color and the functionality created by using color.(13)

Question 14 asks whether color is used to convey information and, if so, whether associated text is being used to clarify the content of the features which utilize color. This question is of obvious importance to users who cannot differentiate between colors. A "no" answer to this question means that users with color blindness are being excluded. However, others such as those with no vision are also are excluded by this deficiency in Web site design because screen readers and Braille displays cannot discern and convey color differences unless they are labeled with text.

Although federal components responded "no" to Question 14 for 153 of the 3,028 Web pages surveyed, a review of these Web pages reveals that few, if any, such pages used color as the means of conveying information. Some or all of these 153 Web pages included the use of either color graphics or colored text, but none of the pages used color itself as a means of conveying information. Furthermore, none of the pages required the user to make such choices as, "click the red button" or "click the blue button." Instead, in all of the pages reviewed, components used color as a means of highlighting certain screen elements without assigning additional meaning to objects based on their color. Therefore, the survey results give a false impression that persons with color blindness would have difficulty with the 155 sites to which agencies responded "No." In reality, color coding does not represent a significant barrier for persons with color blindness to federal Web pages at this time.

Question 15 -- regarding contrast between foreground and background colors -- does not affects users who are blind, because different color combinations on a screen do not present a barrier to accessibility to those who use screen readers or Braille displays. However, where a user's visual perception cannot distinguish between different colors, using foreground and background colors that are of similar hue (e.g., those that are not easily distinguished on a black and white screen) can pose difficulties for him or her.

Federal components responded that 162 Web pages of the 3,028 did not provide sufficient contrast between foreground and background colors. Unlike the components' responses to Question 14, a spot check of these Web pages indicates that contrast between foreground and background colors may be a problem on at least some of them. See Table 11.

Minimizing distracting and harmful elements.

16. For auto-refreshing or timed response pages, is a second copy of the page provided where refresh only happens after a link has been selected (until user agents provide this ability themselves)?

17. Is the Web page free from any blinking or updating of the screen that causes flicker?

Questions 16 and 17 related to Guideline 7 of the WAI Guidelines, which states:

Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped.

The importance of these requirements is explained in the WAI Guidelines:

Some people with cognitive or visual disabilities are unable to read moving text quickly enough or at all. Movement can also cause such a distraction that the rest of the page becomes unreadable for people with cognitive disabilities. Screen readers are unable to read moving text. People with physical disabilities might not be able to move quickly or accurately enough to interact with moving objects.

Question 16 relates to the ability of users with cognitive impairments, learning disabilities, and some disabilities affecting manual dexterity to access two different kinds of Web pages:

Some users with physical disabilities may not have the manual dexterity or speed required to access a timed response page. Also, users with cognitive impairments or learning disabilities may not be able to comprehend material presented in a timed response page quickly enough to access the information before it is replaced by new information or a default screen.

Approximately 12% of the 3,028 Web pages surveyed (368 pages) reportedly contain auto-refreshing or timed-response features. Of these, 109 do not provide any alternative to these potentially inaccessible elements. See Table 12.

Question 17 asks whether the Web page is free from any blinking or updating of the screen that causes flicker. Checkpoint 7.1 of the WAI Guidelines explains the importance of this question:

People with photosensitive epilepsy can have seizures triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (like strobe lights).

Therefore, this question relates to the usability of a Web page by users with some types of visually-induced seizure disorders.

Only approximately 5% of federal Web pages that were surveyed contain elements that would cause computer monitors to blink or flicker. See Table 13.

E. Making the most of organizational elements.

18. Is a fallback page provided for pages that contain frames?

21. If frames are used, are titles provided so that users can keep track of frames by name?

Questions 18 and 21 ask related questions about the use of "frames." Frames are used to "divide up" portions of a Web page to allow each portion of the page to have separate functions. Also, when a page "refreshes" with new information, only certain frames get refreshed. The advantage to this technique is that less information is transmitted at one time -- thus improving the "speed" of the page, while simultaneously placing fewer demands on the server (the computer hardware creating and transmitting the Web pages to many different users). The Web page shown in Fig. 7 uses frames to create a separate portion of its page for commonly used functions or navigational links to other portions of its Web site:

Image of example frame based page

In this Web page, the names of U.S. Attorneys' Offices are listed on the left side of the screen. In a connected, but separate, window on the right side of the screen is text. When the user chooses one of the options on the left side of the screen, only the right portion of the screen changes and becomes filled with new content that reflects the user's choices. As is common with many documents including frames, different frames within the document have separate scroll bars that permit the user to scroll through the content of one frame without disturbing the viewable portion of the other frame.

While frames are useful as an organizational tool, they can present barriers to access for some people with disabilities. For instance, because each "frame" is a separate screen element, someone who cannot see the computer screen may not know which frame his or her screen reader or Braille display is reading from. Similarly, a person using screen enlargement software may encounter difficulties because of the layout of different frames on a screen. In addition, users with cognitive disabilities may have difficulty understanding the relationships between different frame elements.

Guideline 12 of the WAI Guidelines addresses this concern by stating that Web developers should "provide context and orientation information to help users understand complex pages or elements." As explained by the WAI Guidelines,

Grouping elements and providing contextual information about the relationships between elements can be useful for all users. Complex relationships between parts of a page may be difficult for people with cognitive disabilities and people with visual disabilities to interpret.

Therefore, a "no" answer to Question 21 significantly affects the usability of a Web page by blind or visually impaired users and users with cognitive disabilities.

Another issue is that frames often cannot be accessed by older browsers. Like much of the Internet, frames were developed to enhance the appearance and usability of Web sites. Older Web browsers that were developed before the advent of frames, however, cannot "read" frames. When read with older browsers, Web pages with frames appear in an incomprehensible format. Unfortunately, many older browsers (particularly, "text only" browsers such as the popular Lynx browser) work extremely well with screen reader and Braille displays used by people who are blind or who have cognitive impairments or learning disabilities. The WAI Guidelines recognized this problem by recommending that Web developers "ensure that pages are accessible even when newer technologies are not supported or are turned off." Question 18 targets this concern by asking whether Web developers have created "frameless" alternate pages to pages that contain frames. Therefore, a "no" answer to Question 18 indicates that the page is inaccessible to some blind users, especially if they are using an older browser. In addition, it may also indicate that the page is less accessible to users with cognitive disabilities.

Overall, over 10% of federal Web pages surveyed by components (310 of 3,028) included frames without a fallback page, compared with 11% of framed pages (333) that were accompanied by non-framed fallback pages. Just over 7% of Web pages (224 of 3,028) used frames yet did not provide titles, compared with over 14% of pages that had frames which were titled. See Table 14.

F. Using scripts and style sheets.

19. For scripts that present critical information or functions, is an alternative, equivalent presentation or mechanism provided?

20. For pages that use style sheets, are the contents of each page ordered and structured so that they read appropriately without the style sheet?

"Scripts" are used by an increasing number of Web page developers to provide greater functionality to Web pages or to improve their usefulness. Like an "applet," a script is a programmed set of instructions that is sent to a user's computer when he visits a Web page. However, unlike an applet, a script is not "compiled" (a process which makes running the instruction set much faster and more efficient). As a consequence, a script runs more slowly than an applet, but is much easier to write. A script usually resides only in the computer's memory and is used to perform basic functions for the user. For instance, a script can be used to make sure that the user entered correct data in a form (so-called "data validation") or to provide a quick "look-up" to compare submitted information with a small collection of information downloaded with the Web page. The advantage to using scripts is the perceived "speed" of the Web site--- because the information is already in the memory of the user's computer, an "extra trip" to the server isn't necessary for such simple tasks as data validation or look-ups. Scripts can also be used to improve the appearance and "coolness" of a Web site. A script can be used to make a graphic image transform into a different image when the user moves his or her mouse over the image (so-called "rollover gifs") and to create menus that pop up immediately when a user passes the mouse pointer over a button. Unfortunately, scripts also create a number of barriers to access because few of the functions are accessible to those who use screen readers or Braille displays. Therefore, without a means of providing alternative equivalent information or mechanisms that do not use scripts, the information or functions provided by scripts are not available to people who use these and other assistive technologies. Some scripts may also present barriers to users with manual dexterity problems. Scripts animating "rollover gifs" may require careful mouse placement to work and this level of dexterity may be impossible for some users with disabilities.

"Style sheets" are another recent development for the Internet. Style sheets are designed to simplify Web page design for Web page developers because they separate a page's "content" from its "form." Therefore, formatting instructions (such as indentations, fonts, table settings, and paragraph spacing) can be pre-defined and used by a number of separate Web pages on a Web site. In a nutshell, using style sheets makes it much easier for a Web page developer to create a consistent "look and feel" within a Web site and makes updating the site much easier. However, like scripts, style sheets also present barriers to access because only the newest browsers support style sheets. Assistive technologies such as screen readers and Braille displays are often more compatible with older browsers. Hence, the use of style sheets may create a page that is incomprehensible to visitors using browsers that do not support style sheets.(14)

Out of 3,028 Web pages surveyed, 271 did not include an equivalent alternative presentation for Web pages that used scripts. Furthermore, 112 Web pages could not be read appropriately if the user's computer did not support style sheets. See Table 15.

G. Providing text-only alternative pages.

Sometimes, with current technology, it is impossible or extremely difficult to make certain Web pages are fully accessible to users with disabilities. In these circumstances, a so-called "text only" page may be the only alternative for a Web site designer. The WAI Guidelines recognize this reality in the discussion accompanying WAI Guideline 11:

Content developers should only resort to alternative pages when other solutions fail because alternative pages are generally updated less often than "primary" pages. An out-of-date page may be as frustrating as one that is inaccessible since, in both cases, the information presented on the original page is unavailable. Automatically generating alternative pages may lead to more frequent updates, but content developers must still be careful to ensure that generated pages always make sense, and that users are able to navigate a site by following links on primary pages, alternative pages, or both. Before resorting to an alternative page, reconsider the design of the original page; making it accessible is likely to improve it for all users.

These concerns relate to all users with disabilities. However, most affected are users of screen readers and Braille displays, because text is easily converted into speech or Braille output. Questions 22, 23, and 24 relate to these concerns:

22. Do you provide a "text only" alternative page to the original page?

23. If you provide a "text only" alternative page, does it contain substantially the same information as the original page?

24. If you provide a "text only" alternative page, is it updated as often as the original page?

If a component was able to answer "yes" or "Not applicable" to Questions 1-21 for a particular Web page, all of the page's elements are presumably accessible and there is no need for an additional text-only page. Question 22 becomes much more relevant when one or more of the elements analyzed in Questions 1-21 is inaccessible.

Conversely, if text-only alternative pages are provided, they should be updated as often and contain the same information and links as the mainstream page. A "no" answer to either Question 23 or 24 indicates that some people with disabilities would be adversely affected. Federal components responding to Questions 23 and 24 indicated that less than 4% of Web pages surveyed (120 out of 3,028) included either problem identified in Questions 23 and 24. See Table 16.

II. The Subjective Survey Tool: Using a Text-Only Browser and Other Assistive Technologies to Test Web Pages for Accessibility

A. Overview of Subjective Analysis of Web Pages

The focus of agencies' self-evaluation of the accessibility of their Web pages was carried out through the objective format questions in the Web Accessibility Checklist. Question 25 of the Checklist, however, was a subjective-format question that asked the agencies to view each of their evaluated Web pages using a text-only browser. Using the text-only browser as an evaluation tool was intended to have agencies experience -- to some degree -- what a person using a screen reader or refreshable Braille display would experience when accessing those same Web pages. Specifically, Question 25 asked:

After you have evaluated this Web page using the Checklist, test it by running it with a text-only browser, such as Lynx, a public domain text browser that is available at http://lynx.browser.org. Describe the accessibility successes and problems you encountered during this exercise, including your plans for addressing any problems.

Many components chose to test their Web pages using utilities other than the public domain Lynx browser. Many used the interactive Web accessibility evaluation tool "BOBBY," which is provided and maintained free of charge by the Center for Applied Special Technology (CAST). Others evaluated their Web pages using IBM's Home Page Reader.

In addition, as part of their overall agency surveys, components were asked to subjectively evaluate the accessibility of their Web pages as a whole and describe any changes that they intended to implement to improve accessibility.

Of the 3,028 subjective Web responses provided to the Department, approximately 1,900 of them provided meaningful information. Thirty-two overall agency reports included useful information for making federal Web pages more accessible.

B. Findings

In general, most federal agencies' Web pages are generally accessible to users with disabilities; many others can be made accessible relatively easily. Nevertheless, some serious challenges remain for federal agencies in making their Web pages accessible. As more forms and interactive content are put online, agencies will have to maintain their vigilance regarding accessibility.

Overall subjective findings. In 7 of the 32 overall agency reports and 862 component Web page evaluations, the components reported that their Web pages were generally accessible to text browsers, but gave little or no analysis of any identified problems. In 18 of the overall agency reports and 229 Web page evaluations, components indicated that their pages were generally accessible when viewed with a text browser and that any existing problems could be easily remedied. One hundred thirty Web pages were reportedly created in a text-only format and did not pose any accessibility problems when evaluated with the text-only browser. By contrast, only 19 Web page evaluations -- and no overall agency reports -- indicated that pages were completely inaccessible when viewed with a text-only browser. Components identified specific accessibility problems in the remaining Web pages and, for the most part, indicated that they would fix the accessibility problems.

Alternative text. The most common problems identified by components were:

These problems were identified as major -- but easily remedied -- shortcomings in 5 overall agency reports and 203 Web page evaluations. A related problem involved links, where images used as links did not contain adequate alternate text labels. This problem was encountered in 51 individual Web page evaluations. A second related problem involves the use of image maps without alternate text to explain the various portions of the map. This problem occurred in 51 Web pages evaluated by components. These problems are very easy to fix. All components that identified these issues recognized the need to correct them quickly.

Tables. Many agencies' Web sites contain tables. Simple tables are used to improve page layout or convey simple information; larger tables are used to convey more complex information. As noted in the objective analysis section, large tables can be extremely confusing for people who use screen readers and refreshable Braille displays. Some newer browsers -- such as IBM's Home Page Reader -- do a better job of rendering tables in a way that is comprehensible to persons who use assistive technologies. One overall agency report and 68 individual Web page evaluations recognized this problem as a major accessibility problem with their Web pages. In most cases, components indicated that they would provide textual summaries of the information contained in inaccessible tables.

Frames. Another problem encountered by users with disabilities is components' use of frames. In 54 component evaluations, testers identified the use of frames and, in some cases, specifically noted that the use of frames made these Web pages completely unreadable or unusable with a text browser. A user may not be confronted with a page that is difficult to understand -- instead, the user is presented with a screen that may be completely blank. As a result of this survey, however, most components agreed to redesign their sites to address this problem. Agencies need not dispense with frames altogether, but they should provide pages that are comprehensible even when frames are turned off. That is, the easy solution is to provide a fall-back "no frames" option.

Other potential barriers. Four other common problems in Web page design were identified by the components. These included:

Each of these problems could make a Web page inaccessible to users with disabilities. In most cases, these problems can be solved by redesigning the Web page to add redundant, accessible features.

Text-only alternate pages. Some agencies believe that a more appropriate solution to ensuring the accessibility of their Internet pages involves creating text-only alternative Web sites specifically geared towards the needs of persons with disabilities. The final Access Board's Section 508 Standards may address whether providing text-only pages is an appropriate solution.

Inaccessible content. A more significant problem involves agencies' use of inaccessible content on their sites. An agency may create a Web page that is easily navigated by people using a text-only browser but then include downloadable files that are inherently inaccessible. This problem occurs most frequently with two types of file content used by many components ­ files rendered by scanning to Adobe Acrobat's portable document format (pdf) and multimedia files.

Adobe's Portable Document Format (pdf).(16) Many components mentioned in their evaluations that many of their Web pages included pdf files. Other agencies and components were more specific: 46 component evaluations and 3 overall agency reports noted that the presence of pdf files made certain pages useless to testers. In 24 other component evaluations and 3 agency reports, agencies also identified the accessibility problems created by pdf files and agreed to remedy these problems by including accessible content and, in some cases, removing pdf files from their Web sites. Other components, such as the Department of Justice's Civil Rights Division, frequently post pdf documents on their Web sites but routinely ensure that they are accompanied by accessible versions of the same document (usually in accessible HTML).(17) Other inaccessible formats in which some federal Web site information is presented include PowerPoint.(18) Adobe's pdf format, however, due to its sheer popularity, presents one of the most commonly-encountered and difficult obstacles for users with disabilities of federal Web pages.(19) A very high priority should be assigned to addressing this issue throughout federal agencies.(20)

Based on the information presented by Adobe and the Department of Education, agencies should refrain from posting files to their Web pages exclusively in pdf format. Agencies should accompany all pdf documents with accessible versions of the same document (i.e., in accessible HTML). Whenever possible, agencies using pdf are encouraged to use the "print" command rather than creating a pdf document by scanning it. If scanning is used, agencies are encouraged to use optical character recognition (OCR), where the document contains text.(21)

Multimedia files. Multimedia is another type of content that components have identified as causing accessibility problems. As technology has progressed, certain technologies for delivering multimedia content over the Internet have evolved to the point that individuals can download-- or play in "real time" -- multimedia movies. Although these file formats are extremely popular among commercial Web sites, they are relatively uncommon among federal agencies' Web sites. In fact, only 4 component evaluations and one overall agency evaluation noted the lack of audio descriptions in certain video files. Only 12 component evaluations and 2 overall agency reports noted the presence of inaccessible multimedia files.

Unlike pdf files, multimedia content is not simply an alternative to a paper document. Instead, multimedia pages include sound and synchronized video presentation. Therefore, in certain circumstances, it may not be possible to fully and accurately describe the content of such multimedia presentations through text. However, where agencies choose to use such presentations, they should endeavor to make them as accessible as possible.

Recommendations

To address making federal agencies' Web pages more accessible, the Department recommends the following:

1. Testing Web Pages Before Posting. Each agency should evaluate for accessibility all of its new Web pages before they are posted. Existing Web pages should be tested as they are updated. Testing should be done with text-only browsers and, where possible, with assistive technology such as screen reading software to ensure that the experience of users with disabilities is comparable to that of others.

2. Agency Web Guidelines. Each agency that has developed style guidelines to maintain a consistent "look and feel" of its Web pages should review those guidelines to ensure that they will maximize the accessibility of the agency's Web pages.

3. The Government Printing Office (GPO). Many smaller agencies rely on the GPO for their Web site design and maintenance. While section 508 does not apply to the GPO, the GPO should provide leadership to ensure that all Web pages it develops or maintains are accessible.

4. Dedicated E-mail Addresses. Because most accessibility problems on agency Web sites result from oversight or lack of awareness of accessibility issues, rather than technical or design difficulty, each agency should prominently post to its Internet pages an e-mail address through which users with disabilities can inform the agency of any accessibility barriers encountered. Each agency should be responsive to any e-mails it receives regarding the accessibility of its Web site to people with disabilities.

5. Accessibility Information Logo. The National Endowment for the Arts, along with the Universal Access Working Group, GSA, and the Access Board, should develop an easy-to-recognize accessibility information logo (and alternative text label). Each agency should use this logo (and text label) to link people with disabilities who use its Web pages with appropriate accessibility instructions and information, including an e-mail address to the agency's accessibility point-of-contact.

6. Location of Accessibility Information. Where it makes sense to do so, such as when placing a link to a text-only alternate Web site or when posting the accessibility instruction logo and label, each agency should place accessibility information in the uppermost left-hand corner of its Web pages. This location will facilitate use of the agency's Web pages by people who use screen readers, as it is the first location from which a screen reader will read.

7. Document Formats. As agencies put more of their programs and services online, each must remain vigilant to ensure it is not inadvertently creating barriers for people with disabilities. Online forms created using any of the various Web technologies pose significant accessibility challenges to Web designers. Documents rendered exclusively in Adobe's portable document format (pdf) or Microsoft's PowerPoint formats may raise particular concerns. If any posted documents or forms are less than fully accessible, each agency should also post ASCII or accessible HTML versions of the same documents, where possible. Where exclusive reliance on an inaccessible format is unavoidable, each agency should provide contact information where users with disabilities can request the underlying information in an accessible format, where doing so would not impose an undue burden on the agency or result in an fundamental alteration.

Promising Practice Federal Election CommissionD


1. This document is available on the Department of Justice's section 508 Web site (www.usdoj.gov/crt/508). People with disabilities may request copies in Braille, large print, or on computer disk by calling 1-800-514-0301 (voice) or 1-800-514-0383 (TTY).

2. Popularity was measured by usage. If a component had no way to track usage, it was instructed to evaluate the top 20 pages in order of hierarchy: that is, those that could be accessed by the fewest number of links from the component's home page.

3. The guidelines of the W3C's WAI are the result of a compilation and technical upgrading of a number of different Web accessibility guidelines from around the world. They are developed by a consensus process through a W3C working Group involving Web industry, disability organizations, research organizations, and governmental organizations.

The Department of Justice's Report has not been adopted, endorsed by, or in any way approved by the WAI, the W3C, or any component.

More information about the WAI and its products is available on the Internet (http://www.w3.org/WAI).

4. The Department was careful to limit the degree and scope of conclusions drawn from the data provided by agencies, for the simple reason that many of the components appeared to misunderstand some of the questions. Spot-checks conducted by the Department of the Web sites -- the URL's of which were reported on the survey forms -- revealed that many of them did not contain the features the components identified them as containing. For instance, 592 Web pages were identified as containing "applets." The Department, after reviewing a majority of these pages, did not find a single applet in a spot-check of most of them.

There are many possible explanations for this observation. It is possible that as components identified accessibility problems with certain types of features (e.g., applets), they deleted the offending features from their Web pages rather than making them accessible. It is more likely, however, that many of those who evaluated Web pages were not sufficiently careful or knowledgeable to correctly identify features of their Web pages.

5. Because of these categories, some survey questions appear out of order in this Report.

6. This is consistent with Guideline 1 of the WAI Web Content Accessibility Guidelines (WAI Guidelines, version 1.0).

7. Accompanying this analysis are 3 sets of appendices, which include tables and descriptions of the data provided by the agencies. These Web Appendices can be summarized as follows:

8. Currently, applets are written in the JavaTM programming language. Sun Microsystems, the creators of Java, provides background information and technical assistance in creating and using applets in Java through their Web site (http://www.java.sun.com).

9. Of the 2436 Web pages surveyed, components answered "not applicable," presumably indicating that those pages did not contain applets.

10. Reviewers may have confused JavaScript scripts (which were found on many of these pages) for Java applets. JavaScript and Java are two distinct programming languages.

11. NHTSA uses the "dashboard" image map, Fig. 3, extensively throughout its Web site. In the past, NHTSA had inadvertently omitted to provide alternative text links each time the "dashboard" image map appeared on its site. The significance to persons with disabilities was that once they were on a NHTSA page where navigation could only be performed through the "dashboard" image map, people who are blind, deaf-blind, those who have significant low vision, many with cognitive impairments or learning disabilities, and anyone with a disability affecting manual dexterity who cannot use a computer mouse was unable to use any of the functions that were available to the nondisabled user through the dashboard image map: "touring" NHTSA, going to the NHTSA home page, looking at "hot" and "new" items, accessing the Auto Safety Hotline, using the search function, or going to the "Cars" or "People" pages within the NHTSA Web site. NHTSA immediately corrected this problem as soon as the Department of Justice brought it to NHTSA's attention. Now, wherever the NHTSA "dashboard" image map appears, it is accompanied by alternative text links, giving people with disabilities equal access to the functions activated through the image map.

12. Question 6 also relates to WAI Guideline 13, which states, "Provide clear and consistent navigation mechanisms ­ orientation information, navigation bars, a site map, etc.­ to increase the likelihood that a person will find what they are looking for at a site."

13. Questions 14 and 15 follow the principles outlined in Guideline 2 of the WAI Guidelines, which states:

Ensure that text and graphics are understandable when viewed without color.

As explained by the WAI Guidelines,

If color alone is used to convey information, people who cannot differentiate between certain colors and users with devices that have non-color or non-visual displays will not receive the information. When foreground and background colors are too close to the same hue, they may not provide sufficient contrast when viewed using monochrome displays or by people with different types of color deficits.

14. While style sheets may create barriers for some users, other users may use style sheets to actually improve the accessibility of Web pages. Some very modern browsers allow users to create their own style sheets that will be used for any Web pages visited by the user. These style sheets can be used, for instance, by a user with low-vision to ensure that all text on a page is in 18-point, sans serif, black letters on a white background. Web designers should always provide a fall back pages that do not require the user's Internet browser to support style sheets.

15. For security reasons and to promote forms which are electronically scannable, many agencies use Adobe's portable document format (pdf) to post forms to their Internet pages. However, use of pdf poses a substantial barrier to many people with disabilities. Thus, agencies should always accompany pdf forms with alternate, accessible forms. Agencies may indicate that only those for whom the "mainstream" forms are inaccessible are authorized to use the accessible (non-scannable) versions of the form.

16. pdf documents can be created in different ways; each has implications for accessibility. One method to create pdf documents is to scan an image to create a pdf file directly. Unfortunately, these so-called "PDF Image Only" files are essentially graphic representations of the documents and, like photographs with no associated text, are completely unreadable by screen reader technology (some files can be converted into searchable text using optical character recognition techology, but this technology yields inconsistent results). A second way to create pdf files is to print directly to pdf format. While this option does create text that is readable by screen readers, it still suffers from many of the shortcomings identified by the Department of Education.

17. Recently, in a presentation to federal agency officials and employees, representatives from Adobe explained that their newly released version of Adobe Acrobat included many accessibility features that, if used correctly, could be used to create files that were easily accessible to users with disabilities. Adobe's Accessibility Seminar, Feb. 2, 2000, IRS Building. Word processed documents that are "printed" to pdf instead of "scanned" to pdf are much more likely to work well with Adobe's access utility. Adobe clarified that it sees its job as simply to provide the tools for making accessible files, not to teach users how to use these tools to make files more accessible.

Several audience members commented that in light of section 508's requirements, Adobe should integrate into the software it is marketing to federal agencies inaccessibility flags that would warn users when they were using the software in such as way that would result in inaccessible content.

18. Other agencies have included other file formats that they have found to be inaccessible. In 20 component evaluations and 2 overall agency reports, agencies noted the presence of other specialized file formats that were inaccessible to users with disabilities. Among these other file formats, Microsoft PowerPoint files were identified in many of these reports. Microsoft PowerPoint is not as commonly used as pdf files for two reasons. First, Microsoft PowerPoint is a application designed specifically for making visual presentations, often for large groups of users, and not for recording information for dissemination to others. Second, use of the PowerPoint files requires owning a copy of Microsoft PowerPoint to view or use the files for presentations.

19. Adobe Acrobat pdf files are specifically intended as a way of distributing information and can be read using a free reader program available from Adobe. Pdf is a very popular means of disseminating information. In a recent speech, John Warnock, founder and CEO of Adobe Systems, noted that Adobe Acrobat's free reader software is downloaded approximately 1.1 million times each week.

20. In its July 22, 1999, overall agency report, the Department of Education summarized the accessibility challenges faced by agencies choosing to put documents in Adobe Acrobat's pdf format:

The Portable Document Format (PDF) has provided one of the most controversial accessibility problems of the decade. PDF documents, by the nature of the medium, are portable, cross-platform, generally tamper-proof, and render in exacting detail, representations of the original print document's fonts, formatting, etc.
Unfortunately, documents displayed by the Adobe suite of products are totally unusable by those using screen reader technology to retrieve information from a computer display. Approximately three years ago, Adobe released a beta version of a plug-in, designed to convert PDF documents into text/HTML, thus rendering them available to screen reader users.
Unfortunately, this plug-in, despite numerous claims, often crashed, was difficult to install and use, and produced unreadable text, except in the simplest of documents which had no columns, tables, or other complex formats.
The availability of the plug-in has unfortunately misled many individuals into believing that PDF-only posting of documents is an acceptable means of providing documents in accessible formats. This is simply not the case, and we have, through our Internet Working Group, established a general policy of posting documents in PDF and HTML, or PDF and text as appropriate.
We understand that over the next year or two, this bleak prospect for the accessibility of PDF documents should change. With the release of PDF 1.3 in Acrobat 4.0, the PDF format will now contain metadata that will provide more information on the document's logical structure so that accessibility conversion tools can render a more exact representation of the original document when converting to text or HTML.
However, this will take some time, and will not happen until authors begin to utilize this increased logical structure metadata, and the accessibility conversion tools incorporate the ability to interpret this metadata in a meaningful manner.
Ideally, the accessibility plug-in will eventually be built into Acrobat Reader, enabling a smooth and seamless utilization of the Reader by sighted individuals and those using screen readers, without the need for intervening plug-in software. Until these things take place, we must judge the Acrobat Reader as inaccessible and not in compliance with the intent of section 508.

Department of Education's Overall Agency Evaluation.

21. There are many times when printing to pdf or using OCR is not practical, such as when an agency is posting an electronic representation of artwork, a photograph, or other non-textual content. Non-text content should be accompanied by text descriptions.


Back to the Table of Contents