Unified
Web Site Accessibility Guidelines

Version 7.2
June 1997 (amended 06 December 2017)

Compiled by:

with contributions from:

Prepared under funding from
the National Institute on Disability and Rehabilitation Research (NIDRR),
Office of Special Education and Rehabilitation Services (OSERS),
US Department of Education
and in cooperation with the NCSA-PACI Access Project.

Introduction

There are features of the World Wide Web (WWW) which are not currently accessible to people with disabilities. However, it is possible today to make very creative, artistic and interesting Web documents that are completely accessible. These guidelines are a compilation of input and guidelines from a wide range of groups and individuals working on developing accessible Web principles and strategies. Your comments and input are welcome and invited.

When discussing the accessibility of the WWW, these four basic components need to be addressed:

1. the server
2. the source material
3. the pipeline
4. the viewer

This document focuses on what can be done when creating HTML pages which would fall under source material. There are some comments in the document regarding the other components but the focus here is on the pages themselves.

These guidelines look at what can be done today, and also occasionally comment on emerging technologies and the strategies that might be possible in the future.

You can of course, create an accessible document by creating one that only has text and hypertext links (no images, sounds, tables, frames, JavaScript, etc.). However, you do not need to avoid using images, sounds, or advanced features if you design your pages right and provide text alternatives.

As you read this document you will see that much of the document is directed to addressing the problems that people who are blind and using screen readers encounter in using the Web. That is because the primary problems in Web access are encountered by this population. People with physical disabilities do not have much problem with the design of Web pages. If they encounter problems, it is usually with the design of the browser. People with hearing problems only have difficulty if there is important information being presented aurally. As long as all audio information is also provided visually there usually isn't a problem in accessing the Web site. Finally, people with cognitive disabilities usually benefit from clearly laid out pages which use plain language and are obvious in their operation.

This document is divided into the following sections for convenience. This handy jump grid is provided periodically throughout the document to aid in navigation.

NOTE: The Quick Reference Page and Contents for this version of the document are still in preparation.

Text

Text formatting can provide the designer with flexibility but can also present a number of problems to different users if not carefully used. This section addresses text usage that will make Web pages more accessible.

There are 7 subtopics:

1. Text Phrases Used as Links (Text Anchors)
2. Text Layout
3. Graphics Containing Text (Bitmap Text)
4. Text Size
5. Text Color
6. Punctuation and Symbols
7. Blinking and Moving Text/Text that Changes or Moves

Text Anchors

Issues:

1. People who use screen readers to access the information on a Web page will often use the tab key to step through the links on a page. Although this allows users to more quickly identify links, they will not hear the surrounding text and will lose the context of the link. This is especially a problem with pages that use the same phrase for several different links. For example, a page that only has a list of "click here's."
2. Screen readers will often read a series of links as a single link if spaces or punctuation do not separate them.

Solution Strategies:

• Make text anchors descriptive enough so that they make sense when read out of context.
  This will allow a person using a screen reader who is stepping from link to link to select a link without needing to read a whole section to determine the context.
  This is often an impossible task for links included within a sentence. In these instances some HTML authors have included the word link in the text anchor. However, in the future, this problem should be addressed by browsers and/or screen readers.
• Place spaces or horizontal lines between links which occur consecutively.
  Spaces are often used to prevent a list of links from being read as one link by a screen reader. Horizontal lines not only break up the links for the screen reader but the sighted user as well.
  For example, notice the above list of subtopics in the "Text" main topic. Each link ends with several spaces followed by a line break. The HTML looks like this:
  
<A HREF="#text.anchors"> 1. Text Anchors</A><BR> <A HREF="#text.layout"> 2. Text Layout</A><BR> <A HREF="#text.bitmap"> 3. Bitmap Text</A><BR> etc. etc.

Text Layout

Issue:

• Tabular presentation of text causes problems for people using screen reading software because text is read by row rather than column. To understand the problems it is important to know that most screen reading programs used by people who are blind, read the words on the page to the user one line at time. That is, they start at the left margin and read straight across to the right margin. If there are two columns of text, it will read the words in the left column - and then the works in the right column. Even users that have screen readers that can read by column might get lost in a tabular layout if they are unable to determine which column or row they are in while maintaining their position in the table. Also, pages that use tables to layout text can be very confusing if not done very carefully.

For example:


There is a 30% chance of rain showers this		Classes at the University of Wisconsin will
morning, but the weekend looks like it will be sunny.		resume on September 3rd.


This would be read as:
There is a 30% chance of rain showers this Classes at the University of Wisconsin will morning, but the weekend looks like it will resume on September 3rd. be sunny.


The problem of columns getting mixed up becomes even worse when the text "wraps," when it cannot all fit on one line and drops down to the next. For example, the columns might now read:


There is a 30% chance of Classes at the University rain showers of Wisconsin this morning, but the weekend will resume on September looks 3rd. like it will be sunny.

Solution Strategies:

• Avoid arranging text documents in columns .
• If it is unavoidable, make a text-only version of the page containing the table. See the section on tables for more discussion about other types of tables.

Testing Tips:

• One way to predict how a screen reader will read your table is to hold a piece of paper up to your monitor and read completely across the screen. As you move the paper down through the document, read what is on one line and have someone else listen. Does it make sense?
• Another is to save the document as text only (available in the "File" menu in most browsers). Viewing your page this way often gives an indication of how scrambled it might appear to a screen reader.

Solution Strategies in the Future:

As we've discussed, there are several different pieces of the puzzle that can be modified to increase accessibility. In the land of tables, there is work going on with screen readers, HTML specifications, and browser support. Screen reader developers are working on techniques to read by columns, and browsers are emerging that can render tables in a more readable format. The HTML 3.0 specification includes AXES and AXIS attributes for cells of a table, which could be queried by a browser to return row and column information about a specific cell.

Bitmap Text

Issue:

• Screen reading software cannot access bit-mapped text, perceiving it only as a graphic. (for more information on graphics.)

One of the most common examples of this is the counter that records the number of accesses by others to a certain page. On sites that have a script available on-site, the user can select it to know the count in text form. Other sites often use an "IMG" link to some other site that returns a computer-generated count as a GIF image. A text-only browser or screen reader, which says the word "image" when it encounters a graphic, reads, "You are visitor number (image) to visit this site." or "The number of visits to our site this month is (image)."

Solution Strategies:

If use of bit-mapped text is unavoidable, make sure the content is available elsewhere as text.
For example, on the Trace R&D Center page, the choices are presented with a series of GIFs (link to ALT-TEXT of the Trace R&D Center page). This page is accessible because of the ALT-TEXT associated with each image. See In-Line Graphics for more information on ALT-TEXT

Testing Tips:

• View the page with "autoload images" turned off or with a text-based browser such as Lynx.

Text Size

Issues:

• Users need to be able to adjust text size for easier viewing if they have low vision or temporary low vision.
• Page layouts can be affected by users adjusting the font size of browser displays.

Solution Strategy:

Use proportional font markups such as H1, H2, H3 rather than specifying font sizes so that text stays proportional when adjusted.

