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.)
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.
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).
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:
- 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- Understanding Disabilities and Web Access Issues
A discussion of the different types of disabilities and their effect on access to the web- 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
- 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
- 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.- Web Access Resource Site
A website containing extended discussions, case studies, demonstrations, tools, references to other guidelines and efforts related to web access, etc.
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.
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:
- To minimize the effort needed by page authors to make their sites accessible.
- 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.
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.
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:
- magnifying small fonts or images may cause pixelation and/or distortion ;
- 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.
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.
- P aresis - 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).
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:
- Impairments of Intelligence and Thinking
- Mental Retardation
- Dementia
- Impairments of Memory
- Amnesia
- Memory illusions
- Forgetfulness
- Other Intellectual Impairments
- Aphasia
- (Specific) Learning Disabilities
- Spoken language
- Written language
- Arithmetic
- Reasoning
- Psychological impairments
- Drug and Alcohol Dependence
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.
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.
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.
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).
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.
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 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.
[Required] - Required for some groups of users to access the information on a page.
[Recommended] - Makes page easier to understand and use.
[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.
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:
- Recommendations for page authors - issues to be handled in source documents
- Recommendations for user agent (browser) designers - issues to be handled by browsers
- Recommendations for Assistive Technology designers - issues to be handled by screen readers, screen magnifiers, scanning software, etc.
- Suggestions for Users - configuring the user agent and assistive technology for maximum benefit.
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.
Design Tip: Use the
TITLEelement in theHEADof each document.
For example,<HTML><HEAD>...<TITLE>Version 8 of the Unified Web Accessibility Guidelines</TITLE>...</HEAD>...
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.
Issues: There are four issues with the presentation of text:
- 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:
- 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.
- 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.
- Drop-caps, subscripts and superscripts. Current screen readers might interpret words or letters as appearing on a separate line.
- 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.
- 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.
- 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
[Required]
Use style sheets: [New]
Logical: DFN, EM, CITE, CODE, KBD, SAMP, STRONG, VAR, H1, H2, etc.
Physical: size=14, B, I. cite> to undent a paragraph.BLINK and MARQUEE
elements. [Interim]Testing tips
Allow user-selected style sheets to override the page author's settings.
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.
If user agents do not support the previous recommendation, then that functionality should be implemented here (although this requires parsing of HTML).
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
Design Tip: Use the "
title" attribute for acronyms and abbreviations<abbr>title="World wide web">WWW</abbr>
titleinformation available or present it inline if requested by the user.
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
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..
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:
Message that is visible on screen What is read to the user H "H" Ha "Hah" Hav "Have" e a nice day "E A nice day"
Elements affected:
BLINK, MARQUEE, as well as programming or scripting languages, such as Java and JavaScript.
BLINK and MARQUEE
elements. [Interim]
BLINKandMARQUEEphrases as static text.
This goes for all animations and interactions. See the sections on Applets and Scripts for more information.Side note:
MARQUEEis a MSIE3.0 element, whileBLINKwas introduced in Netscape 1.1. Therefore, neither are considered standard HTML.
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
erasersElements affected:
OL, UL, LI, DL, DD, DT, BLOCKQUOTE
UL, OL, LI). (Use style sheets to adjust item spacing
[New]). Tips and tricks:
Introduce
each list by indicating how many items it contains.
Allow the user to configure how nested lists should be
enumerated and presented.
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:
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. 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:
Welcome to our
siteSponsored by
XYZ companyHelp Search Products,
projects and
research newsVirtual tour of our
headquartersGames and
educational
offeringsEmployment
opportunitiesBackground 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
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
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>
<PRE>
elements to arrange text documents in columns or otherwise layout a page. (Use style
sheets to position graphics and text [New]). 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>
Testing tips
Make cell, row and
column information available. AXES, AXIS, and SCOPE
attributes. As the draft solidifies we will provide more information about how to use the
new attributes. Provide methods to
"unwrap" table information. Provide the ability
to navigate by column, row and cell. Provide orientation
functions.
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
[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."
Provide a feature
that displays either:click here; To find out more about
how the west was won, click here.
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.
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.
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.
[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]
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:
- 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.
- 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.
<HEAD><LINK title="Text-only version" rel="alternate"
href="text_only.html" media="speech"></HEAD>
If a page is specifically created for their selected default media type, load the appropriate page automatically.
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.
Support
"tabbing" between links.
Allow the user to
select font color and size of text links. Consider creating a
bookmark function that allows a person to associate a picture with each bookmark.
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.
There are no recommendations at this time. Further exploration is needed and solutions solicited.
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>
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.
The following recommendations apply to images, sounds and multimedia.
Elements affected:
OBJECT, IMG, APPLET, A
Allow users to
designate whether they want to download and view multimedia and applets. Display the
alternate media associated with the element if the user selects not to view multimedia .
- Alternate text for images.
- Alternate text for each link of an image map (client side).
- Alternate renderings for objects included with the
OBJECTelement. 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.- Transcripts for movies.
- Transcripts or descriptions of audio clips.
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.
Elements affected:
OBJECT, IMG
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">.<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.
- [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>- [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."
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>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>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><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><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. "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> Calculate the alt-text for the IMG element if not
provided by the author.IMG element, user
agents should supply the alternate text, calculated in the following order: Alt-text that is
displayed for image links should have the same font attributes as text links. Load and display
long descriptions of graphics on command.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.
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.
<APPLET code="Press.class" width="500"
height="500" alt="Java applet: how temperature affects pressure.">
As temperature increases the molecules in the balloon...
</APPLET><OBJECT classid="Press.class" width="500"
height="500" title="Java applet: how temperature affects
pressure.">
As temperature increases the molecules in the balloon...
</OBJECT>
APPLET> element to provide a description
(see the previous example). Complete text descriptions could be substituted for the
"Hello World!" message.OBJECT> element (see the previous
example). Complete text descriptions and other accessible objects (see
recommendation #5) could be substituted for the "Hello World!" message.APPLET> or <OBJECT> elements.<OBJECT> element, provide
alternative, accessible presentations of information within the <OBJECT>
element body. [New]<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>
APPLET element if not provided by the author, in the same way as suggested for IMG.
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.
- 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
"TITLE" attribute to provide a
brief description within the link to very short sounds. <a href="mittens.wav"
title="meow"></a> Support
time synchronized text (caption) files. Provide
a command to load and display the text transcription/description file. Visually
display aural alerts. Display
the title attribute of links.
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:
STYLEand its attribute
<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:
Use style sheets to:
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.Perhaps one of the best developments for AT designers will be style sheets that work best with their products, especially aural style sheets.
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.
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
titleattribute of theHRelement.Element affected:
HR
title" attribute
on horizontal rules <hr title="new section">
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, FRAMESETandNOFRAME
NOFRAME> option for
each <FRAMESET>.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.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><!-- 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>
"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.longdesc" attribute on <FRAME> and
<IFRAME> elements to link to a page with descriptions.
NOFRAMEoption provided by the page author or the first frame defined as default.
Screen readers should be able to navigate each frame as a separate window that is identified uniquely by the
TITLEof each frame.
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).
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.
<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>
<INPUT type="image" name="submit"
src="button.gif" alt="Submit">
"tabindex".[New]<INPUT tabindex="1" type="text" name="field1">
<INPUT tabindex="2" type="text" name="field2">
<INPUT tabindex="3" type="submit" name="submit">
FIELDSET>
element.[New]<LEGEND>
element. [New][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>
<FORM action="submit" method="post">
<label for="user" accesskey="U">user name</label>
<input type="text" name="user">
</FORM> Support
the accesskey attribute and FIELDSET and LEGEND elements included in the HTML 4.0
specification. Allow
users to navigate to and manipulate all form elements via the keyboard.
Calculate the alt-text for the INPUT element if not provided by the author. Read
labels with their associated objects.
Issue: Forms can include images that act as buttons or image maps to gather input. See the section that discusses graphical links.
<INPUT type="image" name="submit"
src="button.gif" alt="Submit">
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).
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.
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.
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.
Elements affected: almost every element generates at least one of the intrinsic events
<NOSCRIPT> option for all scripts.<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>
Provide
the ability to pause "pushes" until the user is ready for them. Provide
information in the status line to let users know that the page is updating or changing. Provide
the ability to break out the text of an animation, banner or etc. and present it as static
text.
Now that each individual page is accessible, there are few things to consider about your site as a whole.
<BLINK> and
<MARQUEE>) are not used
<HR> element. For example, the alt-text for a
graphical line might be 'Section 2: today's weather."