Web Site Accessibility Guidelines

Web Access Symbol (for 
people with disabilities)

Version 7.2
June 1997 (amended 06 December 2017)

Compiled by:

Gregg C. Vanderheiden Ph.D., Wendy A. Chisholm,
Neal Ewers, Shannon M. Dunphy
Trace R and D Center, University of Wisconsin - Madison

with contributions from:

Jane Berliss, David Clark, Paul Fontaine, Geoff Freed,
Larry Goldberg, Steve Jacobs, Peter Korn, Josh Krieger, Chuck Letourneau,
Mike Paciello, Pat Powers, Jan Richards, Paul Wilson,

(If you have contributed and your name or organization is missing
from the above list, inform us via the below e-mail address so that
we may correct our omission - and we apologize in advance.)

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.

(This is a living document. Comments and suggestions are solicited.

Click here to mail us at Web-team@trace.wisc.edu.)


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.

To access other portions of this document, click on one of the following 12 topics:
1. Contents 2. Quick Reference 3. Introduction 4. Text
5. Page Layout 6. Graphics 7. Multimedia 8. User Interaction
9. Formats 10. Testing 11. Appendix 12. Glossary
Click here to mail us comments and suggestions: web-team@trace.wisc.edu.


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:

Text Anchors


  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:

Text Layout


Solution Strategies:

Testing Tips:

Solution Strategies in the Future:

Bitmap Text


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:

Text Size


Solution Strategy:

Text Color


Solution Strategies:

Punctuation and Symbols


Solution Strategy:

Text that Changes or Moves


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).
  • To access other portions of this document, click on one of the following 12 topics:
    1. Contents 2. Quick Reference 3. Introduction 4. Text
    5. Page Layout 6. Graphics 7. Multimedia 8. User Interaction
    9. Formats 10. Testing 11. Appendix 12. Glossary
    Click here to mail us comments and suggestions: web-team@trace.wisc.edu.


    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.



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

    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:



    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:

    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.



    Solution Today:



    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


    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:

    To access other portions of this document, click on one of the following 12 topics:
    1. Contents 2. Quick Reference 3. Introduction 4. Text
    5. Page Layout 6. Graphics 7. Multimedia 8. User Interaction
    9. Formats 10. Testing 11. Appendix 12. Glossary
    Click here to mail us comments and suggestions: web-team@trace.wisc.edu.


    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


    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:

    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:
    9. <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:

    Separate Viewer-Based Graphics


    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


    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>



    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).
    2. 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).

    3. 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.
    4. 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.)

    To access other portions of this document, click on one of the following 12 topics:
    1. Contents 2. Quick Reference 3. Introduction 4. Text
    5. Page Layout 6. Graphics 7. Multimedia 8. User Interaction
    9. Formats 10. Testing 11. Appendix 12. Glossary
    Click here to mail us comments and suggestions: web-team@trace.wisc.edu.


    There are 2 subtopics:

      1. Audio Clips
      2. Movies

    Audio Clips


    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.


      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.


    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:

      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:

    To access other portions of this document, click on one of the following 12 topics:
    1. Contents 2. Quick Reference 3. Introduction 4. Text
    5. Page Layout 6. Graphics 7. Multimedia 8. User Interaction
    9. Formats 10. Testing 11. Appendix 12. Glossary
    Click here to mail us comments and suggestions: web-team@trace.wisc.edu.

    User Input and Interaction

    There are 2 subtopics:

      1. Forms.
      2. Java.



      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.



    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>

    To access other portions of this document, click on one of the following 12 topics:
    1. Contents 2. Quick Reference 3. Introduction 4. Text
    5. Page Layout 6. Graphics 7. Multimedia 8. User Interaction
    9. Formats 10. Testing 11. Appendix 12. Glossary
    Click here to mail us comments and suggestions: web-team@trace.wisc.edu.

    Non-Standard Formats

    Custom Data Structures and Viewers


      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.

    To access other portions of this document, click on one of the following 12 topics:
    1. Contents 2. Quick Reference 3. Introduction 4. Text
    5. Page Layout 6. Graphics 7. Multimedia 8. User Interaction
    9. Formats 10. Testing 11. Appendix 12. Glossary
    Click here to mail us comments and suggestions: web-team@trace.wisc.edu.


    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.
    To access other portions of this document, click on one of the following 12 topics:
    1. Contents 2. Quick Reference 3. Introduction 4. Text
    5. Page Layout 6. Graphics 7. Multimedia 8. User Interaction
    9. Formats 10. Testing 11. Appendix 12. Glossary
    Click here to mail us comments and suggestions: web-team@trace.wisc.edu.


    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 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.
    2. Click here--Only image map links in D-link page.

    3. 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.
    4. Click here--All links included in D-link page.

    5. 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.
    6. Click here--One page with ALT-TEXT, D-links, text anchors.

    7. 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.
    8. Click here--Only a return link in D-link page.

    9. 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.
    10. 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.


    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.


    Would most likely be read:

    link2, link1, link3

    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.

    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.

    To access other portions of this document, click on one of the following 12 topics:
    1. Contents 2. Quick Reference 3. Introduction 4. Text
    5. Page Layout 6. Graphics 7. Multimedia 8. User Interaction
    9. Formats 10. Testing 11. Appendix 12. Glossary
    Click here to mail us comments and suggestions: web-team@trace.wisc.edu.


    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


    Many of these definitions are modified or completely lifted from the following 3 sources (click to choose):

      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.

    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.

    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

    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.

    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.

    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.

    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)

    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.

    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).

    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.)

    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.

    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.)

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

    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.

    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".

    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.

    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.)

    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.

    A Macintosh graphic file format.

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

    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.)

    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.

    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/ .)

    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.

    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.

    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.
    To access other portions of this document, click on one of the following 12 topics:
    1. Contents 2. Quick Reference 3. Introduction 4. Text
    5. Page Layout 6. Graphics 7. Multimedia 8. User Interaction
    9. Formats 10. Testing 11. Appendix 12. Glossary
    Click here to mail us comments and suggestions: web-team@trace.wisc.edu.