Text Color

Issue:

• Although users can override the color settings of HTML pages to alleviate poorly contrasting colors, new formats such as PDF and style sheets prevent this ability. Also, some users may not yet be aware that they have this ability.

Solution Strategies:

• Make the text and background colors contrast.
• Make sure that you test the colors you use. Is the text readable on a monochrome monitor?

For more information on color contrast, contact The Lighthouse Inc. (link to information on color contrast from The Lighthouse).

Punctuation and Symbols

Issue:

• Screen reading software often ignores or stumbles across punctuation.

Solution Strategy:

• Avoid uncommon typographic characters or constructions such as emoticons, arrows consisting of dashes and greater than signs -->, etc. Rather, spell out any abbreviations.

Text that Changes or Moves

Issue:

• When the BLINK tag is used, on certain browsers the entire word disappears for a couple of seconds at a time; with other browsers, a box around the word disappears and reappears. Browsers that make the box blink do not cause screen readers many problems, but those that blink text lose the word.
• Marquee text is often read by a screen reader one letter at a time as it appears on screen and in the order in which it appears, therefore it may read backwards, one letter at a time.
• Screen reading software may "freeze" if it encounters blinking or marquee text.
• People with certain disabilities (example - attention deficit disorder) are adversely affected by blinking or moving text.

Solution Strategy:

Avoid using the BLINK and MARQUEE tags. Use another method to draw attention to text such as text size, color, or capital letters (being careful to follow suggestions).

Layout

There are 6 subtopics:

1. General statement of problems and strategies
2. Tables
3. Lists
4. Frames
5. JavaScript
6. Preformatted Text (PDF, Style Sheets, etc.)

General Statement of Problems

As HTML evolves, new flexibility is being introduced. Tables and other constructs allow text to be laid out in side-by-side paragraphs and other formats which cause difficulties for screen readers because they will usually read an entire row in a table as a sentence.

General Solution Strategies for Today:

1. Keep layouts simple and straightforward.


2. Avoid side-by-side (columnar) presentation of text.


3. If using graphics to provide organization or structure to the document, attach ALT-TEXT to images that supply the same changes in context that the visual cues provide.

4. Where following guidelines 1 to 3 would interfere with the presentation of the information for some reason, a text-only page which shows the same information in an accessible format can be used. The link to the text-only page should be one of the first encountered on the graphics page and vice-versa.


5. Buttons that perform the same function on different pages (for example, "return to home page") should be located in a consistent location on the page.

Tables

Issue:

There are several ways to use tables to layout the information on a page. Briefly, we list four types of tables:

• Spreadsheet/Calendar - to layout numerical data
• Newspaper - to layout text in columns
• Graphical Navigation - to layout images in a navigation menu
• Combinations of the above - a column of images as a navigation bar beside a column of text.

Each of these create different accessibility problems for screen reading software. As noted above, if there are two columns of text, many screen readers will read the words in the left column - and then the words in the right column. Even users that have screen readers that can read by column might get lost in a table if they are unable to determine which column or row they are in while maintaining their position in the table. Also, pages that use tables to lay out text can be very confusing if not done very carefully.

Solutions Today:

Dependent on the type of table you are using, different strategies may apply.

1. For a layout of a series of icons
   Each cell in the table should be able to stand on its own. As long as the alt-text for each of the images does not wrap within its cell, this should be accessible. For an example, look at the United States Postal Service's WINGS home page (link to the US Postal Service WINGS home page http://www.wings.usps.gov).
2. For text in columns (newspaper format) or numbers in columns (calendar or spreadsheet format)
   Provide a text only version with text laid out in a single column. In some instances this may be undoable. For example, if you have several spreadsheets of budget information for a city, this could take several weeks to translate to a text-only version. OR Provide a contact number or e-mail that someone could call to obtain help with the table.

Solution Strategies in the Future:

• Additions to HTML
  It has been proposed that the table construct will contain two attributes that will help people using screen readers access information in tables. These are the AXES and AXIS attributes that would be associated with each cell in the table.
• Additions to Browsers
  If the browser makes these attributes available for each entry in the table, the row and column information as well as the cell's data contents would be available to the screen reader.
• Additions to Screen Readers
  Currently, many screen readers can read by columns (if the table is laid out in a regular fashion) but are unable to help the user orient which row or column they are in. This information should be either provided by the browser or the screen reader.

Lists

Issue:

People who use screen readers often do not know where lists begin or end, or where an entry begins or ends. If an entry takes up two lines, it may appear to be two separate items.

Solution Strategies:

• Use a bullet or Number for each item in a list. Although numbers may imply an ordering of the items, it makes it easy to determine where in the list you are if hearing it serially.
• State how many items are in an upcoming list. For example, "There are 6 subtopics." or "7 Objectives of this study are:". This information is helpful in orienting users as to how long a list is that they are about to read.

A good example of numbered lists is found on the WINGS Access Page (link to the WINGS Access Page example of numbered lists. http://trace.wisc.edu/wings/)

Numbering lists also addresses cognitive disabilities. The organization in a page with numbered lists and an indicator of the upcoming page structure helps someone's understanding of a Web page.

Frames

Issue:

• Some screen readers treat each frame as a separate window. Screen reader developers and/or browsers need to address the issue of switching between frames to make this easier and more logical to do.
• When multiple frames are used and viewed on small monitors it is often impossible or difficult to see all of the data.

Solution Today:

• Create a text-only page linked to complex frames.

JavaScript

Issue:

JavaScript is a scripting language, that, in a very restricted way, helps make Web pages more dynamic. It is mainly used to enhance forms and as a subset of HTML has a similar set of problems. New issues are related to the ability to have user action's in one frame stimulate change in another. Research is still underway to address these problems.

Preformatted Text

Issue:

Although screen readers work well today with one-column text that is oriented horizontally left to right and top to bottom, screen reader programs do not work well with multi-column or vertically oriented text. The limitations of the screen reading technology present a special challenge to PDF files which are usually visually rich documents. (PDF documents often have a complex layout that includes multiple columns of text, text on a curve, vertical text, and sometimes even invisible text.)

Solutions Today:

• The Access view of the PDF document is designed to cooperate with screen reading programs for Windows by presenting the text of the document to improve readability. For example, Acrobat Access presents multi-column documents as a single column and "straightens" all non-horizontal text.
• If an Access view is not available, a text-only page is a solution.

Graphics

There are 5 subtopics:

1. In-line Graphics
2. Separate Viewer-Based Graphics
3. Image Maps
4. Color
5. ALT-TEXT and D-links

In-Line Graphics

Issues:

• People who are blind cannot view information that is presented (only) in graphic form.
• People who are accessing information over a slow network connection (such as a modem) have only very slow access to pages with graphics if the auto-load images feature is turned on or no access to the graphic information if the auto-load images feature is turned off.
• If Web documents (or their derivatives) are to be made available via phone or other auditory channel, then some alternate method for presenting graphical information is needed.
• People who are accessing information with a text-based browser such as Lynx have no access to graphic information.
• Some people want to view graphics, and some others cannot access graphics.
• People with manual or cognitive disabilities, people who cannot read, etc. may have difficulty understanding or interacting with information that is presented only in text form.

Solution Strategies Today:

Approach 1: ALT-TEXT:
Provide an alternate text description (ALT-TEXT) which would be displayed, instead of the image, when viewing the page with a text-only browser or with the "auto load images" feature turned off.

The form for this is:

<IMG SRC="http://www.your.host/filepath/filename.gif" ALT="Alternate text describing the picture."> ALT-TEXT Tips and Tricks:

1. Keep the wording simple. For descriptions of diagrams or charts see the following two approaches.
2. Sometimes it is easier to describe what the function of the graphic is rather than what it is or looks like.
3. Using the height & width tags for images may cause the ALT-TEXT to wrap, which often makes it unreadable by everyone but Lynx users. Some browsers will support the font size tag. By decreasing the size of the font, the ALT-TEXT can be made to fit in the specified region.
4. Include punctuation or spaces at the end of ALT-TEXT of images used as links, so that several phrases are not strung together. (Link to more info about the Text Anchor guidelines.)
5. If the graphic gives the visual user an indication that there is a change in context, this should be modeled in the ALT-TEXT as well.
   For example: the ALT-TEXT for a graphical line might be 'Section 2: today's weather." But if you have already titled the new section (in some sort of bold text), don't be redundant, just say 'section 2.' If this is also contained in the title of the section, then you may just want to use '-----' or '----2----' or 'horizontal line.'
6. If you are going to use a horizontal rule for a visual layout of change of context, a graphical line is recommended rather than the <HR> tag.
   This way, the image can have ALT-TEXT. The description should indicate the function of the line.
   
   The ALT-TEXT used can also indicate a horizontal line for sighted users with the use of dashes:
   <IMG SRC="http://www.your.host/filepath/horizontalrule.gif" ALT="------------Section 2------------">
7. For critical bullets, use numbers or letters as the ALT-TEXT so that they are pronounced.
8. One of the first items a user encounters on the site should be a description of what protocol is being used. For example, make it clear that images without ALT-TEXT do not have any impact on understanding the context of the page. Some people then like to use nothing as the ALT-TEXT as follows:
   
<IMG SRC="image.gif" ALT=""> Remember that for the text-based browser or screen reader user, the image will be unnoticed.

Approach 2: Longer Descriptions (on separate pages, or as footnotes)
By their nature, ALT-TEXT descriptions are usually short and define the basic purpose of graphic elements. For example "Logo for XYZ company" or "Picture of ZZZ Center Building". These are instructive but do not provide very much information about the pictures.

Method 2.1: D-Links:
In order to provide people with additional information, WGBH has pioneered the practice of placing a capital "D" text anchor next to pictures or graphics which link to a longer description of the graphic. (Click here for the WGBH page discussing D-links.) For example, "The Logo for XYZ company" consists of a globe with people of different races all standing out from the globe, holding hands, while a sunburst shines from behind the earth. The earth is positioned so that no particular continent is centered on the globe" Descriptions which are too long for ALT-TEXT descriptions can thus be provided, yet they do not clutter up the main page.

Since the "D-link" is not a very descriptive link, if you use this method you should probably include a statement somewhere that describes what access features you have included so that people know that a capital 'D' will take them to a description of an image.

Another option is to use a more descriptive text anchor, such as "or a description of xxx."Click here for more discussion and examples of D-links.

Method 2.2: Transparent images as links to descriptions
Another option is to create a transparent image as a link to a text description of the image or a text description at the bottom of the current page. Click here for an example--transparent GIF linking to text at the WINGS site. Click here for an example--transparent GIF linking to footnote description from The Smart Card and Missing Link pamphlets by John Gill.

As can be seen on the "Smart Card" pages, the ALT-TEXT of the first image at the top of the page is a link to a description of the format of the page. When images are loaded, this graphic is not seen since it is the same color as the background. In this case, "invisible" images can provide all kinds of contextual cues to users that do not load graphics, or not be disruptive to users that do.

Approach 3: Alternate pages:

Provide a second version of the page which does not include any inline pictures for decoration or for anchors. Instead, text descriptions and anchors would be used. If this is done, a note at the top of each page could allow users to move back and forth between the graphic and text-only versions of the page.
It is also helpful to provide an indication of how many items appear in a list. For example, before a list with six items you could say, "List with six items." (Click here for more information on lists--Jan Richards' article or click here for our discussion on lists.)
It is also recommended that you provide the ALT-TEXT tags described in Approach 1 on your "graphic version" of the page. Links to alternate pages can be implemented as described in Approach 2 .

It is easy to see that creating text-only versions of every page on a site doubles the number of pages that need to be maintained. Here are three methods for generating and maintaining text-only pages:

(Coming soon: case studies on creating text-only versions, problems, solutions, examples)

Method 3.1: "By hand"
Sometimes, a site may only need to create text-only pages for layouts that can not be made accessible. This may only involve a couple of pages.

Method 3.2: Database-based pages:
Create a database-based server that generates HTML pages on demand when the user asks for them. In this manner, pages can be constructed "on the fly" either with or without graphics. An example of this is the CommerceNet server (click here to access the CommerceNet server).

Method 3.3: Filter
This approach is similar to Method 3.2, but involves the use of a filter/translator that would exist on the server as a common gateway interface (cgi). Pages would be constructed using ALT-TEXT and alternate text pages where needed and, at the direction of the user, translated into either graphic or pure text pages on the fly. This method has disadvantages however. Since all pages must be processed on the fly (as with the database method), there may be a performance hit unless the filter program is used off-line to create the text versions of the pages in advance. Secondly, this method would only work for pages on the server with the AltPage cgi. Whenever references were made to other pages on other servers, the filter would not work. Image maps on other servers would be a particular problem unless client-side image maps were used. Finally, such a filter would create text versions of pages, but since it would do it by formula, the pages may not be laid out very well or be very easy to interpret. Building access into the page or providing alternate pages which are laid out to make sense in text form (and to provide a text alternative to any Image Maps) as with Method 3.1 would be much more effective.

Solution Strategies in the Future:

• All graphic elements will have a text description as part of the data structure of the graphic, which can be viewed instead of the graphic. One example of this is the Portable Network Graphic (PNG) data format.
• All browsers will provide the option of showing the graphic, the text, or both. This should be configurable within the user settings.

Separate Viewer-Based Graphics

Issues:

Often in viewing HTML pages, users will encounter images or anchor phrases which will fetch and display a large graphic image. This image is often displayed using a separate viewer in a separate window on screen.

• If you cannot see, you have no access to this information.
• If you are on a slow network connection, you need to wait a long time to download the image to see whether or not you are interested in the information it contains.
• If you do not have the proper helper programs, you cannot see the information.

Solutions Today:

The only available approach for providing alternate text for non-embedded graphics is to provide an alternate data file with the text description of the graphic in it. (Although some graphic storage formats do allow storage of text within the data structure, the servers, browsers, and viewers do not yet allow access to it.)

Approach 1 : (generally recommended)
Place an anchor to a separate page which has a text description of the picture right next to the anchor that pulls up the picture.

As discussed in the last section, WGBH has instituted the practice of putting a capital "D" next to pictures or graphics in a document. If you are using a thumbnail version of the picture as an anchor to the larger picture, you could use the "D-link" very effectively for the anchor to the description of the picture.

Approach 2 :
Include a descriptive text anchor to a page describing the graphic, for example: "or a description of xxx".

Approach 3:
If the user has requested a text-only page, replace all references to pictures with references to the text files describing them.

In general, Approach 1 is preferred since many users may have asked for the text-only version because of speed, and may want to view occasional pictures of interest. Also, even blind users may sometimes want to pull up a picture to show someone or to have someone describe it to them in more detail. Both of these are much easier with Approach 1 than with Approach 3.

Solution Strategies in the Future:

Someday, all graphic data formats (such as TIFF, JPEG, PICT or their successors) will also allow incorporation of text describing the image (very useful for access and for searching or indexing pictures like PNG). External or "Helper" viewers could then allow display of the graphic, its text, or both. Servers could also be able to send the graphic portion, the text version, or both, on request from the browser. (Java applets could be programmed to do this today, but it is not a general capability yet.)

---

Image Maps

Issue:

Image maps allow users to click on "hot spots" of a picture which reference WWW pages. This type of feature, which requires an ability to see and click on particular parts of a graphic image, is completely inaccessible to people who are blind. Even if the picture is described, they are unable to detect where to click. Unless a client-side image map is viewed with a browser that can tab to any active object on the page, such as Microsoft Internet Explorer.


Image maps are used in a wide variety of ways. Some uses are rather simple like nice-looking menu bars. Others are more sophisticated, like graphic representations of maps, diagrams, etc.

Solutions Today:

Today, there are five strategies for providing access. All of them involve ways to provide text alternatives to the image map's choices, usually as a listing of text anchors.

Approach 1: (recommended)
Create a client-side image map using alt-text for each of the links.

Several browsers support client-side image maps including Lynx, Microsoft Internet Explorer and Netscape's Navigator and Communicator. Client-side image maps are similar to server-side image maps except that the information regarding all of the links or "hot spots" on the image are sent to the browser along with the image map picture. If descriptions (a sort of ALT-TEXT for the image maps links) are provided with the URLs, then browsers can display the text associated with the links of the image map.

To include the ALT-TEXT for the image map links:

<IMG SRC="welcome.gif" ALT="Image Map of Trace Documents" USEMAP="#map1" BORDER=0> <MAP NAME="map1"> <AREA COORDS="0,0,30,30" HREF="java/report.htm" ALT="Java Access Report"> <AREA COORDS="34,34,100,100" HREF="guide/htmlgide.html" ALT="HTML Guidelines"> </MAP>

Approach 2: (recommended)
Have an anchor to a text-only page which presents an alternate form of the entire page. Replace the image map with a list of text anchors of the URLs available through the image map.

Approach 3: (also good if done in a way which avoids confusion)
Provide a listing of image map choices as a list of text anchors immediately below the image map. This sometimes works, but it can also be confusing. The ALT-TEXT of the image map should say that choices are provided in text form following the image map.

Approach 4: Instead of using a single graphic as an image map, use a series of several images that can each have their own ALT-TEXT.

Approach 5: For each link on the image map create a transparent GIF. The ALT-TEXT of this image can act as a substitute link for each image map option. Users who do not view graphics will see all of the image map options, and users that view graphics will not notice the invisible images.

The following example was provided by Bill Shackleton. The image map is a picture of a motorcycle that would link the user to various component descriptions depending on where on the cycle they clicked (wheel, gas tank, etc.). The invisible graphics would be:

<a href="wheels.htm"><img src="invisible.gif" alt="Description: Wheels" border=0></a> <a href="gastank.htm"><img src="invisible.gif" alt="Description: Gas Tank" border=0></a> <a href="motor.htm"><img src="invisible.gif" alt="Description: Motor" border=0></a>

---

Color

Issue:

Background graphics, text colors and colorful images are often used in the design of Web pages. Although this may make the page appear more attractive or memorable to some, to others it is not readable.

Solution Today:

Luckily, users can override the source code by changing several configuration options available in most current browsers. For example, a user can choose not to load background images as well as choose what color, text, font, links, and background will appear.
(A few formats do exist, such as PDF and style sheets, where the user is not allowed such control.) Care needs to be given to this issue by page authors.

Solution Strategies:

1. Background patterns and color should contrast well with the lettering to maintain readability (background refers to both backgrounds of pages and backgrounds of images).
   

Using dark shades of blue, violet, purple or black lettering on backgrounds of light shades of blue-green, green, yellow or orange are easiest to read. Avoid using similar hues together. For example, do not place blue-green lettering on a blue background (Arditi, 1995). For more information on color contrast for people with low vision and color deficiencies, contact the Lighthouse (click here for The Lighthouse and info on color contrast).


2. Select colors that will make your pages easy to read by people with color blindness. One good test is to see if your pages are readable on a monochrome monitor.
   

Make color coding redundant with other means of conveying information. For example, distinguish glossary words with the color red as well as bold font.

Keep in mind that not all platforms will display color in the same manner. For a good discussion on the differences between color support on platforms, read this e-mail from JQ Johnson (click here for a discussion of color support--JQ Johnson).

ALT-TEXT and D-Links

A detailed discussion about ALT-TEXT and D-links can be found in the Appendix. (Click here for an ALT-TEXT and D-links discussion.)

Multimedia

1. Audio Clips
2. Movies

Audio Clips

Issues:

1. People who are deaf or hard of hearing cannot access information which is presented in auditory form only.
2. People without audio capabilities in their computer do not have access to audio information.
3. People who do not have the proper Audio Player helper application will not be able to play an audio clip.
4. People in noisy environments may not be able to hear information presented audibly.
5. People may want a printed transcript of the dialogue of the movie in addition to the sound.
6. People may want to search for a certain section of the audio clip or identify keywords using Web crawlers, so they need a text version.

Solutions Today:

The strategies for accessing sound today also look essentially the same as for graphic files:


Access is provided by placing a transcript of the speech or description of the sound in a separate file. This separate text file is accessed in one of two ways:


Approach 1: (generally recommended)
Place an anchor to a page with a text transcript or description of the sound right next to the anchor for the sound.


Approach 2:
If the user has requested a text-only page, replace all URL references to sound with URL references to the text transcript or description.


As before, Approach 1 is preferred because it provides the user with more options, it allows them to use any residual hearing, and it is useful to people with language impairments.


It is often the case that people without disabilities are interested in the text transcripts as well. For example, it allows you to index and search through movies and audio clips by Web crawlers.


Click here for audio clip info and examples from WGBH.

Example:

Below is an example based on the White House Web server, courtesy of Paul Fontaine at the General Services Administration. Note that this example includes both ALT-TEXT access to the sound icon and the text translation of the audio file.

Suggested code:

The President asked <A HREF="http://www.ostp.eop.gov/images/raw/al-portrait.gif"> Vice President Gore to head up the National Performance Review (NPR), a project to make government work better and cost less. You can <A HREF="http://www.ospt.eop.gov/sounds/gore.au">hear or <A HREF="http://www.npr.gov/al_npr_intro.HTML">read</A> Mr. Gore's speech introducing NPR. This would look like:

The President asked Vice President Gore to head up the National Performance Review (NPR), a project to make government work better and cost less. You can hear Mr. Gore's speech introducing NPR or read a transcript.

Solution Strategies in the Future:

The problems and solution strategies for audio clips are very similar to those for separate viewer-based graphic elements and movies:


1. Access can be accomplished by storing text in the data structure.
2. Servers should be able to send the sound format, the text format, or both, on request from the browser.
3. Players should be able to present either the sound format, the text format, or both.
4. RealAudio or similar formats should include the ability to simultaneously present the text version of the audio information.

Movies

The only known way to make movies accessible to people with disabilities is to embed the accessibility information in the data stream so that it is time-synched with the other information.

Two types of alternate format information are needed to make video accessible:

Audio:
Captions or other visual representations of all important information in the sound track should be provided. (Some data structures such as QuickTime movies already have a mechanism for adding captions to the data structures.)


Video :
For people who are blind or who have low vision, a technique called Descriptive Video is used which provides an additional narrator describing what is happening during the regular dialogue of the movie.


Text transcripts should be provided for both Audio and Video.

Solutions Today:

Captions :(for those who do not have access to sound)

Approach 1 : (Recommended)
If the external viewer being used will display embedded or "closed" captions (such as QuickTime), captions can be embedded in the data structure of the movie.


Approach 2 : (Good Alternate)
A strategy which works for all movie viewers today is to have an alternate version of the movie available with open (permanent) captions which users can choose instead of the uncaptioned version if they wish.

Approach 3 : (Good as supplement)
In addition to providing captions in the movie, it is also useful to provide a separate transcript of the audio track of the movie. It usually takes quite a while to download a movie file, and a text transcript of the audio can usually be downloaded quickly and allow one to prescreen the item before deciding whether to take the time to download it.

Descriptive Video: (For those who do not have access to the video portion of the movie)

Approach 4 :
If the movie format allows alternate audio tracks (such as QuickTime), you can provide an alternate track which includes the descriptive narration.


Approach 5 :
If your movie format does not allow alternate audio tracks, you can provide an alternate form of the movie with the descriptive narration included in the audio track.


Approach 6 :
In addition to providing a transcript of the basic audio track of the movie, it is also useful to include the text of the descriptive video in the transcript.

Example - QuickTime:

In QuickTime you can add as many audio or video tracks as you wish. Users can then select as few or as many of the tracks as desired when they view the QuickTime clip.


Tracks could include:

1. The regular video track
2. The regular audio track
3. A text track with captions
4. An audio track with video descriptions added
5. An additional video track with American Sign Language translation
6. Additional text or audio or video tracks spoken or signed in other languages

Other Advantages:

In addition to the access advantages of these approaches, there are also other benefits:


1. Movies with captions can be indexed based on their captions and found using text searches of the World Wide Web.
   
2. You can search for words within the captions of a movie and jump to that position in the movie.
   
3. If descriptions are provided in text mode as well, you can index and search for any video information which is contained in the descriptions.
   

Solution Strategies in the Future:

• Eventually, all data structures should allow captions and audio or text descriptions of movies to be embedded in the data storage and transport formats.
  
• Servers should allow any combination of video, audio, captions, and / or description to be fetched on command.
  
• Viewers or players (helper applications) should allow users to specify and display any combination of the above.

User Input and Interaction

1. Forms.
2. Java.

Forms

Issue:

Forms include several types of components such as buttons, edit boxes, pop-up lists and radio buttons. Currently, some screen readers have difficulty entering and manipulating form components. Much of this functionality is being added to browsers, for example, you can now use the keyboard to tab between all objects on a screen in Microsoft Internet Explorer and Netscape's Communicator. However, there are still some screen reader and browser combinations that have problems.

Solutions Today:

For those browsers and/or screen readers that can not identify empty edit boxes, we recommend using place-holding characters such as a space, short description or a textual cue. The Trace Web Site Search edit box has a space included as a place holder.

<input type=text name="keywords" value=" " size=40>

It is often a good idea to also provide a form which can be downloaded then mailed or e-mailed (click here for a cgi for mailing forms from MIT) or a phone number someone can call for assistance.

Solution Strategies in the Future:

In the future, features within the browsers and/or screen readers will allow users to navigate between and manipulate form components.


For a discussion of browsers, click here for Trace Center page on browsers.

Java

Issues:

Since Java is a full-fledged programming language with several issues of its own, we leave the discussion for how to make Java applets/applications accessible to another document. Trace recently completed a report commissioned by Sun to identify the accessibility issues with Java. That report can be found at http://trace.wisc.edu/java/report.htm

However, not all browsers support java nor do all users want to download applets because of bandwidth or platform constraints. The newer browsers support a preferences flag that allows the user to indicate if they wish to view applets or not.

Solution Strategies:

For viewers that allow the user to block downloading of applets, include alt-text:

<applet code="HelloWorld.class" width=50 height=100 alt="This applet displays the words 'Hello World'"> </applet>

For viewers that not do support Java, you can include images or a text description or a link to another page:

<applet code="HelloWorld.class" width=50 height=100 alt="This applet displays the words 'Hello World'"> <IMG SRC="Hello.gif"> An applet exists in this space that displays the words "Hello World." </applet>

Non-Standard Formats

Custom Data Structures and Viewers

Issue:

Some Web sites are introducing special data structures and viewers to differentiate themselves or provide special functions not available with the standard tools.

Solution Strategies:

The only way for these custom data and views to be accessible is if the access is built directly into the viewer. Standard access tools do not generally work with special viewers at this time.

Testing

Always test your pages using a variety of text browsers and platforms (PC, Mac, UNIX). Be sure to include text-based browsers and use graphic browsers with images turned off as well as black-and-white monitors.

1. Bobby, ( Note of 16.12.2017: this was available at http://www.cast.org/bobby, but it has been put offline ) developed by Cast, is a culmination of several sets of accessibility guidelines, including these. It will check whatever URL you give it for possible accessibility problems. The report that it produces not only tells you where possible problems are, but how to solve them.
2. You might also want to use an HTML validation service to determine that your source conforms to one (or several) of the HTML specifications. Yahoo! has a list of several different sites that offer a variety of validation services. Click here for Yahoo! validation services.
   

Appendix

Experimental Solutions and Discussion

In the previous sections, we have presented approaches that can be used to increase the accessibility of your HTML. There are several approaches that we are testing and soliciting input on that are not yet ready to be included in the guidelines. We include our current thoughts on these experimental approaches to generate discussion, ideas and solutions.

The following section is divided into 3 categories:

1. "D-links"
2. Text (ALT-TEXT and text anchors)
3. Forms and edit boxes

"D-links"

D-links or "description links" have been pioneered by WGBH in order to more fully describe a graphic image than ALT-TEXT would. A D-link is a capital "D" text anchor that appears next to or below an image. This "D" links to a page with a full description of the image. Because D-link descriptions appear on their own pages, they can be as long as an author wants them to be. Therefore, users can receive more information about the physical description of graphic images than ALT-TEXT allows.


The following discussions were generated by looking at worse-case scenarios. Often, the pages viewed as models were totally unrecognizable by the screen readers used. The problems that arose dealt with cluttering of the original image map page, the need to toggle back and forth between D-link page and image map page, and the extra work needed to maintain the Web site. We are striving to find a solution which can alleviate problems for users and designers alike.


Send us your suggestions and comments! Click here to mail us: Web-team@trace.wisc.edu.

Possible Strategies for the Use of D-link with Image Maps

There is currently no best format for a D-link page. Five possible formats are discussed below with examples.

1. When users click on a D-link, they could be presented with the description of the image map, as well as the links from the image map itself. However, there may be links on the original page that are not reachable from the image map and thus cannot be accessed from the D-link page.
   

Click here--Only image map links in D-link page.


2. When users click on a D-link, they could be presented with the description of the image map, links in the image map itself, and all the links on that page that are not included in the image map. In this way, the user who wishes to understand the image map, by reading the description, would have the same access a sighted person would have on the original page. However, this would increase the amount of maintenance needed of the Web site.
   

Click here--All links included in D-link page.


3. Another way to increase access would be to present the image map links and all other links on the original page with ALT-TEXT, D-links and text anchors. However, this could give the image map page a cluttered look.
   

Click here--One page with ALT-TEXT, D-links, text anchors.


4. To decrease the amount of maintenance needed at the Web site, the D-link page could include only a link which returned the user to the original page. All other links would be accessed from the original page. However, this would mean that the person who wanted a description of the image map would have to make an extra link purely for the purpose of discovering the particulars about the visual properties of the image map.
   

Click here--Only a return link in D-link page.


5. The D-links could not appear on the image map page at all. Each time a D-link could be used, a text version of that page could be presented instead. The explanation of the image map would appear on the text page. The text page would have the same option of having links in it or not. However, you would be creating text pages which would otherwise not be needed.
   

Click here--Text version instead of D-link.

Preserving the Feel of the Site

When D-links appear on the image map page, there is a need to keep the D-links as unobtrusive as possible.

1. One suggestion is to use a very small font. However, certain screen readers have problems dealing with rapid font size changes. Therefore the size of the D-link would have to be large enough to be read by a screen reader. More research will be needed in this area.
2. Another suggestion, when available, would be to have visually nested links. We are hopeful that in the future it will be possible to include D-links in the ALT-TEXT link. In this case, when you have images turned on, you would be able to see the graphics page without the clutter of the D-link.
3. A third suggestion is to maximize the knowledge of the graphical image. This can be done by thoughtfully labeling the ALT-TEXT. For example, if the graphic was a man hole cover with a "need to repair" symbol, the ALT-TEXT might say, "manhole cover with repair symbol." The graphic would be completely defined in the ALT-TEXT and a D-link would not be needed. In addition, any person who does not have graphics turned on would have a greater knowledge of whether they wanted to follow the link attached to the graphic. However, complicated graphics cannot be dealt with in this manner.

Text Versions of a Page or an Entire Site

There are many reasons for choosing to use a text version of a page. One reason for using a text version of a page is the inaccessibility of the original page. The text version gives an accessible alternative. Another reason is due to the inability, in any other acceptable format, to present to a screen reader all the information a sighted person would be able to see at one time. A third reason is to give the ability to rapidly read the text without unwanted graphics. With a variety of needs, problems can arise.

1. When the site developer creates a text version of a page, would D-links be included on this page? The problem here is that some people read text pages because of the ability to rapidly read the text without unwanted graphical information, while others read it because of its accessibility. If you put a D-link on the text page, you would also have to include a symbol, as a place holder for the graphic, in order to allow the persons who are using the text version for accessibility, to know where the graphic appeared on the page. This would mean more clutter for those who only wanted to read the text.
   
2. When only part of the site contains text versions, how does the user know if the text page is taking them to another text page or to a graphical page? The designer may wish to keep the continuity of the site by causing the text pages to have much the same feel as the rest of the site. In other words, instead of being purely text, these pages would maintain the symbols, D-links, and other references to graphical images which appear on the original page. In this way, when the user ends up on a page which is not a text page, a difference will not be felt. However, this means making the page more cluttered for purely text readers and not truly a text page for those who need it.
   
3. Presenting a text version of the entire site is useful to persons using screen readers, text browsers, and any person who feel that they don't want the graphics. This issue, however, needs more investigation.
   

Conclusion

We need to carefully look at the different D-link scenarios to determine which approaches will provide effective and efficient access while keeping the page easy to maintain and attractive. In addition, we need to have a better understanding of those who would want or need the D-links so that the D-links could best meet the needs of the users.

Text (ALT-TEXT and text anchors)

We discuss 4 problems and their solutions:

Problem 1:

Screen readers will often read the ALT-TEXT of image anchors and/or text anchors as one link if there are no spaces between them.


For example: a menu bar at the bottom of a page is made up of one image anchor and two text anchors. The ALT-TEXT of the image and the first text anchor are read as one.



<A HREF="/pathname/link1.html"><IMG SRC="/pathname/image.gif" ALT="link1"></A> <A HREF="/pathname/link2.html">"link2"</A> <A HREF="path/link3.lhtml">"link3"</A>

Experimental Solution:

Place a space or spaces between text anchors to make sure you resolve the problem. This will also separate the links for visual users.

Note: Depending on the screen reader used, adding just spaces may not be enough to solve the problem all of the time. The screen reader software we are using has consistently paused between links when it reaches a space. Other punctuation may work as well. The use of spaces not only increases the accessibility by a screen reader, but it separates the text visually as well.

Problem 2:

ALT-TEXT is sometimes centered vertically next to the image icon and thus read on a different line.

Example:

<A HREF="/pathname/link1.html">"link1"</A> <A HREF="/pathname/link2.html"><IMG SRC="/pathname/image.gif" ALT="link2">"link2"</A> | <A HREF="path/link3.html">"link3"</A>

Experimental Solution:

A possible strategy is to take the image out of the sentence and put it before or after the paragraph or sentence. Authors can turn images off and see the placement of the ALT-TEXT, but the words may wrap differently on different browsers depending on the width and text size that users have chosen.

Problem 3:

Sometimes when ALT-TEXT is included in a sentence, it is hard to tell where the ALT-TEXT ends and the text of the paragraph begins.

Experimental Solutions:

You can place a character before and after the ALT-TEXT string, for example, an x. This will be read by all screen readers, although it may make things confusing. For example, if this were the ALT-TEXT of an image map, "x see links below x" the "x" could be confused with an entity (like icon x or x distance of miles to go, etc.) This also adds two syllables to each ALT-TEXT entry.

Another alternative is a slash (/). This way a person using a screen reader could turn on the correct level of punctuation so that a slash will be read or turn it off if they do not wish to hear the begin and end of the ALT-TEXT. With some screen readers, no punctuation means no punctuation, and in order to hear the slash, some punctuation needs to be turned on. However, this also means that point (.), comma (,), @, %, ^, &, \, # etc. will be read, which can greatly increase the amount of time and energy it takes to read a page. Including punctuation sometimes confuses the context of a sentence. For instance, "With some screen readers (comma) no punctuation means no punctuation (point)"

Problem 4:

If height and width are specified for an image, the ALT-TEXT might wrap. If there are several images in a row all whose ALT-TEXT have wrapped, a person with a screen reader might not be able to read it at all since a screen reader will read across the page. For instance if the ALT-TEXT for three images was, "Trace logo" "Trace documents", and "Trace calendar," depending on how the images were sized, a screen reader might read this as:

Trace Trace Trace logo documents calendar.

This also may make the ALT-TEXT unreadable for sighted people.

Current Solution:

At this time, a text-only version seems to be the only solution, unless the author can find a way around using the height and width attributes of images or use them in such a way that the text will not wrap. This is almost impossible to test, however, because people may have selected different fonts and sizes to be displayed by their browser.

Forms and edit boxes

Screen readers pass over edit boxes which are empty. The user has no way of knowing they are there. Even if they know, for example, that there is likely to be an edit box for entering a search query, it is difficult to place the mouse pointer on the edit box without sighted assistance.

Experimental solutions:

1. Put a place holder in the edit box.
   • If this place holder is accidently erased by the user, the I-bar will still be present in that box and the user can find it again.
     

   • Care would have to be taken to make sure the place holder did not interfere with such things as E-mail addresses, search routines, etc. The worse case would be that the user might have to erase the place holder in an E-mail address box. An asterisk might work in a search conditions edit box in that it would simply act as a wild card and allow the user to type in whatever word or phrase they wanted to search for.
     

2. Place the label for the edit box in a prescribed place relative to the box itself, for example, to the left of the box. As long as either there is a place holder in the edit box or the I-bar is present, the user would be able to find the label and then move the mouse pointer 1 space to the left to locate the edit box.

3. Alternate strategies could be used to obtain and act on the information normally found in edit boxes.
   • A search routine could be presented in an alphabetic index as well as a key-word search.

   • The user could down-load an address form or simply an E-mail address which could be used to return the requested information.

References

Arditi, Aries, PhD. (1995) Color Contrast and Partial Sight (Pamphlet). The Lighthouse, Inc. Available: 111 East 59th Street, New York, NY 10022. (800) 334-5497. TTY (212) 821-9713.

Norman De Forest

Berliss, Jane, Lewis Kraus, and Susan Stoddard. Design of Accessible Web Pages http://www.infouse.com/disabilitydata/guidelines.text.html

Glossary

1. The Free On-line Dictionary of Computing
2. The ADA handbook
3. "Accessible Design: A Handbook for more universal product design" by Gregg C Vanderheiden (1993) - class materials.

ALT-TEXT

Descriptive text information accompanying an image or graphic embedded in the HTML. When a user chooses not to view graphics, or uses a text-based browser, this is displayed instead of the image that it is associated with. The format is:

<IMG SRC="image.gif" ALT="Description">

American Sign Language (ASL)

A language for the deaf that uses manual signs; it is also called Ameslan.

bitmap text

A data file or structure which corresponds bit for bit with an image displayed on a screen, probably in the same format as it would be stored in the display's video memory or maybe as a device-independent bitmap. A bitmap is characterized by the width and height of the image in pixels and the number of bits per pixel which determines the number of shades of grey or colors it can represent. A bitmap representing a colored image (a "pixmap") will usually have pixels with between one and eight bits for each of the red, green, and blue components, though other color encodings are also used. The green component sometimes has more bits that the other two to cater for the human eye's greater discrimination of green.

blindness

A condition in which a person has lost the use of vision for ordinary life purposes, although some residual vision may exist.
Legal blindness is defined as visual acuity (sharpness of vision) of 20/200 or worse in the better eye, after correction, or when the field of vision is less than 20 degrees in the better eye, after correction

braille

A tactile code developed by Louis Braille to represent letters of the alphabet. There are six or eight dots in a braille "cell," depending on the style of writing used.
Characters are formed by the presence of one or more of these dots.

browsers (Web)

Software which allows a person to view Hypertext Markup Language (HTML). The browser gives some means of viewing the contents of nodes (or "pages") and navigating from one node to another.
Netscape Navigator, Microsoft Internet Explorer, NCSA Mosaic, Lynx, and W3 are examples of browsers for the World-Wide Web. They act as clients to remote Web servers.

captions

Subtitles in a movie or film or TV show.
Click here to learn about movie captioning on the Web.

client-side image maps

Also called "local" image maps, these are graphics or images with "hot spots." Each hot spot refers to a Uniform Resource Locator address (URL) so that clicking over the hot spot follows the link to the URL. Client-side image maps also allow the Web page designer to include text descriptions of each URL.
(See also server-side image maps.)

common gateway interface (cgi)

A standard for running external programs under a World-Wide Web HTTP server.
External programs are known as "gateways" because they provide an interface between an external source of information and the server.

cognitive disability

An impairment that results from some type of damage to the human brain.
Examples include: Impairments of intelligence and thinking, memory impairments, aphasia (an impairment of the ability to interpret and/or formulate language symbols), and learning disabilities.

color blindness

The inability to detect, distinguish between or identify colors at all or certain colors.

"curb cuts"

A popular example of universal design that benefits all users. Originally these were cuts into sidewalks for people that use wheelchairs, but have made travel easier for bicyclists, people that use strollers, pedestrians, luggage carts, and many others.
Now curbcuts also refer to universally-designed aids in society that benefit many users.

D-links

A text anchor placed next to or below a graphic that links to a detailed description of the associated graphic.
D-links were created by the National Center for Accessible Media (NCAM) at WGBH.

data formats (TIFF, JPEG, PICT, etc.)

Differing methods of arranging and storing data in a file.

deafness

A profound degree of hearing loss that prevents the understanding of auditory information, including speech, through the ear. Normal conversation is approximately 40 to 60 decibels (dB) sound pressure level (SPL). A person is usually considered deaf when sound must reach at least 90 dB SPL to be heard at all and cannot understand speech.

descriptive video

The Descriptive Video Service (DVS) provides narrated descriptions of the key visual elements in a video without interfering with the audio or dialogue of a program or movie. The narration describes visual elements such as actions, settings, body language and graphics.
(Click here for info on DVS at http://www.boston.com/wgbh/pages/dvs/dvsbrochure.html)

disability

A physical or mental impairment that substantially limits one or more of the major life activities of an individual.

edit boxes

Objects on a Web page that allow the user to enter text data.

emoticon

Punctuation used to indicate emotions in electronic mail or news. Although originally intended mostly as jokes, emoticons (or some other explicit humor indication) are necessary under certain circumstances in high-volume text-only communication forums such as Usenet; the lack of verbal and visual cues can otherwise cause what were intended to be humorous, sarcastic, ironic, or otherwise non-100%-serious comments to be badly misinterpreted.
Examples include :) (a colon and end parenthesis for a happy face) and :( (a colon and a start parenthesis for a sad face).

frames

A way to display more than one page of HTML on the screen at a time. A single browser window can be divided into multiple sections, each containing its own HTML page.
(Click here for info on frames at http://home.netscape.com/assist/net_sites/frame_syntax.html.)

GIF

A type of graphic and also the standard image format for Web browsers. You can include then inline with text. They do have visual li mitations, an 8-bit palette and 8 bits of color data, and are best used for compressing line drawings or cartoons.

hard of hearing

Normal conversation is approximately 40 to 60 decibels Sound Pressure Level (SPL) in volume. A person is usually considered deaf when sound must reach at least 90 dB SPL to be heard at all. A person whose hearing is less severely impaired is said to be hard of hearing.

helper programs or applications

An application needed to interpret a type of data format. It works outside of the browser in a separate application space.
An example would be QuickTime data formats which need a QuickTime player to view the data as a movie.
(See also plug-in.)

HTML (Hypertext Markup Language)

A Hypertext document format used on the World-Wide Web to create Web pages. "Tags" are embedded in the HTML text. A tag consists of a "<", a "directive", zero or more parameters and a ">". Matched pairs of directives, like

<title> </title> are used to begin and end text which is to appear in a certain place or style.

hypertext

A term coined by Ted Nelson around 1965 for a collection of text documents or "nodes" containing cross-references or "links" which allow the reader to move easily from one document to another.

image maps

An image in an HTML document with "hot spots" which act as anchors or links to other information. You need to click on a certain area in order to follow the link.
For example, an image of a map of the world might provide links to resources related to different countries. Clicking on a certain country would connect to the relevant information.
(See also client-side and server-side image maps.)

impairment

Loss or abnormality of physiological or anatomical structure or function of the body due to disease, injury, or genetic problem.

IMG

The tag used in HTML to include an in-line image in a page.
For example,

<IMG SRC="/pathname/image.gif" ALT="description of image">

in-line graphic

An image or graphic that is included within the contents of an HTML page.
A separate viewer is not needed to view the image, because it appears within the contents of the text or other images on the page.

Java

An object-oriented, general-purpose programming language developed by Sun Microsystems. Java supports programming for the Internet in the form of platform-independent Java "applets".

JavaScript

Sun's simple, cross-platform, World-Wide Web scripting language adopted by Netscape and allies. Its functionality is limited, as it is aimed primarily at enhanced forms and simple Web database front-ends.

JPEG (Joint Photographic Experts Group)

A graphic format often used to compress photographic data, best used for images with rich color or applied graphics format.
(There's more info about the differences between GIF and JPEG.
Click here for ftp://rtfm.mit.edu/pub/usenet/news.answers/jpeg-faq/part1, and click here for ftp://rtfm.mit.edu/pub/usenet/news.answers/jpeg-faq/part2)

learning disability

A condition of presumed neurological origin which selectively interferes with the development, integration, and/or demonstration of verbal and/or non-verbal abilities.

low vision

This is impaired vision or inability to see clearly or completely.
There are many different types of visual impairments, other than blindness, that can result in low vision. The major types are: lowered central acuity, distortion of vision, spots or floaters before the eyes, color distortions, field-of-vision defects, abnormal sensitivity to light, night blindness, and oscillopsia.

Lynx

A text-based browser developed at the University of Kansas.
(Click here for more info about Lynx: http://www.cc.ukans.edu/about_lynx/about_lynx.html.)

marquee

An HTML tag that scrolls a line of text across a section of a page.

non-embedded graphics

Graphics that require an external viewing application.

open caption/closed caption

A method of displaying subtitles on the TV, mainly for hard-of-hearing users.
"Open" refers to subtitles that everyone can see, and "closed" refers to subtitles that users must have the capability to see.

Portable Document Format (PDF)

A format that provides a way to capture a file, whether it be a text document or a Computer Aided Design (CAD), so that when viewed on different platforms by different people it maintains the same look and feel. These files are viewed with Adobe Acrobat and Adobe Acrobat Access plug-in.
(Click here for Adobe Acrobat main page, or click here for White paper on the Acrobat Access plug-in.)

physical disability

A physical impairment that prohibits a person from full movement or function of the body. Different types of physical disabilities include paralysis, weakness, and interference with control of the muscles and can be divided into two major groups: neuromuscular and skeletal.

PICT

A Macintosh graphic file format.

pipeline

The cables and wires that the bytes (computer information) flow through.

plug-in

A file containing data used to alter, enhance, or extend the operation of a parent application program. A plug-in is specific to a particular operating system and displays or interprets a particular file format such as Shockwave, RealAudio, Adobe PDF, Corel CMX (vector graphics). The file to be displayed is included in a Web page using an EMBED HTML tag. Plug-ins, both commercially and independently authored, are usually downloaded for free and stored locally.

Portable Network Graphics (PNG)

PNG provides small files and rapid previews to enhance the responsiveness of Web pages and to allow graphics to look the same on different platforms. One of its most attractive and unique features is its ability to store several pieces of text with an image.

(Click here for the "Canonical" PNG site, or click here for information from the World Wide Web Consortia.)

QuickTime

Apple Computer's standard for integrating full-motion video and digitized sound into application programs.

sensory disability

An impairment of any of the senses: sight, hearing, smell, touch, or taste.

screen reader

Software that translates Graphical User Interfaces (GUIs) to textual forms which are either read out loud and heard through synthesized speech or read with refreshable Braille displays.

server

A combination of hardware and software that responds to client requests. Clients are applications such as browsers that ask the server for information such as the contents of HTML pages.

sound file or sound track

A stream of audio data that is presented on its own or is synchronized with a video stream.

source material or documents or code

The HTML code which designates the format and output viewed on a Web page;
HTML source pages.

speech disability

An inability to communicate effectively through speech because of muscular or cognitive impairments.

style sheets

These describe how documents are presented on screens, in print, or perhaps how the words are pronounced.
A designer can redefine how a browser interprets and displays basic HTML.
(Click here for how designers define style sheets at http://www.w3.org/pub/WWW/Style/ .)

tables

An HTML syntax consisting of rows and columns used to lay out information.

text anchor

A word or phrase which is the source or destination of a link. Clicking with the mouse on an anchor causes the link to be followed and the anchor at the opposite end of the link to be displayed. Text anchors are usually underlined and blue.
(See also image anchor.)

text-only version (text-only page)

An alternate form of a Web page that only presents text. It is commonly used with complicated graphical pages to decrease download time and increase the ease of interpretation by people unable to view graphics.

thumbnail picture

A reduced size version of an image that acts as an anchor to the full-size version.

TIFF

A generic graphics file format.

video track

A data stream that contains video information. This can be synchronized with the audio track and captioning track in movies.

viewers

Software applications that interpret formatting codes, such as those in HTML files, to display an object. A browser, such as Netscape, Microsoft Internet Explorer, or NCSA Mosaic, is a commonly used application to view World Wide Web information.