WD-WAI-PAGEAUTH-0414
WAI Accessibility Guidelines:
Page Authoring
W3C Working Draft 14-Apr-1998
This version:
http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0414
Latest version:
http://www.w3.org/TR/WD-WAI-PAGEAUTH
Previous versions:
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0413
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0410
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0203
Editors:
Gregg Vanderheiden, Trace Research and Development
Wendy Chisholm, Trace Research and Development
Ian Jacobs, W3C
Please see the Acknowledgements section of the Appendix for a full listing of contributors.
Status of this document
This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft
document and may be updated, replaced or obsoleted by other documents at any time. It is
inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in
progress". This is work in progress and does not imply endorsement by, or the consensus of, either
W3C or members of the WAI GL Working Group.
This document has been produced as part of the W3C WAI Activity, and is intended as a draft of a
Proposed Recommendation for authoring accessible Web pages. The goal of the WAI-GL working
group is discussed in our charter.
Abstract
This document is a list of markup guidelines that HTML authors should follow in order to make their
pages more accessible for people with disabilities and more useful to indexing robots. Following the list
of guidelines is a checklist that authors and Web masters should use to verify page accessibility. Tools
that generate documents in HTML (authoring tools, file conversion packages or other products) should
produce documents that follow these guidelines. This document is part of a series of accessibility
documents published by the Web Accessibility Initiative.
Comments
Please send detailed comments on this document to w3c-wai-gl@w3.org. Public comments about the
WAI author guidelines can also be sent to this mailing list.
Note. Some people have encountered problems printing this page due to the use of style sheets.
We have tried to correct the problem but ask that people help us explore solutions.
Table of Contents
Introduction
Rating and Classification
1. Style and Structure
2. Images and Image Maps
3. Applets and Scripts
4. Audio and Video
5. Tables
6. Links
7. Frames
8. User-Input Forms
9. If All Else Fails...
10. Good Web Site Design Practices
Appendix A - Table examples
Appendix B - Alt-text authoring guidelines
Checklist
Acknowledgements
References
Introduction
This document recommends guidelines that HTML authors should follow in order to improve the
accessibility of their pages. Some of the guidelines take advantage of the features of HTML 4.0, but
many of them apply to earlier versions of HTML as well.
Measures to improve accessibility fall roughly into the following categories:
Structure
HTML documents that contain a lot of markup used for presentation and not enough markup to
convey structure pose accessibility problems for non-visual users. Authors should use HTML
structural markup to convey meaning and style sheets to format and layout pages.
Navigation
Authors should enable keyboard-only navigation (access to hyperlinks, navigation among links,
navigation among form fields, navigation within and between pages) and design pages that promote
easy orientation (numbered lists, titles, etc.).
Alternative format
Authors should always provide alternative ways to access information presented via images, sounds,
applets, and scripts. For example, captions and transcripts provide auditory information in a form
accessible to people unable to hear it. A textual replacement of a graphic, either a description of its
content or function, provides information in a form accessible to people unable to see it.
The following sections offer specific guidelines that HTML authors should use to improve the
accessibility of their pages.
Rating and Classification
Each guideline is accompanied by a rating that describes its importance:
[Required]
Required, otherwise it will be impossible for one or more groups of users to understand the page.
[Recommended]
Makes page easier to understand and use.
Each guideline may be implemented by one or more "strategies" in HTML (and possibly a style sheet
language). Each strategy may be classified according to the immediacy of its application:
[Interim]
This strategy is necessary to make pages accessible for today's browsers and assistive technologies
[New]
This strategy takes advantage of features being incorporated into tomorrow's browsers and assistive
technologies (that incorporate Web Access Initiative recommendations).
Strategies with no classification work for versions of HTML prior to HTML 4.0, and old or new
browsers.
1. Style and Structure
1. [Required]
Use elements and attributes that comply with an HTML 4.0 Document Type
Definition (DTD) and CSS-1.
The W3C offers an HTML validation service at http://validator.w3.org/ that can be used to
determine if a site complies with one of the HTML 4.0 Document Type Definitions (there are
three: strict, transitional, and frameset - see the validation service for more information). It is
recommended, but not currently required, that pages comply with the strict definition.
2. [Required]
Ensure that pages are readable and usable without style sheets for browsers that do not
support them or users who deactivate them. 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.
3. [Required]
Nest headings properly.
Since some users skim through a document by navigating its headings, it is important to
increment heading levels correctly (H1 followed by H2, rather than H1 followed by H3).
Headings used for other purposes, such as formatting text in a larger font size, may disorient
users; use style sheets for formatting. Note. See items 9 and 10 in this section.
4. [Required]
Encode list structure and list items properly.
The HTML list elements (DL, UL, OL, LI) should only be used to create lists. Avoid using
list elements for presentation effects such as indentation.
[New] Use style sheets rather than HTML attributes to control item spacing. Note. See item 7
in this section.
5. [Required]
Avoid blinking or scrolling text.
[Interim] Authors should avoid the BLINK and MARQUEE elements. First of all, these elements
are not part of HTML 4.0 (they are proprietary extensions and should be avoided. See item
1). Second, blinking and moving text 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"). Authors should use style sheets to draw
attention to text in other ways, such as different fonts, sizes, or colors.
6. [Recommended]
Use style sheets rather than converting text to images.
For example, stylized text on a colored background can be created with style sheets instead of
as an image. This provides flexibility for people to view the text in a form that is most readable
to them including magnified, in a particular color combination such as white on black, or in a
particular font.
7. [Recommended]
Use style sheets rather than invisible or transparent images to force layout.
Note. Current (April 1998) browsers do not yet support use of style sheets for some types
of positioning, such as absolute.
8. [Recommended]
Avoid the use of deprecated presentation elements and attributes (as well as B and
I).
Authors should use style sheets instead of presentation elements (TT, and FONT) and
attributes ("align" and "background") that control visual presentation. Authors are encouraged
to use elements (such as STRONG, EM, H1, H2, ABBR, etc.) that add structure to documents.
Documents that use style sheets for presentation allow users to adjust the look of the document
(e.g., larger print, color contrast, etc.) through personal style sheets or browser settings.
9. [Recommended]
Use elements and attributes that appropriately convey structure.
Phrase elements include: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR,
and ACRONYM
Structural elements: H1, H2, etc.
Structural elements enforce consistency in documents and supply information to other tools
(e.g., indexing tools, search engines, programs that extract tables to databases, browsers that
use header elements ( H1, H2, etc.) to generate navigation tools, etc.).
10. [Recommended]
Do not misuse structural elements and attributes for purposes of layout.
For example, do not use the BLOCKQUOTE element to indent a paragraph that is not a quotation;
use style sheets. Do not use PRE to create a tabular layout of text; use tables.
11. [Recommended]
Do not misuse presentation elements for purposes of structure.
For example, while a horizontal rule (HR) might convey a structural change to some users, it may
not to all users. Instead, specify structure with DIV and SPAN. For example:
12. [Recommended]
Provide titles for horizontal rules, acronyms, and abbreviations.
For example:
ID
WWW
Tips and Tricks
? To test if the text and background contrast is sufficient enough to be read by people with color
deficiencies or on low resolution monitors, print pages on a black and white printer (with
backgrounds and colors appearing in grayscale).
? 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 or a Lynx emulator such as Lynx Viewer or Lynx-me.
? Using a numbered (ordered) list makes it easier for people accessing the page aurally to keep
track of where they are within a list.
For more information:
1. Style Sheets - Chapter 14 in the Central Reference Document
2. Style Sheets - the HTML 4.0 specification
3. Cascading Style Sheets, level 2 -- Working Draft from the World Wide Web Consortium
4. Text - Chapter 9 in the Central Reference Document
5. Text - the HTML 4.0 specification
6. Lists and Outlining - Chapter 10 in the Central Reference Document
7. Lists - the HTML 4.0 specification
2. Images and Image maps
Please also consult the section on links.
1. [Required]
Provide alternative text for all images and image maps.
Each image should have alternative text that represents the function of the graphic. Aim for a
functional label based on the context in which it is used rather than a visual description. A good
test to determine if alternative text is useful is to imagine reading the document aloud over the
telephone. What would you say upon encountering this image to make the page comprehensible
to the listener? Possible strategies for providing alternative text include:
1. The "alt" attribute is mandatory for the AREA and IMG elements. It should also be used
for buttons used as submit buttons on forms (INPUT and BUTTON elements). For
example: . However, the
recommendations for alt-text vary depending on how the graphic is used (decoration,
button, bullet, illustration, etc.). Please see Appendix B - Alt-text authoring guidelines
for more information.
2. [New] If OBJECT is used, text can be provided in the body of the OBJECT element.
For example:
Note. Longer descriptions of the appearance of an image may be provided. See the next
recommendation for solution strategies.
2. [Required]
Provide a longer description for graphics that present important information (especially
charts, tables, and diagrams).
Alternative text (see strategy 2.1 above) is usually short and defines the basic purpose of a
graphic element. To describe the graphic itself in more detail, supply a longer description with
one of the following mechanisms (most of these methods link to additional information):
1. [Interim] Provide a description-link (D-link) next to the graphic. The D-link links to
a page or a phrase at the bottom of the page with a longer description of the graphic.
For example:
D
2. [New] Use the "longdesc" attribute of the IMG element. For example:
3. [New] Provide text within the body of the OBJECT element:
4. Include internal text in image data file when the image data file format supports it, e.g.,
PNG.
3. [Required]
Ensure that image map information is accessible and keyboard navigable.
The easiest way to satisfy this recommendation is to use a client-side image map since browsers
that are not displaying graphics can use "alt" or "title" attribute values of AREA elements to
present a list of links in place of the image map graphic. Keyboard navigation to areas within
the image map is also possible since the browser knows the coordinates of the defined areas.
When a server-side image map must be used, authors should provide an alternative list of image
map choices. If an alternative list of links follows the image map, authors should indicate with
the "alt" attribute of the IMG element the existence and location of the alternative list. A more
straightforward solution, although newer and less backwards compatible, is to include the
alternative links within the body of an OBJECT element (see examples below). One final
possibility is to create an alternative page that is accessible.
For client-side image maps, there are several solution strategies:
1. If the MAP element has been used with AREA, set the "alt" attribute of the AREA
element. For example, with the IMG element:
2. [New] The same idea, this time using the OBJECT element with flexibility to include
more information:
3. [New] The MAP element can be used with A elements to specify active region
geometries and provide contextual information.
Note in this example that the MAP element is the content of the OBJECT element so that
the alternative links will only be displayed if the image map (navbar1.gif) is not.
4. [Recommended]
Provide descriptive titles for images used as links.
Use the "title" attribute of the A element to provide more information about images used as
links. For example:
5. [Recommended]
Avoid ASCII art. Replace it with an image and alternative text.
Common typographic characters or constructions to be avoided are emoticons and arrows
consisting of dashes and greater than signs (e.g., -->), etc.
For more information:
1. From the Central Reference Document
1. 13.1 Introduction to the issues
2. 13.2 General recommendations
3. 13.3 Viewing and interacting with static images and image maps
2. Objects, Images and Applets - the HTML 4.0 specification
3. Applets and Scripts
1. [Required]
Provide alternative presentations of content for each script and applet that conveys
information.
1. [New] The NOSCRIPT element allows authors to supply alternative presentations of
content for scripts. For example:
2. [Interim] Supply a description as content of the APPLET element.
Note. The APPLET element is deprecated in HTML 4.0.
3. [New] Supply a description as content of the OBJECT element.
A more complex version takes advantage of the fact the OBJECT elements may be
embedded to provide for alternative representations of information:
2. [Required]
Provide alternative mechanisms for each script and applet that performs an important
function, other than presentation of information.
For example, an applet gathers information for a database. Alternative information-gathering
mechanisms such as a user-input form, e-mail address, phone or fax number should be provided
within the content of either the APPLET or OBJECT elements.
3. [Required]
If an applet requires user interaction (e.g., the ability to manipulate a physics
experiment) that cannot be duplicated in an alternative format, make the applet
directly accessible.
More information is available through the Java Accessibility page at the Trace Center.
4. [Required]
Provide a mechanism for the user to freeze all moving or blinking objects, particularly
those that contain text.
In an 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.
5. [Recommended]
Provide alternative text for each applet.
Providing content within the body of the APPLET or OBJECT element (item 1 in this section) is
the preferred method to provide alternative text because it is backwards compatible.
1. [Interim] Use the "alt" attribute of the APPLET element, as in:
Note. The APPLET element is deprecated in HTML 4.0.
2. [New] When using the OBJECT element, specify alternative text within the "title"
attribute or within the body of the OBJECT element (see item 1 in this section):
6. [Recommended]
Make scripts and applets keyboard-operable.
Note. More exploration is needed in this area. Please stay tuned.
For more information:
1. From the Central Reference Document
1. 13.1 Introduction to the issues
2. 13.2 General recommendations
3. 13.4 Applets
4. 18 Scripts
2. Objects, Images and Applets - the HTML 4.0 specification
3. Scripts - the HTML 4.0 specification
4. IBM Guidelines for Writing Accessible Applications Using 100% Pure Java -- IBM Special
Needs Systems
4. Audio and Video
1. [Required]
Provide a text transcript of all audio information.
Full audio transcripts include spoken dialogue as well as any other significant sounds including
on-screen and off-screen sounds, music, laughter, applause, etc. When these transcripts are
presented synchronously with a video presentation they are called "captions" and are used by
people who cannot hear the audio track of the video material.
2. [Required]
Provide descriptions of all video information in an auditory form, synchronized with
the audio track.
Video descriptions are used primarily by people who are blind to follow the action and other
non-auditory information in video material. The description provides narration of the key visual
elements without interfering with the audio or dialogue of a movie. Key visual elements include
actions, settings, body language, graphics, and displayed text.
3. [Required]
Provide descriptions of all video information in a text format.
A text transcript of the video descriptions provides the same information as in recommendation
4.2, but in a text format. This text transcript, in conjunction with the full audio transcript (4.1),
allows access by people with both visual and hearing disabilities. This also provides everyone
with the ability to index and search for information contained in audio/visual materials.
4. [Required]
Synchronize text and video description information with audio/video information,
either directly or via a synchronization file.
Some media formats, such as QuickTime 3.0, allow captions and video descriptions to be
added to the multimedia clip.
1. [Interim] Until the format in question supports alternative tracks, two versions of the
movie could be made available, one with captions and descriptive video, and one
without.
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. [Recommended]
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
such as at 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 visual form of the information
instead of the auditory form if the user preferences are set to do so. However, strategies
must also work with today's browsers.
6. [Recommended]
Use the "title" attribute to provide a brief description of a very short sound.
For example: Calico says "hello"
For more information:
1. From the Central Reference Document
1. 13.1 Introduction to the issues
2. 13.2 General recommendations
3. 13.5 Audio and video
2. Objects, Images and Applets - the HTML 4.0 specification
3. Examples from NCAM
5. Tables
1. [Required]
Associate table cells with row and column labels explicitly.
Future browsers and assistive technologies will be able to automatically translate tables into
linear sequences if tables are labeled appropriately. [New] One way of labeling cells is with the
"headers" and "scope" attributes. Please refer to the first two table examples in the appendix.
2. [Required]
Avoid using tables to format text documents in columns.
3. [Recommended]
For tables of text and numbers, provide an alternative page that presents the table
information in a linear fashion.
4. [Recommended]
Avoid using tables to layout a page.
[New] Authors should use style sheets to position graphics and text.
5. [Recommended]
Provide abbreviations for lengthy row or column labels.
[New] Row and column header abbreviations (the "abbr" attribute) 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.
Please refer to the examples in the appendix.
6. [Recommended]
Provide summaries of tables.
[New] Summaries of table structure and purpose (the "summary" attribute of the TABLE
element) are especially useful for non-visual users. Please refer to the examples in the appendix.
7. [Recommended]
For more complex tables, group information into categories.
[New] Future browsers will allow users to select data from a table by filtering on categories.
Please refer to the third example (the "axis" attribute) in the appendix.
8. [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 800x600 pixels.
9. [Recommended]
Provide a phone number, fax number or e-mail address if tables cannot be made
accessible.
Tips and Tricks
? To predict how one of today's screen readers might read the 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?
? OR 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.
? OR view the page with a text-based browser such as Lynx or use a Lynx emulator such as
Lynx Viewer or Lynx-me.
For more information:
1. Tables - Chapter 11 in the Central Reference Document
2. Tables - the HTML 4.0 specification
6. Links
Please also consult the section on image maps.
1. [Recommended]
Create link phrases that make sense when read out of context, but that are not too
verbose.
Users who are blind often jump from link to link when skimming a page or looking for
information. When they do this, only the text of the link ("link text") is read. Therefore, it is
important that link text make sense when read without surrounding text. For example, authors
should not use "click here" as link text several times on the same page; this requires a user
browsing the page with a screen reader to step through each link and read the surrounding text
to determine the purpose of the link. Instead, link text should carry sufficient information, as in
"download this document in ASCII text," "view the full version in HTML," or "for the text
version select this link."
2. [Recommended]
Place non-link, printable characters (surrounded by spaces) between links that occur
consecutively to keep separate links from being read as one by screen readers (e.g., " | ").
[Interim] Please consult the example provided in guideline 5.3.
3. [Recommended]
Provide keyboard shortcuts for links.
The "accesskey" attribute of the LABEL, A, CAPTION, and LEGEND elements 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. XYZ company home page
For more information:
1. Links - Chapter 12 in the Central Reference Document
2. Links - the HTML 4.0 specification
7. Frames
1. [Required]
Ensure that pages are readable and usable without frames.
[New] Authors should include a NOFRAMES element at the end of each FRAMESET. Please refer
to the example in the Central Reference Document.
2. [Required]
Do not include an image directly in a frame -- put it in a separate document.
[New] Otherwise, if the frame contents change, the frame title -- the only alternative text
available in this case -- will no longer make sense. Including the image in its own file allows
authors to specify alt-text with the IMG or OBJECT elements.
3. [Required]
Give each frame a title.
[New] People accessing the page aurally will more easily keep track of how many frames exist
and which is the current one. For example:
4. [Recommended]
Describe the layout and purpose of frames and how multiple frames relate to each
other.
[New] Use the "longdesc" attribute on the FRAME and IFRAME elements to designate a long
description.
For more information:
1. Frames - Chapter 16 in the Central Reference Document
2. Frames - the HTML 4.0 specification
8. User-Input Forms
1. [Required]
Do not use image maps to create graphical "submit" buttons.
Instead, use the BUTTON or INPUT elements with alternative text.
2. [Required]
Associate labels with their form controls.
Labels can be associated explicitly using the "for" attribute of the LABEL element.
[New] The "for" attribute of the LABEL element allows explicit association. For example:
3. [Required]
Provide alternative text for images used as "submit" buttons.
For example:
4. [Recommended]
Specify a logical tab order among form controls.
[New] The "tabindex" attribute specifies the tabbing navigation order among form controls.
For example:
5. [Recommended]
Group related controls semantically and label each group.
[New] The new FIELDSET element groups form controls while the LEGEND element labels each
group. Please see the example in guideline 10.2.
6. [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 the OPTGROUP element (with the SELECT element). For
example:
7. [Recommended]
Include default, place-holding characters in edit boxes and text areas. [Interim]
8. [Recommended]
Include a phone number, fax number, e-mail address, or postal address as an
alternative way to submit information. [Interim]
9. [Recommended]
Furnish keyboard shortcuts for form elements.
[New] Keyboard shortcuts are assigned with the "accesskey" attribute. This example assigns
"U" as the access key. Typing "U" gives focus to the label, which gives focus to the control, so
that the user can input text.
For more information:
1. Forms - Chapter 17 in the Central Reference Document
2. Forms - the HTML 4.0 specification
9. If All Else Fails...
If, after best efforts, any page is still not accessible, provide a link to an alternative page that is
accessible, has equivalent information, and is maintained with the same frequency as the
inaccessible page. Alternative pages are not a recommended practice because maintenance costs
increase the likelihood that the alternative pages will become outdated. If alternative pages are created
they must be updated as frequently as the main pages and provide equivalent information.
1. Methods for linking to alternative pages:
1. [Interim] Provide a link at the top of each page to allow a user to move back and forth
between the graphic and alternative versions of the page.
2. [New] Provide the appropriate information in the header of the principal page (with the
LINK element) so that the browser loads it automatically. If the user has set their default
media type to "aural," "braille," or "tty" the user agent should load the alternative page
automatically. For example:
Welcome to the Virtual Mall!
10. Good Web Site Design Practices
Following the general site design guidelines will further improve accessibility.
1. Create a consistent style for pages.
2. Use a clear, consistent navigation structure.
3. Offer navigation bars for easy access to the navigation structure.
4. Provide a description of the general layout of the site, the access features used, and how to use
them.
5. Offer a site map.
6. Offer different types of searches for different skill levels and preferences.
7. Ensure that nothing within the site prevents keyboard operation.
8. Ensure that text and background colors or patterns contrast well. (A good test is to print your
page to a black and white printer).
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. Place distinguishing information at the beginning of headings, paragraphs, lists, etc., to decrease
the amount of sifting readers perform to find important information. This is commonly referred
to as "front-loading" and is especially helpful for people accessing information serially.
11. Create a single downloadable file for documents that exist as a series of separate pages. This
helps people reading documents off-line. Currently, an archival or compression program is
needed to create the single file. In the near future, user agents will be able to collate separate
pages based on information in page headers. The following example shows how to indicate
where the first page of the reference manual exists as well as which page follows the current
one.
Reference manual -- Chapter 1
12. Test the site with at least:
? a text-only browser (e.g., Lynx or a Lynx emulator such as Lynx Viewer or Lynx-me)
? multiple graphic browsers, with:
? sounds and graphics loaded,
? graphics not loaded,
? sounds not loaded,
? no mouse
13. It may also be helpful to test a site with a self-voicing browser (such as PWWebspeak)
14. Validate pages with tools such as:
? Bobby http://www.cast.org/bobby/
? W3C HTML Validation Service http://validator.w3.org/
For more information:
Good Web Site Design Practices - Chapter 25 in the Central Reference Document
Appendix A - Table examples
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".
Cups of coffee consumed by each senator
Name
Cups
Type of Coffee
Sugar?
T. Sexton
10
Espresso
No
J. Dinnen
5
Decaf
Yes
A speech synthesizer might render by speaking the following:
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.
This example might be rendered by a speech synthesizer as the previous example.
Cups of coffee consumed by each senator
Name
Cups
Type of Coffee
Sugar?
T. Sexton
10
Espresso
No
J. Dinnen
5
Decaf
Yes
3. "axis" - The following example shows how to create categories within a table.
Travel Expense Report
Meals
Hotels
Transport
subtotals
San Jose
25-Aug-97
37.74
112.00
45.00
26-Aug-97
27.28
112.00
45.00
subtotals
65.02
224.00&
90.00
379.02
Seattle
27-Aug-97
96.25
109.00
36.00
28-Aug-97
35.00
109.00
36.00
subtotals
131.25
218.00
72.00
421.25
Totals
196.27
442.00
162.00
800.27
Appendix B - Alt-text authoring guidelines
General recommendation
In general, authors should specify alternative text that describes the function of the graphic or image and
not its visual appearance. Authors should ask themselves this question: if you were reading the
document aloud over the telephone, what would you say upon encountering this image or graphic to
make the page comprehensible to the listener?
There are three attributes of IMG that can be used to provide textual information about an image:
? "alt" - should be used to give the functional and contextualized label or description (rather than
a visual description). Think of it as a textual replacement for users and search engines. It
should not bring to the attention of the user that a picture exists and should be grammatically
correct. End alt-text with punctuation (comma, colon, or period) to indicate a pause in reading,
when appropriate.
? "title" - This is a new attribute to HTML 4.0 to provide additional information about almost
every element (only HEAD, BODY, and 8 other elements do NOT support title as an
attribute). There is some argument as to its appropriate use as well as how it can be used in
combination with alt-text to maintain backwards compatibility.
? "longdesc" - used to provide a link to a page that has a complete visual description of the
image (required for charts, illustrations and other vital information). Be sure to convey the spirit
or the message of the image in long descriptions.
Note. Providing alternative text for images embedded with the OBJECT element is a different
beast and will be covered in the future.
Decorative graphics
Provide a brief textual equivalent of the image. Providing alt-text is required, while providing a longer
description is recommended.
Example:
Then, within sailboatsdesc.html:
A picture of ten sailboats docked in calm water at the edge of busy street in a small town.
Since some users may not want to see even a short description of the graphic, keep them as short as
possible. In the future, we will make recommendations for the use of style sheets, class values, and
XML that will allow users to select types of images they wish to download and view.
Bullets
1. Mark up list items correctly.
2. For unordered lists where bullets do not provide additional information use "Item:" as the alt-
text. Avoid using style sheets to provide alternative bullets until a way as been found to
associate alt-text with the image (see Example 2).
Example 1:
D
2. [New] Use the "longdesc" attribute of the IMG element. For example:
2. [New] The same idea, this time using the OBJECT element with flexibility to include
more information:
3. [New] The MAP element can be used with A elements to specify active region
geometries and provide contextual information.
Note in this example that the MAP element is the content of the OBJECT element so that
the alternative links will only be displayed if the image map (navbar1.gif) is not.
4. [Recommended]
Provide descriptive titles for images used as links.
Use the "title" attribute of the A element to provide more information about images used as
links. For example:
Then, within sailboatsdesc.html:
A picture of ten sailboats docked in calm water at the edge of busy street in a small town.
Since some users may not want to see even a short description of the graphic, keep them as short as
possible. In the future, we will make recommendations for the use of style sheets, class values, and
XML that will allow users to select types of images they wish to download and view.
Bullets
1. Mark up list items correctly.
2. For unordered lists where bullets do not provide additional information use "Item:" as the alt-
text. Avoid using style sheets to provide alternative bullets until a way as been found to
associate alt-text with the image (see Example 2).
Example 1: