ADVANCED DRAFT COPY

January 20, 1998

 

Compiled by:
Gregg C. Vanderheiden Ph.D., Wendy A. Chisholm, M.S.,
Trace R and D Center, University of Wisconsin – Madison
For the Web Accessibility Initiative Guidelines Working Group

(This is a final Trace Center Guidelines Document.
It is compiled in preparation for transfer of the Guidelines to the Web Accessibility
Initiative of the W3C.
This guideline reflects recent work of the WAI as well as previous contributions of many
other guidelines developers (listed in the appendix)).  
Contributors include: Jim Bell, Jane Berliss, Harvey Bingham, Judy Brewer, Kevin Carey,
John Churchill, David Clark, Dan Connolly, Daniel Dardailler, Judith Dixon, Martin Durst,
Paul Fontaine, Geoff Freed, Alfred S. Gilman, Larry Goldberg, Jon Gunderson, Markku
Hakkinen, Scott Isaacs, Scott Isensee, Jun Ishikawa, Steve Jacobs, Phill Jenkins, Alan
Karben, Hiroshi Kawamura, George Kerscher,  Peter Korn, Josh Krieger, Chuck
Letourneau, Edmund MacKenty, Murray Maloney, Aya Matsui, Gabriel Michel, Jim Miller,
Masafumi NAKANE, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Dave
Ragget, T.V. Raman, Jan Richards, Madeleine Rothberg, Jutta Treviranus, Steve Tyler, Jaap
Van Lelieveld,  Jason White, Tom Wlodkowski, ATRC, CAST, InfoUse, NCR, WGBH, WINGS,
YRIF, and the WAI IG and GL Working groups

(If you have contributed and your name or organization is missing
from the above list, inform us via e-mail 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
The US Postal Service’s WINGS project and
the NCSA-PACI Universal Design / Disability Access Project.

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

---

Table of Contents

1. About version 8 of the Unified Web Site Accessibility Guidelines
   1. Introduction
   2. Purpose of Version 8
   3. Format of Version 8
   4. Simplifying the Guidelines
   5. Input Requested
2. Introduction to web site accessibility
3. [Place holder for “On SGML and HTML “]
4. Definitions and Conventions
   1. Definitions
   2. Types and encoding of recommendations
5. [Place holder for “HTML Document Representation – Character sets, character encodings, and entities“]
6. [Place holder for “Basic HTML data types – Character data, colors, and lengths“]
7. The global structure of an HTML document – The HEAD and BODY of a document
   1. Page Titles
   2. Metadata
8. Language information and text direction -International considerations for text
9. Text – Paragraphs, Lines, and Phrases
   1. Text formatting
   2. Acronyms
   3. Punctuation, symbols and ASCII art
   4. Text that changes or moves
10. Lists and Outlining – Unordered, Ordered, and Definition Lists
    1. Helping users navigate lists effectively
11. Tables
    1. Comprehension and navigation of table elements
12. Links – Hypertext and Media-Independent Links
    1. Links read out of context
    2. Identifying links within a sentence
    3. Several links read as one
    4. Methods for linking to alternate pages
    5. Use of graphics decreases cognitive load and increases target area.
    6. Page abstracts
    7. Keyboard shortcuts for links
13. Objects, Images, Audio, and Applets
    1. Introduction to the issues
    2. General recommendations
    3. Images and image maps
    4. Applets
    5. Audio and video
14. Style Sheets – Controlling the presentation of an HTML document
    1. Style sheets solve several issues, but only if users can override
15. Alignment, font styles, and horizontal rules
    1. Providing additional cues with horizontal rules
16. Frames – Multi-view presentation of documents
    1. Misinterpretation by screen readers and small screen users
17. Forms – User-input Forms: Text Fields, Buttons, Menus, and more
    1. Navigation and manipulation
    2. Graphical buttons
18. Scripts – Animated Documents and Smart Forms
    1. Introduction to the issues
       1. Action occurring away from user focus
       2. Actions executed during load of page
       3. Automatic update of page (“push”)
       4. Summary of issues
19. [Place holder for “SGML reference information for HTML – Formal definition of HTML and validation“]
20. [Place holder for “SGML Declaration of HTML 4.0”]
21. [Place holder for “Document Type Definition”]
22. [Place holder for “Transitional Document Type Definition”]
23. [Place holder for “Frameset Document Type Definition”]
24. [Place holder for “Character entity references in HTML 4.0”]
25. Good Web Site Design Practices
26. Appendices
    1. Design Notes
       1. Alt-text
       2. Alternate pages
27. References

 

---

1. About Version 8 of the
Unified Web Site Accessibility Guidelines

1.1 Introduction

The 8 series of website accessibility guidelines is the final set of unified guidelines prepared by the Trace Center. The Web Access Initiative (WAI) of the World-Wide-Web Consortium (W3C) has been launched, and the development of HTML guidelines is being transferred to that body. The Trace Center will be continuing to work with and as a part of the WAI. As a result, the Trace Center will no longer be developing or maintaining this Unified Website Accessibility Guideline series. Readers are referred to the W3C site (http://www.w3.org/wai) for the latest version of the guidelines.

1.2 Purpose of Version 8

p align=”left”>The primary purpose for compiling Version 8 is to bring together all of the information, notes, and ideas that the Trace Center has been able to locate (see appendix for listing of guidelines we were able to locate). This version also takes into account decisions and directions that were taken at the August 1997 WAI working group meeting, as well as recent discussions by the working groups on-line (although at the present time, some of those discussions have not reached conclusion).

 

1.3 Format of Version 8

Version 8 has been completely restructured from previous versions. Part of this was to reflect decisions or directions in which the WAI decided that it would like to take the guidelines at the August meeting. The greatest restructuring, however, has been done so that these web guidelines would directly follow the structure and numbering of topics in the new HTML 4.0 specification. In fact, in order to maintain the numbering, there are several sections in this document that have almost nothing in them, or are just place holders to keep the numbering aligned between these guidelines and the HTML 4.0 specification.

This document is actually one of a series of documents that make up the Unified Website Design Guidelines 8. The full set of guidelines include:

1. Web Access: Why Is It Important? (in 2 pages or less)
   A brief introduction to the issues around web access for executives responsible for websites
2. Understanding Disabilities and Web Access Issues
   A discussion of the different types of disabilities and their effect on access to the web
3. A series of Check Lists
   • Checklist for web authors – about two printed pages
   • Checklist for user agent (browser) developers
   • Checklist for web server developers
   • Checklist for web tool developers
4. A series of Guidelines
   • Guidelines for web authors – about six printed pages
   • Guidelines for user agent (browser) developers
   • Guidelines for web server developers
   • Guidelines for web tool developers
5. The Unified Website Access Guidelines Central Reference Document
   Presentation of web access issues along with solution strategies for web authors, browser developers, server developers, and tool developers, all in an integrated document so that the issues and the interactions between the authors, browsers, and tools may most easily be seen.
6. Web Access Resource Site
   A website containing extended discussions, case studies, demonstrations, tools, references to other guidelines and efforts related to web access, etc.

1.4 Simplifying the Guidelines

In putting together these guidelines, we have tried to keep in mind that the simpler the guidelines were, the easier they would be to understand and follow. Unfortunately, HTML, formatting, and the Web are becoming increasingly complex. Also, browsers are introducing new elements and options. These present both opportunities and complications. In addition, we need to take into account the fact that although some of the pages out there on the Web will be using the new features, there is still a legacy of pages using old techniques, only a small portion of which will probably ever be updated and reformatted. We are therefore trying to follow the advice of Albert Einstein, who said "Everything should be made as simple as possible, but no simpler." This first draft is an attempt to reach our objective. In it, we have tried to incorporate all of the new information and strategies, and to present them in as straightforward and useful a fashion as possible. Our goals in this first version are therefore: correct, complete, simplify, in that order. In fact, since this set of guidelines is being used as a central reference point by so many, we need to always maintain that order. However, we recognize the need for simplicity, and that will be a primary focus, particularly of the short form and checklist versions.

C2S2 Approach

The Trace Center has also launched what they call a "C2S2 Project." This stands for the "Comprehensive Cross-Segment Strategy Project." In a nutshell, this project seeks to identify and define a way that different industry segments (authors, user agent [browser] developers, and assistive technology developers [e.g., screen reader manufacturers]) can coordinate their efforts. The goals of this cooredination are:

1. To minimize the effort needed by page authors to make their sites accessible.
2. To maximize the flexibility and creativity of page authors to create web-based environments.

For example, currently, page authors have to follow several rules that are not necessary if some basic capabilities or options were built into browsers and screen readers. C2S2 seeks to work with all of the segments to identify a cooperative strategy that divides up the access issue and identifies ways that the different industry segments could cooperate to minimize the number of guidelines and amount of effort needed. These guidelines reflect and help support the C2S2 approach by identifying, under each issue, the strategies and approaches that could be taken by all of the industry segments to help address the access issue. More information on the C2S2 project is available at http://trace.wisc.edu/docs/c2s2/c2s2.htm.

1.5 Input Requested

As always, any and all comments on this draft are solicited. This 8 series, however, will formally freeze on November 10. At that point, the guidelines in their current form will be formally transferred to the WAI, which will then, per previous decision, use them as a basis for developing the formal WAI guidelines. Once the W3C/WAI guidelines are released, these guidelines will be archived and website authors will be directed to the W3C/WAI guidelines.

 

---

2. Introduction to Web Site Accessibility

 

---

2.1 Profiles of users with disabilities

Sensory disabilities – vision, audition

Low vision – There are many types of low vision, including poor acuity, tunnel vision, clouded vision, floaters in the eye, peripheral vision, etc. Some people with low vision need to enlarge the text fonts and images, and may use use a dual (i.e., partial) or full screen magnifier.

Note, low vision users may still encounter difficulty deciphering information on the computer screen even when magnified due to:

1. magnifying small fonts or images may cause pixelation and/or distortion ;
2. magnified areas tend to loose contextual information (tunnel vision effect doesn’t allow user to "see" what information or choices are around the magnified area).

Blindness – People are legally blind when they have less than 20/200 vision in the better eye after correction, or less than a 20 degree field of view in the better eye after correction. Individuals who are blind rely primarily on screen readers to read the text on the screen. For graphic elements, they rely on the presence of a text description of the image (and any text that is included as an image in the document).

Hard of hearing – A person whose hearing is less severely impaired than deafness is said to be hard of hearing.

Deafness – A person is considered deaf when sound must reach at least 90 decibels to be heard at all and even amplified speech cannot be understood. Normal conversation is approximately 40 to 60 decibels.

Physical disabilities – paralysis, fine-motor skills

There is a tremendous variety of physical disabilities. In addition to the usual range from minor to severe involvement, there are also many different types of physical disabilities. In order to better understand its breadth, it is useful to break this category into two major areas: neuromuscular and skeletal. Neuromuscular impairments include any impairments that relate to the nervous system (including the brain) or the muscles. For example, most speech impairments fall into this area. Skeletal impairments relate to the bones, joints and missing limbs.

Although there are many specific types of neurological impairments, their effects can be characterized as variations or combination of:

• Paralysis – This lack of any muscular control and often sensation in part of the body. This is usually caused by a break in the nerves leading to the muscle, often in the spinal cord.
• Paresis – Weakness or inability to produce small, controlled or forceful movements. This can be caused by problems with the signals sent to the muscles via the nerves, problems with the muscles themselves, or problems due to pain when movements are made (as in the case of severe arthritis).
• Interference with Control – This interference can take different forms. The term spasticity is used if the muscles are tense and contracted and voluntary movements is very difficult. Ataxia refers to problems in motor programming and coordination. Athetosis and Chorea refer to constant or uncontrolled motion (i.e. extra, involuntary movements).

Cognitive disabilities – learning, attention deficit

These disabilities result from some type of damage to the human brain. Therefore it is not surprising that there is a great complexity of impairments in this category. Cognitive disabilities can be divided into the following seven categories:

1. Impairments of Intelligence and Thinking
   1. Mental Retardation
   2. Dementia
2. Impairments of Memory
   1. Amnesia
   2. Memory illusions
   3. Forgetfulness
3. Other Intellectual Impairments
4. Aphasia
5. (Specific) Learning Disabilities
   1. Spoken language
   2. Written language
   3. Arithmetic
   4. Reasoning
6. Psychological impairments
7. Drug and Alcohol Dependence

 

---

3. [Place holder for “On SGML and HTML”]

 

---

4. Definitions and Conventions

4.1 Definitions

Assistive Technologies

Assistive technologies are products used to help people accomplish tasks that they can not accomplish otherwise. For example, eyeglasses assist those of us who can not see clearly. When dealing with computers and the world wide web, assistive technologies usually refer to software adaptations, specially designed hardware devices, and/or standard devices used in alternative ways which provide user access.

Screen reader

A software program that reads the contents of the screen aloud to a user. Used primarily by individuals who are blind, screen readers can only read text that is printed, not painted, to the screen.

Screen magnifier

A software program that magnifies a portion of the screen, so that it can be more easily viewed. Used primarily by individuals with low vision.

ShowSounds and SoundSentry

Individuals who are deaf or hard-of-hearing can set the "ShowSounds" and "SoundSentry" flags on some operating systems such as Windows95/NT. If the SoundSentry flag is set, whenever the computer makes a sound, a user chosen visual indication is provided on the screen. Any programs which have significant aural or spoken content should check to see if the ShowSounds flag is turned on. If it is, these programs should also provide all significant aural content in a visual format (e.g., closed captions).

Scanning Software

Software that highlights (and/or announces) selection choices (e.g. menu items, groups of possible phrases, etc.) one at a time. A user selects a desired item by hitting a switch when the desired item is highlighted/announced. Used primarily by individuals with severe physical or cognitive disabilities.

Alternate Keyboards

Hardware/software devices that provide an alternate way of creating keystrokes that appear to be coming from the standard keyboard. On-screen keyboards, speech input, eyegaze keyboards, and sip-and-puff (Morse code) keyboards are some examples. Used primarily by individuals with disabilities that prevent them from using the standard keyboard (and usually from using the mouse as well). Programs that can be operated entirely from the standard keyboard (and don’t require the mouse) can be used by individuals with alternate keyboards.

Braille and Dynamic Braille

Braille is a technique involving six dots which are raised in different patterns to represent letters and numbers so that they can be read by people who are blind using their fingertips. Grade II braille includes additional codes that represent common letter groupings (e.g., "th," "ble") to make braille more compact. An 8-dot version of braille has been developed to allow all ASCII characters to be represented. Dynamic braille involves the use of a display where dots can be raised and lowered dynamically to allow any braille words to be displayed. Only letters and numbers can be represented in braille, although some braille printers have a utility that allows simple graphics to be drawn on a sheet using the raised dots at a resolution of approximately 11 dots per inch.

The word “Accessible” in Braille.

The word “Accessible” in Grade II Braille.

---

4.2 Types and encoding of recommendations

 

Rating System

[Required]   – Required for some groups of users to access the information on a page.

[Recommended] – Makes page easier to understand and use.

Classification System

[Interim] – Strategies needed to make pages accessible for today’s browsers and assistive technologies

[New] – Strategies that will take advantage of new features being incorporated into supported tomorrow’s browsers and assistive technologies (which incorporate Web Access Initiative recommendations).

If a recommendation has several possible strategies, the strategies are classified, if not the recommendation itself is classified.  Those recommendations and strategies that have no classification work for both old and new browsers.

Recommendations for different groups

There are several pieces of the puzzle that need to be put together for a single page to be accessible. This document focuses mainly on what page authors should be doing to ensure that browsers render the page as maximally accessible as they can. We do offer suggestions for browser and assistive technology designers, and even a few hints for users. The following headings are used throughout the document:

1. Recommendations for page authors – issues to behandled in source documents
2. Recommendations for user agent (browser) designers – issues to be handled by browsers
3. Recommendations for Assistive Technology designers – issues to be handled by screen readers, screen magnifiers, scanning software, etc.
4. Suggestions for Users– configuring the useragent and assistive technology for maximum benefit.

 

---

5. [Place holder for “HTML Document Representation”]

6. [Place holder for “Basic HTML data types”]

---

7. The global structure of an HTML document

The HEAD and BODY of a document

---

7.1 Page Titles

Issue:  Meaningful titles should be associated with each page not only because they are required in HTML 4.0, but users will more easily identify bookmarked pages. Most browsers will use the address of a web page if no title is provided.

Recommendations for page authors

Design Tip:  Use the TITLE element in the HEAD of each document.
For example, <HTML><HEAD>...<TITLE>Version 8 of the Unified Web Accessibility Guidelines</TITLE>...</HEAD>...

---

7.2 Metadata

There are many recent developments on this front that are still being discussed. Hopefully, in the near future, authors will be able to associate a variety of metadata with their pages. Stay tuned.

---

8. Language information and text direction

International considerations for text

---

 

---

9. Text

Paragraphs, Lines, Phrases,

Punctuation and Symbols

1. 9.1 Text formatting
2. 9.2 Acronyms
3. 9.3 Punctuation, symbols and ASCII art
4. 9.4 Text that changes or moves

---

9.1 Text formatting

Issues: There are four issues with the presentation of text:

1. Authors often use color, font style (e.g. bold or italic) or font changes to highlight certain words or to make a page easier to read visually (e.g. headings are italicized, outdented, a larger font and bold).  While this often makes the page easier to read visually, it is either lost in the aural presentation or makes the aural presentation confusing.  In some instances, important information is being conveyed through the typographics used and is lost to the auditory user.  The following is an expansion of the issues:
   1. Color, font or font size – These typographic attributes often highlight a section of text.  For example,  to signify a heading, or to emphasize an important statement.  Since most screen readers read all text in the same manner, no matter what visual attributes they possess, the meta information given in the example is lost.  Headings not only make it easier to skim through a page, they signify that a major change in context has just occurred and give the new context a "handle."   The loss of this information can make a document harder to understand.
   2. Indentation – Indentation is usually used to order or to group items.  Most screen readers do not indicate how much space precedes or follows text.  The issues are discussed in greater detail in the section on Lists.
   3. Drop-caps, subscripts and superscripts.  Current screen readers might interpret words or letters as appearing on a separate line.
2. Users need to  adjust text size for easier viewing if they have low vision. Changing the text size often makes the page unreadable due to changes in layout.
3. Although users can override the color settings of HTML pages to alleviate poorly contrasting colors,  formats such as Portable Document Format (PDF) prevent this. Also, some users may not yet be aware that they have this ability.
4. Screen reading software cannot make sense of bit-mapped text since it is perceived as graphical information. One of the most common examples of bitmap text is the counter that records the number of accesses to a certain page. For example, a text-only browser or screen reader might say the word "image" when it encounters a graphic.   Reading a page with a graphical counter would sound like, "You are visitor number (image) to visit this site" or "The number of visits to our site this month is (image)."

Elements affected:   EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, BLOCKQUOTE, Q, IMG, FONT, SUB and SUP

Recommendations for page authors

1. [Required]

     Use style sheets: [New]

   • to create drop caps, subscripts and superscripts
   • to highlight sections of a document with font size, formatting or color
   • rather than converting text to images or alternative text file formats(such as PDF)
2. [Recommended]
     Use logical styles rather than physical markups.  Do no misuse logical elements.
   Logical: DFN, EM, CITE, CODE, KBD, SAMP, STRONG, VAR, H1, H2, etc.
Physical: size=14, B, I.
   This makes it easier for users to adjust the look of the screen (e.g., larger print, color contrast, etc.) when they apply their own style sheets or for browsers to adjust the presentation of the document based on user settings. The other advantage of logical elements is that they help enforce consistency in your documents.  It also leaves open the possibility for more sophisticated uses of the semantic encodings in the future.  For example, the Lycos indexing system can take advantage of semantic encoding to create abstracts of documents. Alternatively, browsers can navigate through a document by  logical styles, such as headers. Only use logical elements for what they represent.  For example, avoid using <cite> to undent a paragraph.
3. [Recommended]
     Avoid using the BLINK and MARQUEE elements. [Interim]
   Use another method to draw attention to text such as text size or color.
4. [Recommended]
     Properly nest headings. (Use style sheets for formatting [New] ).
   Users with dyslexia may have problems reading long pages and will be helped if the design facilitates scanability by proper use of headings. This also benefits us all, as we scan through pages via the headings. Tagging these correctly means that user agents can provide navigation through the structure.

Testing tips

• To test if the text and background contrast is sufficient enough to be read by people with color deficiencies or on low resolution monitors, view your pages with a monochrome

  monitor.

• To get a better understanding of what a screen reader would present to a user, do not load the images on a page when viewing with a graphical browser or use a text-based

  browser such as Lynx.

Recommendations for user agent (browser) designers

1. Allow user-selected style sheets to override the page author’s settings.
2. Support navigation between different size “chunks.”

   For example, allow the user to jump between links, or level 2 headings, or by sentence, or whatever they choose.

Recommendations for assistive technology designers

If user agents do not support the previous recommendation, then that functionality should be implemented here (although this requires parsing of HTML).

Suggestions for users

1. Make use of existing (or create your own) Aural Cascading Style Sheet (ACSS) to interpret the page constructs as you desire.
2. To translate PDF files, download Adobe’s plug-in for windows or retrieve documents through their proxy. For more information, go to the Adobe site at http://access.adobe.com/.

---

9.2 Acronyms

Issue: Acronyms may be unfamiliar to readers or interpretted incorrectly based on previous experience.  For example,  "CID" can stand for "Central Institute for the Deaf, " "Charge Injection Device," "Computer Integrated Design," or   "Configuration/Installation/Distribution"  depending on your context.  For disability access, screen readers may not recognize the phrase as an acronym and might make a best guess at pronouncing it.  Not only can this sound ridiculous, it can be confusing.

Element affected:  ABBR

Recommendations for page authors

Design Tip:  Use the "title" attribute for acronyms and abbreviations <abbr>title="World wide web">WWW</abbr>

Recommendations for user agent (browser) designers

Make title information available or present it inline if requested by the user.

 

---

9.3 Punctuation, symbols and ASCII art

Issue:  Screen reading software will often either ignore or read each name for punctuation used to make an emoticon or ASCII art.  For example, the smiley emoticon 🙂 would either be ignored or read as "colon dash close parentheses."

Text symbols affected: all punctuation and letters that are used to make emoticons, symbols or ASCII art

Recommendations for page authors

Design Tip:  Avoid using ASCII art or replace it with an image and alternative text.
Common typographic characters or constructions to be avoided are emoticons, arrows consisting of dashes and greater than signs –>, etc..

 

---

9.4 Text that changes or moves

Issue:  Text that changes or moves is either read incorrectly or not at all by screen readers, can adversely affect people with cognitive disabilities, and is often annoying to people in general (see Jared Spool’s book, "Web Site Usability").  For example, a user with attention deficit disorder might find it hard to focus on the rest of a page while blinking or scrolling text is present. Another example, marquee text, is often read by most current screen readers (which do not interpret the HTML) one letter at a time as it appears on screen. Therefore, the visible words and characters of the message will be repeated each time a new letter appears. For example, the message "Have a nice day,"  scrolling left to right:

Elements affected: BLINK, MARQUEE, as well as programming or scripting languages, such as Java and JavaScript.

Recommendations for page authors

1. [Required]
     Provide a mechanism for the user to freeze any moving or blinking text.
   In the following example created by Mark Novak, if the user presses the escape key while the Java marquee has focus, the text will be displayed statically. View the example.
2. [Recommended]
     Avoid using the BLINK and MARQUEE elements. [Interim]
   Use another method to draw attention to text such as text size or color.

Recommendations for user agent (browser) designers

Allow users to view BLINK and MARQUEE phrases as static text.
This goes for all animations and interactions. See the sections on Applets and Scripts for more information.

Side note: MARQUEE is a MSIE3.0 element, while BLINK was introduced in Netscape 1.1.  Therefore, neither are considered standard HTML. 

 

---

10. Lists and Outlining

Unordered, Ordered, and Definition Lists

---

10.1 Helping users navigate lists effectively

Issue:  Non-visual users often "get lost" in lists, especially those with several layers of embedding and those which lack discernible cues to indicate the specific level of indentation for each item. In addition, it is often difficult for non-visual users to know where the list itself begins and ends and where each  list item starts. Further, if a list entry wraps to the next line, it may appear to be two separate items in the list.

For example, imagine stripping the indentation and bullets from a list of items I keep in my desk:

• writing utensils.
  • pens
    • highlighters
      • red
      • green
      • blue
    • ball-point
      • green
      • purple
      • blue
  • pencils
    • #2 lead
    • soft lead
• erasers

It might be read like this by a screen reader:

writing utensils.
pens
highlighters
red
green
blue
ball-point
green
purple
blue
pencils
#2 lead
soft lead
erasers

Elements affected: OL, UL, LI, DL, DD, DT, BLOCKQUOTE

Recommendations for Page Authors

1. [Recommended]   Correctly encode list structure and list items with proper HTML elements (UL, OL, LI). (Use style sheets to adjust item spacing [New]).
   
2. This is an ongoing topic of discussion, stay tuned for developments.

Tips and tricks:

1. Using a numbered (ordered) list makes it easier for people accessing the page auditorally to keep track of where they are within a list.

Recommendations for user agent (browser) designers

1. Introduce each list by indicating how many items it contains.
   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. 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.
2. Allow the user to configure how nested lists should be enumerated and presented.
   This includes allowing the user to choose to view all text in a left-justified format if they so desire or to associate an aural cue with different levels (via alternate aural cascading style sheets).

 

---

11. Tables

 

---

11.1 Comprehension and navigation of table elements

Issue 1:  Newspaper columns. Tables are often used to layout pages of text in newspaper columns.  Most current screen readers (which do not interpret the HTML) read all the way across the page reading sentences on the same row from different columns as one sentence.

For example:

 

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

Issue 2:  Spreadsheets and calendars. Tables are often used to layout text and numbers.  The screen reader may append all of the numbers from different columns in the same row into one large number if spaces and punctuation are not provided.

Issue 3:  Alt-text that wraps. If the alt-text of graphics laid out in a table wrap, then the "column effect" described above will occur, making the table difficult or impossible to decipher. For example, tables are often used to layout graphics to create navigation bars.  In this instance the alt-text for an image might be wrapped to fit the width of the column that it is placed in.  The following table represents what a reader might see if images were not viewed on an example opening page:

Since each of these cells represents a graphic, and each graphic is a link to another page, a user tabbing through the page might hear:
"Welcome to our" [tab] "Sponsored by" [tab] "site" [tab] "XYZ company" [tab] "Help" [tab] "Search" [tab] "Products" [tab] "Games and" [tab] "project and" etc.

Issue 4:  In all of these instances, it is very difficult to comprehend the semantics of the table since navigation through a table with most current screen readers (which do not interpret the HTML) is so limited.  The user is forced to navigate by sentence, without the options to navigate by row, column or cell.

Elements affected:   TABLE, CAPTION, THEAD, TFOOT, COLGROUP, TBODY, TH, TD, TR, and their attributes

Recommendations for page authors

1. [Required]
     Explicitly associate table cells with row and column labels. [New]
   Future browsers and assistive technologies will be able to automatically translate tables into linear fashions if tables are tagged appropriately. 
   
   1. "headers" – The following example, shows how to associate header information with the "headers" attribute.  The "headers" attribute specifies a list of header cells (row and column labels) associated with the current data cell.  This requires each header cell to have an "id."

      <TABLE border="border" summary="This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar.">
<CAPTION>Cups of coffee consumed by each senator</CAPTION>
<TR>
<TH id="t1">Name</TH>
<TH id="t2">Cups</TH>
<TH id="t3" abbr="Type">Type of Coffee</TH>
<TH id="t4">Sugar?</TH>
<TR>
<TD headers="t1">T. Sexton</TD>
<TD headers="t2">10</TD>
<TD headers="t3">Espresso</TD>
<TD headers="t4">No</TD>
<TR>
<TD headers="t1">J. Dinnen</TD>
<TD headers="t2">5</TD>
<TD headers="t3">Decaf</TD>
<TD headers="t4">Yes</TD>
</TABLE>

      A speech synthesizer might render this table as follows:

      Caption: Cups of coffee consumed by each senator
      Summary: This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar.
      Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No
      Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes

   2. "scope" – The following example associates the same header and data information as the previous example, but uses the "scope" attribute rather than "headers."  "Scope" must have one of the following values:  row, col, rowgroup or colgroup.  Scope specifies the set of data cells to be associated with the current header cell.  This method is particularly useful for simple tables.

      <TABLE border="border"
summary="This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar.">
<CAPTION>Cups of coffee consumed by each senator</CAPTION>
<TR>
<TH scope="col">Name</TH>
<TH scope="col">Cups</TH>
<TH scope="col" abbr="Type">Type of Coffee</TH>
<TH scope="col">Sugar?</TH>
<TR>
<TD>T. Sexton</TD>
<TD>10</TD>
<TD>Espresso</TD>
<TD>No</TD>
<TR>
<TD>J. Dinnen</TD>
<TD>5</TD>
<TD>Decaf</TD>
<TD>Yes</TD>
</TABLE>

2. [Required]
     Avoid using tables or <PRE> elements to arrange text documents in columns or otherwise layout a page. (Use style sheets to position graphics and text [New]).
   
3. [Recommended]  
     Provide abbreviations for lengthy row or column labels.   [New]
   Abbreviations should be short but meaningful.  This will be particularly useful for future speaking technologies that will read row and column labels for each cell.   Abbreviations cut down on repetition and reading time.  Refer to the examples given in the appendix.
4. [Recommended]  
     Provide summaries of tables. [New]
   Summaries of table structure and purpose are especially useful for non-visual users.  Refer to the examples given in the appendix.
5. [Recommended]  
     For more complex tables, group information into categories.   [New]
   Future browsers will allow users to select data from a table by asking for categories.  For example, a table contains information about several trips a person has recently made.  One of these trips is to San Jose.  Information on expenses for meals, hotels and transportation are recorded (each in their own column).  There are several locations (San Jose, Seattle, Madison).  The expenses can be grouped into an "Expenses" category and all of the locations into a "Location" category.  The following question could then be asked, "What were all of my expenses in San Jose?" This means "What are all the data cells in the "Expenses=Meals, Hotels, Transport" and "Location=San Jose" categories?

   The following example shows how to create categories within a table.

   <TABLE border="border">
<CAPTION> Travel Expense Report </CAPTION>
<TR>
<TH></TH>
<TH id="a2" axis="expenses">Meals</TH>
<TH id="a3" axis="expenses">Hotels</TH>
<TH id="a4" axis="expenses">Transport</TH><TD>subtotals</TD>
</TR>
<TR>
<TH id="a6" axis="location">San Jose</TH>
<TH></TH><TH></TH><TH></TH><TD></TD>
</TR>
<TR>
<TD id="a7" axis="date">25-Aug-97</TD>
<TD headers="a6 a7 a2">37.74</TD>
<TD headers="a6 a7 a3">112.00</TD>
<TD headers="a6 a7 a4">45.00</TD><TD></TD>
</TR>
<TR>
<TD id="a8" axis="date">26-Aug-97</TD>
<TD headers="a6 a8 a2">27.28</TD>
<TD headers="a6 a8 a3">112.00</TD>
<TD headers="a6 a8 a4">45.00</TD><TD></TD>
</TR>
<TR>
<TD>subtotals</TD><TD>65.02</TD><TD>224.00</TD><TD>90.00</TD><TD>379.02</TD>
</TR>
<TR>
<TH id="a10" axis="location">Seattle</TH>
<TH></TH><TH></TH><TH></TH><TD></TD>
</TR>
<TR>
<TD id="a11" axis="date">27-Aug-97</TD>
<TD headers="a10 a11 a2">96.25</TD>
<TD headers="a10 a11 a3">109.00</TD>
<TD headers="a10 a11 a4">36.00</TD><TD></TD>
</TR>
<TR>
<TD id="a12" axis="date">28-Aug-97</TD>
<TD headers="a10 a12 a2">35.00</TD>
<TD headers="a10 a12 a3">109.00</TD>
<TD headers="a10 a12 a4">36.00</TD><TD></TD>
</TR>
<TR>
<TD>subtotals</TD><TD>131.25</TD><TD>218.00</TD><TD>72.00</TD><TD>421.25</TD>
</TR>
<TR>
<TH>Totals</TH><TD>196.27</TD><TD>442.00</TD><TD>162.00</TD><TD>800.27</TD>
</TR>
</TABLE>


6. [Recommended]
     Ensure that alternative text does not wrap within tables used to position graphics. [Interim]
   Test for wrapping using the equivalent window size as that which can maximally fit on a 15-inch monitor using a common resolution such as 800×600 pixels.
7. TBD
     For tables of text and numbers, provide an alternative page which presents the table information in a linear fashion. [Interim]
   There are several ways to link to alternate pages which are described in more detail in Methods for linking to alternate pages.
8. [Recommended]
     Provide a phone or fax number or e-mail address if tables can not be made accessible.

Testing tips

• To predict how one of today’s screen readers might read your table, hold a piece of paper up to your monitor.  As you slide the paper down the monitor,  read the words above the line the paper creates as a sentence.  Ask another person to listen as you read the page out loud without pausing for column gaps.  Can he or she make sense out of what you have read?
• Another method, to predict how a screen reader will interpret your page, is to save it as a text-only file then open it with a word processing program.  This function is available in the "File" menu in most browsers.

Recommendations for user agent (browser) designers

1. Make cell, row and column information available.
   Semantic information is provided through attributes available for each entry in the table, the row and column information as well as the cell’s data contents. This will most likely emerge in the next HTML 4.0 specification as AXES, AXIS, and SCOPE attributes. As the draft solidifies we will provide more information about how to use the new attributes.
2. Provide methods to "unwrap" table information.
   How a table is unwrapped will be determined by which attributes are added to HTML 4.0. There has been considerable discussion about this in the WAI working groups and we will update this recommendation as soon as it is resolved.

Recommendations for assistive technology designers

1. Provide the ability to navigate by column, row and cell.
   
2. Provide orientation functions.
   To help the user determine which row or column they are in, and to establish how the current cell contents relate to the rest of the table, a "where am I" feature is needed.

 

---

12. Links

Hypertext and Media-Independent Links

1. 12.1 Links read out of context
2. 12.2 Identifying links within a sentence
3. 12.3 Several links read as one
4. 12.4 Methods for linking to alternate pages
5. 12.5 Use of graphics decreases cognitive load and increases target area.
6. 12.6 Page abstracts
7. 12.7 Keyboard shortcuts for links

---

12.1 Links read out of context

Issue: People who use screen readers to access the information on the web 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. Pages that use the same phrase for several different links (e.g. a series of "click here’s") are impossible to navigate solely by reading the links. Microsoft Internet Explorer 4.0 can create an overview of a page by presenting a list of just the links on the page. This might become a popular method to scan pages by everyone.

Element affected:  A

Recommendations for page authors

[Recommended]
  Create link phrases that make sense when read out of context (but they are not too verbose).
A user should be able to select a link from a list of all of the links on a page without reading the context in which the link was used. For example, using "click here" as the text phrase for several links requires a user viewing the page with a screen reader to scout out each link to determine the context before selecting one. However, replacing "click here" with something more descriptive solves this problem. For example, "download this document in ASCII text," "view the full version in HTML," or "to view the text version, click here."

Recommendations for user agent (browser) designers

1. Provide a feature that displays either:
   1. A list of links
   2. A list of links which each link followed by its surrounding text.
      For example, click here; To find out more about how the west was won, click here.
   3. OR A list of headers and links

 

---

12.2 Identifying links within a sentence

Issue: It is difficult for users of screen readers to identify links included within a sentence since there are no aural differences of how links are read versus other words. Visual users are able to detect links by color coding and underlining.

Recommendations for user agent (browser) designers and/or assistive technology designers

Provide an option to insert a character(s) or a blank line before each link or associate an aural cue with links.
Characters are one way of associating an aural cue with links, since it will be spoken by those using screen readers. However, this cue usually does not help determine where the link ends whereas a sustained background sound that is played during the reading of a link or a change in the pitch of the voice would.

 

---

12.3 Several links read as one

Issue:  Currently, lists of links are sometimes read as one link by most current screen readers (which do not interpret the HTML). Sometimes this happens even when the links are on different lines. The user is unable to position the mouse cursor on any of the specific links, making the links inaccessible.

Recommendations for page authors

[Recommended]
  Place non-link,  printable characters (surrounded by spaces)  between links which occur consecutively to keep separate links from being read as one by screen readers. [Interim]

Recommendations for assistive technology designers

Links should be spoken separately with pauses in between. 

 

---

12.4 Methods for Linking to alternate pages

Issue :  Oftentimes an alternate version of a page is available as a link from the current page.  Alternate pages can be text-only versions of a page, the page translated to another language, or a more succinct presentation of the information.

When creating text-only versions of pages, there are several issues to be aware of:

1. The text-only page might link back to a graphic-intensive page, which has an alternative link for a text-only page.  This hopping back and forth can dramatically increase the time required to navigate the site.  Especially if the link for the text-only version is buried in the page.
2. It is easy to see that creating text-only versions of every page on a site could double the number of pages that need to be maintained. Three methods for generating and maintaining text-only pages are described in the section Methods to create alternate pages found in Appendix A. Some of these methods generate text-only pages automatically.

Methods for page authors

1. Provide a visible link at the top of each page to allow a user to move back and forth between the graphic and alternate versions of the page, if they wish to do so.   [Interim]
2. Provide the appropriate information in the header of the page so that the browser loads it automatically.  [New]
   If the user has set his or her default media type to "speech" this will load the alternate page automatically:
<HEAD><LINK title="Text-only version" rel="alternate" href="text_only.html" media="speech"></HEAD>

Recommendations for user agent (browser) designers

Allow users to select a default media type (screen, print, projection, braille, or speech).
If a page is specifically created for their selected default media type, load the appropriate page automatically.

 

---

12.5 Use of graphics decreases cognitive load and increases target area

Issue: For web-surfers with some degree of motion impairment, selecting text links can be difficult because of the small target area and dexterity needed to select them with a mouse pointer. Therefore they, along with people with cognitive disabilities and people who cannot read well, often find that photos and graphics/icons make it easier to navigate and comprehend a site. While the use of graphics poses problems for users with visual disabilities, it may make it more obvious for someone else who has difficult reading and/or understanding the content. To learn more about how to make images accessible to people with visual disabilities, see the section Viewing and interacting with images and image maps. Keep in mind that the design of effective icons is not a trivial task due to the variety of possible interpretations by people based on personal differences.

Recommendations for page authors

1. Design Trick: Provide hyperlinks that use enlarged font sizes or graphical buttons to make the target area larger.
   However, make sure that you follow the guidelines for style sheets and alt-text so that you do not cause problems for people with visual disabilities.

Recommendations for user agent (browser) designers

1. Support "tabbing" between links.
   
2. Allow the user to select font color and size of text links.
   
3. Consider creating a bookmark function that allows a person to associate a picture with each bookmark.
   Selecting a favorite page then becomes a matter of locating the image they associate with it.

 

---

12.6 Page abstracts

Issue: It seems that it would be beneficial if metadata information could be stored with a link or retrieved separate from the entire page to provide a better picture of where the user is headed. Some information that might be helpful is a description of where the page going to, size of the page, purpose of the link, author, etc. Or, the creation of a page "abstract" that could be retrieved and viewed before the whole page was loaded.

Recommendations

There are no recommendations at this time. Further exploration is needed and solutions solicited.

---

12.7 Keyboard shortcuts for links

Design Trick: Provide keyboard shortcuts for links.
The "accesskey " attribute of <LABEL>, <A>, <CAPTION> and <LEGEND> allows an author to associate a keyboard shortcut with the phrase. For example, when associated with a link, it takes the user to the associated document.  <A accesskey="C" href="doc.html">Press C to go to XYZ page</A>

 

---

13. Objects, Images, Audio, and Applets

Multimedia in HTML documents

1. 13.1 Introduction to the issues
2. 13.2 In general
3. 13.3 Viewing and interacting with static images and image maps
4. 13.4 Viewing and interacting with applets
5. 13.5 Audio and video

 

---

13.1 Introduction to the issues

Multimedia provides the greatest number of barriers for the greatest number of people for the following reasons:

• Some users are unable to see images, movies or other types of animations CLEARLY either because they are colorblind, they have low vision, or they do not have a high resolution display.
• Some users are unable to view images, movies or other types of animations AT ALL either because their eyes are currently busy (they are driving), they do not have the proper software, have text-based software, have a slow data connection, are blind or very low vision, or they are accessing the information via phone interface.
• Some users are unable to hear movie sound tracks, audio clips or other types of audio information because they work in a loud environment (and the computer noises are masked by the environmental noises), work in a quiet environment (and need to turn the speakers off so as not to disturb others), do not have the proper software, hardware or enough memory to run the software, have a slow data connection, or are deaf or hard of hearing.

 

---

13.2 General Recommendations

The following recommendations apply to images, sounds and multimedia.

Elements affected:  OBJECT, IMG, APPLET, A

Recommendations for page authors

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).
   1. Avoid using similar hues together. For example, do not place blue-green lettering on a blue background. 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. For more information on color contrast for people with low vision and color deficiencies contact The Lighthouse, Inc. for their pamphlet Color Contrast and Partial Sight [(800) 334-5497] which is also available on the web at http://www.lighthouse.org/1lh32a.html.
   2. Design graphics with just 16 colors so that colors do not change across platforms, i.e. it might be unreadable on a different platform.
2. Make color coding redundant with other means of conveying information.
   For example, distinguish glossary words with the color red as well as with emphasis.
3. For troublesome pages, link to an alternative page
   Whenever you have trouble making a page directly accessible, provide a second version of the page which replaces any graphics, applets, movies or audio with text descriptions or transcripts and replaces buttons and other active areas with text links. There are several ways to do this which are described in more detail in Methods for linking to alternate pages (in Appendix B).

Recommendations for user agent (browser) designers

1. Allow users to designate whether they want to download and view multimedia and applets.
2. Display the alternate media associated with the element if the user selects not to view multimedia .
   This includes:

1. Alternate text for images.
2. Alternate text for each link of an image map (client side).
3. Alternate renderings for objects included with the OBJECT element. An HTML example is in the section on applets. Then an applet, either a movie, a still image or text description could be loaded based on the user’s preferences.
4. Transcripts for movies.
5. Transcripts or descriptions of audio clips.

Suggestions for users

If you have a slow modem connection (14400 kbps or less), are unable to see, or do not care to see multimedia or applets, your browser should provide a way to select whether or not you wish to download this information.  Lynx and other text-based browsers do not support graphics and you will not need to configure anything.

 

---

13.3 Images and image maps

Elements affected:  OBJECT, IMG

Recommendations for page authors

1. [Required]  
     Provide alternative text for all images and image maps. 
   All images should have alternative text that describes the function of the graphic. Examples of possible alt-text are, "Section Title: Banana Products," "Graph of population versus age," or "Search Button."  Possible solution strategies include:
   1. The "alt" attribute is mandatory for the <AREA> and <IMG> elements, but should also be used for <APPLET>, and <INPUT>. For example, <IMG SRC="logo.gif" alt="XYZ Logo">.
   2. [New] If <OBJECT> is used, text can be provided in the body of the <OBJECT> element.  For example, <OBJECT data="logo.gif"> XYZ Logo </OBJECT>

   Several tips and tricks concerning alternative text are in the appendix.

2. [Required]  
     Provide a link to a longer description (i.e., via D-link, or longdesc, etc.) for graphics that present important information (especially charts, tables and diagrams). (Include internal text in image file formats that support it).
   Alternative text descriptions (recommendation #1) are usually short and define the basic purpose of graphic elements. To describe the graphic itself in more detail a link to a longer description should be provided.
   1. [Interim] Provide a D-link next to the graphic that links to a page or a phrase at the bottom of the page with a longer description of the graphic. For example, <IMG SRC="97sales.gif" alt="Sales for 1997"><A HREF="sales.html">D</A>
   2. [New] Use the "longdesc" attribute of the <IMG> element or provide text within the body of the <OBJECT > element.  For example, <IMG SRC="97sales.gif" alt="Sales for 1997" longdesc="sales.html">

      The description found on the page "97sales.html" might read something like: "This chart shows how many widgets we sold in each of our four regions, North, South, East and West. In the North we sold 2,000 units. In the South 5,000 units. In the East 6,000 units and in the West 8,000 units."

      WGBH pioneered the practice of placing a capital "D" text link next to pictures or graphics which link to a longer description of the graphic. Since the letter "D" is not a very descriptive phrase for a link, if you use this method you should include an explanation of what it represents and why. Another option is to use a more descriptive text link, such as "or a description of xxx."

3. [Required]  
     Use client-side (instead of server-side) image maps.
   Client-side image maps are similar to server-side image maps except that the information for all of the "hot-spots" within the image are sent to the browser along with the image map picture. Descriptions provided with the URLs can be displayed rather than the graphic. If server-side image maps can not be avoided, see the 5th strategy of the next recommendation.
   
4. [Required]  
     Provide a description for each link in an image map.
   Depending on how you’ve created your image map you have several possibilities:
1. Use the "alt" attribute of the <AREA> element (with the IMAGE, MAP and AREA elements)
   <IMG src="welcome.gif" alt="Image map of areas in the library" usemap="#map1">
<MAP name="map1">
<AREA coords="0,0,30,30" href="reference.html" alt="Reference">
<AREA coords="34,34,100,100" href="media.html" alt="Audio Visual lab">
</MAP>
2. [New] Use the "alt" attribute of the <AREA> element (with the OBJECT, MAP and AREA elements)
   <OBJECT data="welcome.gif" usemap="#map1">
alt="Image map of areas in the library" </OBJECT>
<MAP name="map1">
<AREA coords="0,0,30,30" href="reference.html" alt="Reference">
<AREA coords="34,34,100,100" href="media.html" alt="Audio Visual lab">
</MAP>
3. [New] Use the "title" attribute of the <A> element (with the OBJECT and SHAPES elements)
   <OBJECT data="welcome.gif" shapes>
Areas in the library
<A coord="0,0,30,30" href="reference.html" title="Reference">Reference</A>
<A coords="34,34,100,100" href="media.html" title="Audio Visual lab">Audio Visual Lab</A>
</OBJECT>
4. [New] Create a descriptive paragraph within the <OBJECT> element that includes the links (using the OBJECT and A elements)
   <OBJECT data="welcome.gif" shapes>
There are several areas in the library  including <A coord="0,0,30,30" href="reference.html">Reference</A> and <A coords="34,34,100,100" href="media.html"> the Audio Visual Lab</A>.  More text can follow or precede.
</OBJECT>
5. If a server-side image map has to be used, provide a list of the image map choices (links) as text links on the same page, on an alternative page that is accessible, or within the body of the <OBJECT> element (similar to method #4 above). To avoid confusion, if providing the list of links following the image map, you should indicate within the alt-text of the image map that this is so.
5. [Recommended]  
     Provide descriptive titles for all images used as links.
   Use the "title" attribute of the <A> element to provide more information about images used as links (usually a graphical button). For example, <a href="home.html" title="XYZ company home page"><IMG SRC="logo.gif" alt="XYZ logo"></A>

Recommendations for user agent (browser) designers

1. Calculate the alt-text for the IMG element if not provided by the author.
   When an author does not set the alt attribute for the IMG element, user agents should supply the alternate text, calculated in the following order:
   
   1. If the title has been specified, its value should be used as alternate text.
   2. Otherwise, if HTTP headers provide title information when the included object is retrieved, this information should be used as alternate text.
   3. Otherwise, if the included object contains text fields (e.g., Portable Network Graphics (PNG) images contain some text fields), information extracted from the text fields should be used as alternate text. Since user agents may have to retrieve an entire object first in order to extract textual information, user agents may adopt more economical approaches (e.g., content negotiation).
   4. Otherwise, in the absence of other information, user agents should use the file name (minus the extension) as alternate text.
2. Alt-text that is displayed for image links should have the same font attributes as text links.
   If an image is a link to another page then the alt-text should be coded just as other text links. The most common coding is blue and underlined. This will ensure that users will be able to distinguish between decorative or illustrative graphics and those that are links.
3. Load and display long descriptions of graphics on command.
   While a user is on a graphic, he or she should be able to issue a command to pull up the long description of the graphic. Especially as the longdesc attribute of IMG is supported or descriptions are included within the graphic file. The description should be displayed surrounded by square brackets in place of the graphic. If no description has been specified for a graphic, the user should be notified of the error.

 

---

13.4 Applets

 Since there are several full-fledged programming languages with accessibility issues of their own, we leave the discussion for how to make them accessible to other documents. Trace recently completed a report commissioned by Sun to identify the accessibility issues with Java. For more information on what JavaSoft is doing about accessibility issues within Java, visit their Java Accessibility site at http://www.sun.com/tech/access/.

However, not all browsers support applets and some users do not want to download them because of bandwidth or platform constraints. Newer browsers support a preferences flag that allows the user to indicate if they wish to view applets or not.

Recommendations for page authors

1. [Required]
     Provide alternative text for all applets.
   1. [Interim] <APPLET code="Press.class" width="500" height="500" alt="Java applet: how temperature affects pressure.">
As temperature increases the molecules in the balloon...
</APPLET>
   2. [New] <OBJECT classid="Press.class" width="500" height="500" title="Java applet: how temperature affects pressure.">
As temperature increases the molecules in the balloon...
</OBJECT>

2. [Required]
     Provide descriptions of applets that present important information.
1. [Interim] Use the <APPLET> element to provide a description (see the previous example).  Complete text descriptions could be substituted for the "Hello World!" message.
2. [New] Use the <OBJECT> element (see the previous example).  Complete text descriptions and other accessible objects (see recommendation #5) could be substituted for the "Hello World!" message.
3. [Required]  
     If an applet gathers information, provide an alternative mechanism to gather the information.
   As with the previous two recommendations, an alternative such as a user-input form, e-mail address, phone or fax number could be provided within the alternative text of either the <APPLET> or <OBJECT> elements.
4. [Required]  
     If an applet requires a user interaction (e.g. the ability to manipulate a physics experiment) that can not be duplicated in an alternative format, make the applet directly accessible.
   The guidelines for accomplishing this are included within the Java Accessibility project, and are not yet complete.
5. [Recommended]  
     For applets embedded with the <OBJECT> element, provide alternative, accessible presentations of information within the <OBJECT> element body. [New]
   In HTML4.0 the <APPLET> element has been replaced by the <OBJECT> element. The <OBJECT> element supports nesting of objects for alternative  renderings. For example:
<!-- First, try the pressure applet -->
<OBJECT title="How temperature affects pressure" classid="Press.class" width="500" height="500">
<!-- Else, try the MPEG video -->
<OBJECT data="pressure.mpeg" type="application/mpeg">
<!-- Else, try the GIF image -->
<OBJECT data="Pressure.gif">
<!-- Else render the description and an alternative exercise -->
As temperature increases the molecules in the balloon...
</OBJECT></OBJECT></OBJECT>

6. [Recommended]
     Make applets keyboard operable (using standard conventions).

Recommendations for user agent (browser) designers

1. Render alternatives based on user preferences.
   
2. Calculate the alt-text for the APPLET element if not provided by the author, in the same way as suggested for IMG.

 

---

13.5 Audio and video

Beyond the accessibility issues, there are other practical issues that support following these guidelines. For example, users may want to print a transcript of the dialogue in a movie, search for a certain section of an audio clip via keywords, or search for a particular video clip using a search engine such as a web crawler. Associated captions and transcripts makes these scenarios possible. If descriptions are provided in text mode as well, you can index and search for any video information which is contained in the descriptions.

Recommendations for page authors

1. [Required]
     Provide a text transcript file for all information presented auditorally.
   A transcript is a textual representation of all dialogue, and audio information.
2. [Required]
     Provide descriptions of all video information in an auditory form.
   Audio  descriptions of video action provide additional information during breaks in the dialogue of a movie about the actions that are occurring.
3. [Required]
     Provide a separate text transcript file of all video descriptions.
   A text transcript of video action provides the same information as in recommendation #2 but in a format accessible to those with no audio access.
   
4. [Required]
     Synchronize transcript and video description information with audio/video information, either directly or via a synchronization file.
   Some media formats such as QuickTime (for Macintosh) movies provide alternative tracks that can be used to add captioning and video descriptions.
   1. [Interim] Until the format you are using supports alternative tracks, two versions of the movie could be made available, one with captions (and descriptive video) and one without.

      Example – QuickTime (for Macintosh): With 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 (in addition to the regular video and audio tracks):

      • A text track with captions
      • An audio track with video descriptions added
      • An additional video track with American Sign Language translation
      • Additional text or audio or video tracks spoken or signed in other languages

      For more information on captioning and descriptions visit: http://www.boston.com/wgbh/pages/ncam/currentprojects/captionedmovies.html

   2. [New] Future technologies will allow separate audio/visual files to be combined with text files via a synchronization file to create captioned audio and movies. It will also allow the user to choose from multiple sets of captions to match their reading skills.  For more information see the SMIL specification.
5. TBD
     Provide visual notification of sounds that are played automatically.
   This can be provided in the form of a text phrase on the page that links to a text transcript or description of the sound file. The link to the transcript should appear in a highly visible location like the top of the page. However, if a script is automatically loading a sound, it should also be able to automatically load a visual indication that the sound is currently being played and provide a description or transcript of the sound. The controversy surrounding this recommendation is that the browser should load the semantic information instead of the auditory if the user preferences are set to do so. However, how do we resolve this so it will work with today’s browsers.

6. Design Trick: Use the "TITLE" attribute to provide a brief description within the link to very short sounds.
   For example, <a href="mittens.wav" title="meow"></a>

Recommendations for user agent (browser) designers

1. Support time synchronized text (caption) files.
   This implies providing the support to link three files (the audio, the text transcript and the text synchronization files).
2. Provide a command to load and display the text transcription/description file.
3. Visually display aural alerts.
   If the device has a ShowSounds/Captions feature then this indicator could be tied to the ShowSounds/Caption Flag maintained by the system.
4. Display the title attribute of links.

 

---

14. Style Sheets

Controlling the presentation of an HTML document

 

---

14.1 Style sheets solve several issues, but only if users can override

Whereas most of the other areas present issues that create problems, style sheets is one of the few areas where it generates more solutions that problems.  This assumes that the current specification of HTML 4.0 is implemented as discussed in the most recent draft. 

Elements affected:  STYLE and its attribute

Recommendations for page authors

1. [Required]  
     Use style sheets to position text and objects within pages, rather than physically marking up text and graphics (e.g. <B> or the "align" attribute of <IMG>) (However, continue to use logical elements such as STRONG, H1, etc.  to provide semantic coding within the body of the page) [New]

   Use style sheets rather than:

   • converting text to images or alternative text file formats (such as PDF)
   • using tables or PRE elements to layout pages
   • using proprietary extensions
   • using "invisible" images to layout pages
   • writing a program to accomplish something that is possible with style sheets or plain HTML

   Use style sheets to:

   • position text and graphics
   • create drop caps, subscripts and superscripts
   • avoid uncommon typographic characters or constructions (such as ASCII art, etc.)
   • create alternative versions of a page. Whether or not you anticipate your page being viewed on alternative media, such as a PDA, a speech-based browser or paper (printed), it is a good idea to create style sheets for alternative media to facilitate readability.   Example media types are screen, print, projection, braille, and speech.
   • highlight sections of a document with font size, formatting or color
2. [Required]  
     Ensure that your pages are readable and usable without style sheets (e.g. when the browser does not support or the user prefers not to load).  Since style sheets are a new phenomenon, older browsers will not support them and it will take a while for new browsers to support them in a standard way.

Recommendations for user agent (browser) designers

1. Allow users to select which types of media style sheets they want to use. Allow users to override page author settings with their own style sheets.

Recommendations for assistive technology designers

Perhaps one of the best developments for AT designers will be style sheets that work best with their products, especially aural style sheets.

Suggestions for users

If you do not want to create your own style sheet, but would like to ensure that pages will display appropriately on your viewing device, you can retrieve a style sheet and set it as your default from one of the emerging libraries of style sheets.

 

---

15. Alignment, font styles, and horizontal rules

 

---

15.1 Providing additional cues with horizontal rules

Issue: Horizontal rules (lines) visually indicate changes in context or highlight a section of text. For example, in this document we use horizontal rules between chapters and sections. Since screen readers do not usually pronounce anything for horizontal rules  these cues changes in context go unnoticed. In this document we try to give as many cues to the reader as possible. One strategy is to use numbers to mark each chapter and associated section. Therefore when you read 16.4, then come across 17 it should be easy to interpret that you have just started a new chapter. To provide equal "warning" to the non-visual user we use the title attribute of the HR element.

Element affected:  HR

Recommendations for page authors

1. Design Trick:  Use the "title" attribute on horizontal rules <hr title="new section">

 

---

16. Frames

Multi-view presentation of documents

 

---

16.1 Misinterpretation by screen readers and small screen users

Issue:  Today’s screen readers often view each frame as either a separate window or read across several of them as they do tables (line by line across all frames).  Other times, screen readers get stuck in one frame. Also, when multiple frames are viewed on small monitors it is often difficult or impossible to see all of the data.

Elements affected:  FRAME, FRAMESET  and NOFRAME

Recommendations for page authors

1. [Required]
     Provide a <NOFRAME> option for each <FRAMESET>.
   When using the <NOFRAME> option it is easiest to include all essential information on the bottom of the main frame. The following example is taken from the HTML 4.0 specification.
   • If the user reads "top.html" and the user agent is not displaying frames the user won’t see anything since we do not have a BODY in "top.html". If we insert "table_of_contents.html" and "main.html" directly in a NOFRAMES element in the FRAMESET, we solve the problem of associating the two documents, but we may cause user agents that support frames to retrieve the same data twice: one copy associated with the FRAMESET and one copy inserted in the NOFRAMES. It is more economical to include the table of contents at the top of "main.html" within a NOFRAMES element:

     <!-- This is main.html -->
<HTML><BODY>
<NOFRAMES>
...the table of contents here...
</NOFRAMES>
...the rest of the document...
</BODY></HTML>

     and to link to "main.html" from "top.html" for the case when frames are not displayed:

     <!-- This is top.html -->
<HTML>
<FRAMESET cols="50%, 50%" title="Our big document">
<FRAME src="main.html" title="Where it's all at">
<FRAME src="table_of_contents.html" title="Table of Contents">
<NOFRAMES>
Here's the <A href="main.html">for a non-frames version.</A>
</NOFRAMES>
</FRAMESET>
</HTML>


2. [Recommended]
   Title each frame. [TOMORROW]
   Notice the use of "TITLE" in the previous example. People accesing the page aurally will more easily keep track of how many frames exist and which is the current one.
3. [Recommended]
     Describe the layout and purpose of frames and how multiple frames relate to each other. [New] Use the "longdesc" attribute on <FRAME> and <IFRAME> elements to link to a page with descriptions.

Recommendations for user agent (browser) designers

Allow the user to select whether they want to load frames or not.  If they do not, use the NOFRAME option provided by the page author or the first frame defined as default.

Recommendations for assistive technology designers

Screen readers should be able to navigate each frame as a separate window that is identified uniquely by the TITLE of each frame.

Suggestions for users

If you don’t want to view frames, select the "NOFRAME" in your user agent (TOMORROW), or use a text-based like Lynx which automatically requests the NOFRAME (TODAY).

 

---

 17. Forms

User-input Forms: Text Fields, Buttons, Menus, and more

1. 17.1 Navigation and manipulation
2. 17.2 Graphical buttons

---

17.1 Navigation and manipulation

Issue:  Users who do not use a mouse (such as screen reader users) or that do not use a mouse well (such as users with mobility disabilities) are not always able to navigate into form elements. Often, once they are able to focus on the form element they are unable to manipulate it.

Elements affected:  A, AREA, OBJECT, INPUT, SELECT, TEXTAREA, and BUTTON. 

Recommendations for page authors

1. [Required]
     Do not use image maps to create graphical "submit" buttons.

2. [Required]
     Explicitly associate labels with their control. [New]
   For example:
   <FORM action="http://somesite.com/adduser" method="post"
<FIELDSET>
<LEGEND align="top">Personal information</LEGEND>
<LABEL for="firstname">First name: </LABEL>
<INPUT type="text" id="firstname" tabindex="1">
<LABEL for="lastname">Last name: </LABEL>
<INPUT type="text" id="lastname" tabindex="2">
...more personal information...
</FIELDSET>
<FIELDSET>
<LEGEND align="top">Medical History</LEGEND>
...medical history information...
</FIELDSET>
</FORM>

3. [Required]
     Provide alternative text for images used as "submit" buttons.
   For example, <INPUT type="image" name="submit" src="button.gif" alt="Submit">

4. [Recommended]
     Specify a logical tab order with "tabindex".[New]
   For example, (taken from the HTML 4.0 draft)
   <INPUT tabindex="1" type="text" name="field1">
<INPUT tabindex="2" type="text" name="field2">
<INPUT tabindex="3" type="submit" name="submit">

5. [Recommended]
     Group related controls with the <FIELDSET> element.[New]
   see the example for #2 – "Explicitly associate labels with their control."
   
6. [Recommended]
     Label a group of controls with the <LEGEND> element. [New]
   see the example for #2 – "Explicitly associate labels with their control."
   

7. [Recommended]
     For long lists of selections, group items into a hierarchy.  [New] In the near future, browsers will display grouped lists with expanding and collapsing levels of detail.   To group items, use  <OPTGROUP>   elements with a <SELECT> element, such as:

   <FORM action="http://somesite.com/prog/someprog" method="post">
<P><SELECT name="ComOS">
<OPTGROUP label="Comm Servers">
<OPTGROUP label="PortMaster 3">
<OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with ComOS 3.7.1
<OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS 3.7
<OPTION label="3.5" value="pm3_3.5">PortMaster 3 with ComOS 3.5
</OPTGROUP>
<OPTGROUP label="PortMaster 2">
<OPTION label="3.7" value="pm2_3.7">PortMaster 2 with ComOS 3.7
<OPTION label="3.5" value="pm2_3.5">PortMaster 2 with ComOS 3.5
</OPTGROUP>
</OPTGROUP>
<OPTGROUP label="Routers">
<OPTGROUP label="IRX">
<OPTION label="3.7R" value="IRX_3.7R">IRX with ComOS 3.7R
<OPTION label="3.5R" value="IRX_3.5R">IRX with ComOS 3.5R
</OPTGROUP>
</OPTGROUP>
</SELECT>
</FORM>


8. [Recommended]
     Include default, place-holding characters in edit boxes and text areas. [Interim]
9. [Recommended]
     Include a phone number, e-mail address, postal address or fax number for submitting information. 
10. [Recommended]
      Create keyboard shortcuts for form elements. [New]
    This example assigns "U" as the access key. Typing "U" gives focus to the label which gives focus to the control then the user can input text.
    <FORM action="submit" method="post">
<label for="user" accesskey="U">user name</label>
<input type="text" name="user">
</FORM>

Recommendations for user agent (browser) designers

1. Support the accesskey attribute and FIELDSET and LEGEND elements included in the HTML 4.0 specification.
   
2. Allow users to navigate to and manipulate all form elements via the keyboard.
   
3. Calculate the alt-text for the INPUT element if not provided by the author.
   When an author does not set the alt attribute for the INPUT element, user agents should supply the alternate text, calculated in the following order:
   1. If the title has been specified, its value should be used as alternate text.
   2. Otherwise, if the name has been specified, its value should be used as alternate text.
   3. Otherwise (submit and reset buttons), the value of the type attribute should be used as alternate text
4. Read labels with their associated objects.

 

---

17.2 Graphical buttons

Issue:  Forms can include images that act as buttons or image maps to gather input.  See the section that discusses graphical links.

Recommendations for page authors

1. [Required]
     Do not use image maps to create graphical "submit" buttons.
   
2. [Required]
     Provide alternative text for images used as "submit" buttons.
   For example, <INPUT type="image" name="submit" src="button.gif" alt="Submit">


 

---

18. Scripts

Animated Documents and Smart Forms

1. 18.1 Introduction to the issues
   1. 18.1.1 Action occurring away from user focus
   2. 18.1.2 Actions executed during load of page
   3. 18.1.3 Automatic update of page ("push")
   4. 18.1.4 Summary of issues

---

18.1 Introduction to the issues

A client-side script is a program that may accompany an HTML document or be embedded directly in it. The program executes on the client’s machine when the document loads, or at some other time such as when a link is activated. HTML’s support for scripts is independent of the scripting language.

Scripts offer authors a means to extend HTML documents in highly active and interactive ways. For example:

• Scripts may be evaluated as a document loads to modify the contents of the document dynamically.
• Scripts may accompany a form to process input as it is entered. Designers may dynamically fill out parts of a form based on the values of other fields. They may also ensure that input data conforms to predetermined ranges of values, that fields are mutually consistent, etc.
• Scripts may be triggered by events that affect the document, such as loading, unloading, element focus, mouse movement, etc.
• Scripts may be linked to form controls (e.g., buttons) to produce graphical user interface elements (HTML 4.0 draft).

18.1.1 Action occurring away from user focus

Issue: "Intrinsic events" are events generated by the elements on an HTML page that can be used to trigger scripts that accompany a page. These scripts are often used to cause action away from the user focus.  Where the user’s focus is limited because they are accessing the page aurally or only accessing a portion of the page (via a PDA or screen magnification), these events may go unnoticed.  Intrinsic events are:  onfocus, onblur, onchange, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup.

18.1.2 Actions executed during load of page

Issue: There are two types of scripts: those that are execute in conjunction with an intrinsic event (just discussed) and those executed during loading or immediately after the page is loaded. This includes audio greetings that are played upon opening a page. For this example, if valuable information about how to navigate the site is exclusively delivered by audio, people who are unable to hear the greeting will miss out on the instructions.

18.1.3 Automatic update of page ("push")

Issue :  Where an intrinsic event or an allotted passage of time causes another page to be loaded or more information to be displayed, a user who has a limited focus may not realize new information has been displayed.  For example, if they are reading a page of basketball scores line by line with a screen reader, by the time they have read one score of one game, the page may have reloaded a different set of scores.  In this case they would hear one score for each team for two different games. Not all users are able to interact with animations or dynamically changing pages either because they are not able to position and activate the mouse quickly enough, or do not have the visual information to realize that the page is changing.

18.1.4  Summary of issues

1. Where the user’s focus is limited because they are accessing the page aurally or only accessing a portion of the page (via a PDA or screen magnification), events occurring away from the center of the user’s focus may go unnoticed.
2. Actions executed during loading or immediately after the page is loaded may go unnoticed.
3. Where an intrinsic event or an allotted passage of time causes another page to be loaded or more information to be displayed, a user with a limited focus may not realize new information has been displayed. 
4. Not all users are able to interact with animations or dynamically changing pages either because they are not quick enough, do not have the visual information to realize that the page is changing, or do not have the agility to precisely select a moving image.

Elements affected:  almost every element generates at least one of the intrinsic events

 

Recommendations for page authors

1. [Required]  
     Provide a <NOSCRIPT> option for all scripts.
   For example:
   <SCRIPT type="text/tcl">
...some Tcl script to show a billboard of sports scores...
</SCRIPT>
<NOSCRIPT>
<P> To access today's scores <A href="scores.html">visit our text-only version.</A>
</NOSCRIPT>

2. [Required]
     Provide a mechanism for the user to freeze any moving or blinking text.
3. More exploration is needed in this area. Please stay tuned.

Recommendations for user agent (browser) designers

1. Provide the ability to pause "pushes" until the user is ready for them.
   
2. Provide information in the status line to let users know that the page is updating or changing.
   
3. Provide the ability to break out the text of an animation, banner or etc. and present it as static text.

 

---

19. [Place holder for "SGML reference information for HTML"]

20. [Place holder for "SGML Declaration of HTML 4.0"]

21. [Place holder for "Document Type Definition’]

22. [Place holder for "Transitional Document Type Definition’]

23. [Place holder for "Frameset Document Type Definition"]

24. [Place holder for "Character entity references in HTML 4.0"]

 

---

25. Good Web Site Design Practices

 

---

Now that each individual page is accessible, there are few things to consider about your site as a whole.

1. Page layout is consistent but pages or areas do not look identical.
   For example, navigation bars should be located in the same place on every page.
2. A clear, consistent navigation structure is used. 
   You should always be able to easily navigate to all documents which immediately relate, but you should also always be able to get any other document in the infrastructure with a minimum of fuss. Always provide access to the original table of contents, or its equivalent. This is especially important when others create links to documents in your site that are not necessarily main entry points.  This will prevent readers from finding themselves in the middle of what is obviously a larger document, but without any means of finding additional information.
3. Navigation bars provide easy access to the navigation structure. 
   Graphical aids are useful for some persons with learning or intellectual disabilities.  The button bar can be individual .GIF files or an image map. BUT don’t forget to provide alternatives for users who cannot view graphics.  It is helpful to keep the same buttons and the same location on every page. 
4. Instructions are provided to describe the general layout of the site, the access features used, and how to use them.
   For example, if you use D-links describe what information the user can expect to find when following D-links.
5. A site map is available.
   People who have difficulty visualizing the structure of information can be helped by a site map, a visualization of the structure of the site. In the future, perhaps user agents will update the view of the site map with the path of navigation and the location of the current page.
6. Different types of searches are available for different skill levels and preferences.
   Most search facilities require the user to enter keywords for search terms. Users with spelling disabilities and foreign users will have a difficult time finding what they need as long as perfect spellings are required. Search engines could include a spell checker, offering best guess alternatives or offer different types of searches, for example: query-by-example or similarity searches.
7. Nothing within the site prevents keyboard operation.
   
8. Elements outside of the HTML 4.0 specification (such as <BLINK> and <MARQUEE>) are not used
   
9. Use a design tool that supports access features (and does not remove access when you close, or reopen your page using the tool)
10. Test the site with AT LEAST:
    • a text only browser (such as Lynx)
    • a self-voicing browser (such as PWWebspeak)
    • Multiple graphic browsers, with:
      • sounds and graphics loaded,
      • graphics not loaded,
      • sounds not loaded,
      • no mouse

 

---

Appendices

 

---

A. Design Notes

Alt-text Tips and Tricks

1. Keep the wording simple.
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 attributes for images may cause the alt-text to wrap, which often makes it unreadable by everyone but Lynx users. By decreasing the size of the font, the alt-text can be made to fit in the specified region.
4. Include periods at the end of alt-text of images, especially those used as links. Periods cause screen readers to pause and will give an indication of where the alt-text ends and the rest of the text begins. It also ensures that several links in a row will not be strung together into a single link.
5. Graphical lines can be used to provide extra cues for changes in context, in comparison with the<HR> element. For example, the alt-text for a graphical line might be ‘Section 2: today’s weather."
6. For critical bullets, use numbers or letters as the alt-text so that they are pronounced.
7. 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 that have spaces for alt-text or not alt-text at all are not required to grasp the content of the page.
8. AT&T has created a reference area for creating alt-text available at http://www.att.com/style/alttext.html

 

---

Methods to create alternate pages

1. "By hand"
   Sometimes, a site may only need to create text-only pages for layouts that can not be made accessible. This may involve only a couple of pages.
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 the CommerceNet server.
3. Filters
   This approach is similar to Database-based pages, 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, be 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 decrement in performance 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 so 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 1 (By hand) would be much more effective.
4. Style sheets
   

---

References

1. HTML 4.0 draft Available: http://www.w3.org/TR/WD-html40/cover.html
2. World Wide Web browser access recommendations – Jon Gunderson. Available: http://www.staff.uiuc.edu/~jongund/access-browsers.html

Designing Accessible HTML Pages — guidelines and overview documents

1. Accessible Design for Users with Disabilities. — Sun Microsystems
2. The Accessible Web: Web Access Through Adaptive Technology — Kevin Nguyen, University of Toronto
3. ACT Centre Accessible Web Design
4. All Things Web 
5. ALT text recommendations, and notes on viewing situation — A.J. Flavell, University of Glasgow
6. Alternative Access to the World Wide Web — University of Toronto
7. Any Browser Table Format — Department of MIssions, Abilene Christian University
8. Best Viewed With Any Browser — Accessible Site Design
9. Compatibility & Accessibility — Towards the creation of an accessible, truly World-wide Web — All Things Web
10. Composing Good HTML — James "Eric" Tilton. 
11. Design Considerations: Readers with Visual Impairments — Arthur R. Murphy
12. Designing Access to WWW Pages – Alliance for Technology Access.
13. Designing HTML Tables to Work with HTML 2.0 Browsers — Stanton McCandlish
14. DO-IT HTML Guidelines — University of Washington
15. Experiences Implementing Web Accessibility Guidelines in IBM — Phill Jenkins
16. For Web Page Designers — Microsoft
17. GSA HTML Accessibility Guidelines – Paul Fontaine
18. Guide to Writing Accessible HTML — University of Toronto
19. Guidelines on Universal Web-Site Accessibility — Treasury Board Internet Working Group on Internet Presentation, Style and Accessibility
20. Hints for designing accessible Websites — Royal National Institute for the Blind
21. IBM Web Design Guidelines
22. Increasing Access to World Wide Web Sites for Blind and Visually Impaired Computer Users — Dena Shumila, Jan Richards
23. InfoUse Web Accessibility Guidelines
24. LEVELLING THE ROAD AHEAD: GUIDELINES FOR THE CREATION OF WWW PAGES ACCESSIBLE TO BLIND AND VISUALLY HANDICAPPED USERS, Judith M. Dixon, Ph.D., Consumer Relations Officer, National Library Service for the Blind and Physically Handicapped
25. The Lynx Manifesto — Dehanced for Lynx
26. Making Your Site Speech Friendly — Cathy Anne Murtha, Web Design and Access Specialist, Magical Mist Creations
27. NCSA Mosaic Access Page
28. Nimble Document Navigation Using Alternative Access Tools — Jutta Treviranus, University of Toronto
29. On-Line Examples of HTML Accessibility – Chuck Le Tourneau
30. Tables on non-table browsers — A.J. Flavell, Glasgow University
31. Unified HTML Accessibility Guidelines — Previous version of this document
32. Universal Accessibility — Government of Canada Internet Guide
33. Universal Design of WWW Pages — a DO-IT (University of Washington) Brochure
34. Universal Information Access on the WWW (COCA)
35. "Universal Specifications" Accessibility Standards for Web Design — New South Wales Attorney General’s Department
36. Usability of Information and the WWW — UCLA Disabilities and Computing Program
37. Web Accessibility Guidelines — IBM
38. World Wide Web Access: Disability Discrimination Act Advisory Notes — Australia