[contents]
Copyright © 2004 W3C ® ( MIT , ERCIM , Keio), All Rights Reserved. W3C liability, trademark, document use rules apply.
This document provides information to Web content developers who wish to satisfy the success criteria of "Web Content Accessibility Guidelines 2.0" [WCAG20] (currently a W3C Working Draft). The techniques in this document are specific to Hypertext Markup Language content [HTML4], [XHTML1] although some techniques contain Cascading Style Sheet [CSS1] and ECMAScript solutions. Use of the illustrative techniques provided in this document may make it more likely for Web content to demonstrate conformance to WCAG 2.0 success criteria (by passing the relevant tests in the WCAG 2.0 test suite - to be developed) than if these illustrative techniques are not used.
There may be other techniques besides those provided in this document that may be used to demonstrate conformance to WCAG 2.0; in that case, it is encouraged to submit those techniques to the WCAG WG for consideration for inclusion in this document, so that the set of techniques maintained by the WCAG WG is as comprehensive as possible. Deprecated examples illustrate techniques that the Working Group no longer recommends, but may be applicable in some cases.
Note: WCAG 2.0 is a Working Draft and the cross-references between success criteria and techniques are not fully established.
This document is part of a series of documents published by the W3C Web Accessibility Initiative (WAI) to support WCAG 2.0.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document is prepared by the Web Content Accessibility Guidelines Working Group (WCAG WG) to show how HTML Techniques for WCAG 2.0 might read. This draft is not yet based on consensus of the WCAG Working Group nor has it gone through W3C process. This Working Draft in no way supersedes HTML Techniques for WCAG 1.0 published as a W3C Note September 2000. The WCAG WG intends to publish this as a Working Group Note at the same time or soon after WCAG 2.0 becomes a Recommendation.
Please refer to Issue tracking for WCAG 2.0 Techniques for HTML/XHTML for a list of open issues related to this Working Draft. The History of Changes to HTML Techniques for WCAG 2.0 Working Drafts is also available.
The Working Group welcomes comments on this document at public-comments-wcag20@w3.org. The archives for the public comments list are publicly available.
This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the WCAG WG are discussed in the Working Group charter. The WCAG WG is part of the WAI Technical Activity.
This is the HTML Techniques for Web Content Accessibility Guidelines 2.0 (WCAG 2.0). The guidelines provide a generic description of the requirements for a Web site that is accessible to people with disabilities. The HTML techniques provide an interpretation of the guidelines as applied to HTML and XHTML. This interpretation represents the best thinking of the Web Content Accessibility Guidelines working group and as such is a good guide to achieve conformance to WCAG 2.0. The Working Group encourages authors to implement these techniques where appropriate. Additionally the Working Group strongly encourages manufacturers of authoring tools to support the process of authoring content that conforms to these techniques, and encourages manufacturers or user agents, including assistive technologies, to implement the behaviors described by these techniques. However, these techniques do not provide a final definition of WCAG conformance and it is possible to meet guideline requirements without following these techniques. As new methods of conforming to the guidelines come to the attention of the Working Group, these techniques will be updated.
These techniques are intended for use both with HTML 4.01 and with XHTML 1.0/1.1. To encourage migration to newer technologies, examples for techniques are XHTML unless there is a specific reason to present an HTML example. Some references have not yet been updated to point preferentially to XHTML. This will be adjusted in a future draft of this document.
Note: Techniques in this document are known to contain errors. Recommendations will be rendered obsolete by future drafts. The purpose of this document is to receive feedback about the content of the techniques to ensure that future drafts are more accurate and useful. These techniques should not be implemented by people attempting to attain WCAG conformance at this time.
User agent support information is not included in this draft. In future drafts, the WCAG WG intends to provide this information to help authors decide which techniques to implement. Providing this information requires extensive user agent and assistive technology testing. The WCAG WG welcomes submissions of test result information that demonstrates user agent or assistive technology support (or lack of support) of existing techniques. Submissions of additional techniques are also welcome.
As work on the technology-specific checklists progresses, we expect to clearly distinguish between techniques required for conformance versus those that are optional. That distinction is not made in this Working Draft. The issue is captured as Issue #772 -"How do we make it clear that there are some techniques that are sufficient and some that are optional?"
This section discusses how to use metadata to increase the accessibility of Web content. Metadata is information about the content rather than the content itself. For example, the author, the creation date, expiration date, or primary language of the document. Metadata can be used by search engines to help users find content that has been made accessible or it can be used by the user agent (browser) to render the presentation in a way that fits the user's needs.
For more general information about Metadata refer to:
The Dublin Core Metadata Initiative, particularly the DC Accessibility Interest Group
Editorial Note: The WCAG WG anticipates that a separate techniques document will focus on metadata, semantic web issues, and RDF and will be referenced from this section.
!doctype statementThis technique relates to the following sections of the guidelines:
Use the !doctype statement to define the HTML or XHTML version of your document.
Validating to a published formal grammar and declaring that validation at the beginning of a document lets the user know that the structure of the document is sound. It also lets the user agent know where to look for semantics if it needs to. The W3C Validation Service validates documents against a whole list of published grammars.
It is preferable to validate to grammars that have been designed with accessibility in mind.
This is an example defining an English-language document as using the HTML 4.01 Transitional DTD.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
...
</head>
<body>
...
</body>
</html>
title elementThis technique relates to the following sections of the guidelines:
Use the title element to describe the document.
All documents, including individual frames in a frameset, should have a title element that defines in a simple phrase the purpose of the document. This helps users to orient themselves within the site quickly without having to search for orientation information in the body of the page.
Note that the (mandatory) title element, which only appears once in a document, is different from the title attribute, which may be applied to almost every HTML 4.01 element.
This example defines a document's title.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>The World Wide Web Consortium</title>
</head>
<body>
...
</body>
</html>
address elementThis technique relates to the following sections of the guidelines:
Use the address element to define a page's author.
Editorial Note: Describe how to use address to indicate contact information on the Web page.
Editorial Note: Question whether there is a particular accessibility benefit to this. If not, we should remove.
Editorial Note: Link to General technique about semantic markup.
This element can be used to provide information about the creator of the page.
<address> This document was written by <a href="mailto:yourname@example.com">Your Name</a> </address>
This technique relates to the following sections of the guidelines:
Provide a reference to a glossary.
If your page uses terms that are defined in a glossary document, use link
rel = "glossary" to reference the glossary of terms used on the page. This enables users to access the glossary quickly using user agent features.
This technique relates to the following sections of the guidelines:
Do not create a timed redirect.
meta
http-equiv of "{timeout}; url=... " is often used to automatically redirect users. The meta element should be used to specify metadata for a document such as keywords and information about the author.
Editorial Note: MC: I think we should clearly separate out the "surprise" problem from the misuse of meta problem, which isn't actually a violation.
It is acceptable to use the meta element to create a redirect when the timeout is set to zero. However, it is preferable to use server-side methods to accomplish this.
Editorial Note: Refer to HTTP techniques here.
This is a deprecated example which, using the meta element, forwards the user from one page to another after a timeout. However, this markup is non-standard, it disorients users, and it can disrupt a browser's history of visited pages.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Don't use this!</title>
<meta http-equiv="refresh"
content="5; url=http://www.example.com/newpage" />
</head>
<body>
<p>
If your browser supports Refresh, you'll be
transported to our
<a href="http://www.example.com/newpage">new site</a>
in 5 seconds, otherwise, select the link manually.
</p>
</body>
</html>
The meta element is used here to create an immediate redirect. Similar effects can be achieved using server-side techniques and are recommended over the use of the meta element.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Meta Redirect Example</title>
<meta http-equiv="refresh" content="0; url=http://www.example.com/newpage" />
</head>
<body>
<p>Please view our <a href="http://www.example.com/newpage">new site</a>.</p>
</body>
</html>
Editorial Note: Are there any examples we can use that are not deprecated? .htaccess is a server-side technique, perhaps point to that (after a server-side techniques document exists)
To be completed.
This technique relates to the following sections of the guidelines:
Do not cause a page to refresh automatically.
meta
http-equiv of "refresh" is often used to periodically refresh pages. If the time interval is too short, people who are blind will not have enough time to make their screen readers read the page before the page refreshes unexpectedly and causes the screen reader to begin reading at the top.
This is a deprecated example that changes the user's page at regular intervals. Content developers should not use this technique to simulate "push" technology. Developers cannot predict how much time a user will require to read a page; premature refresh can disorient users. Content developers should avoid periodic refresh and allow users to choose when they want the latest information.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>HTML Techniques for WCAG 2.0</title>
<meta http-equiv="refresh" content="60" />
</head>
<body>
...
</body>
</html>
This technique relates to the following sections of the guidelines:
Provide a site map and a description of accessibility features of the site.
Site maps can help all users find a page more readily when they already have a general idea of what they are looking for. If your site is highly visual in nature, the structure might be harder to navigate if the user can't form a mental map of where they are going or where they have been. The site map will help users discover the navigation mechanisms you have provided. Site maps are often presented as outlines, composed of nested lists, showing the hierarchy of pages. It may help to provide a summary of the contents of each page in the outline.
This technique relates to the following sections of the guidelines:
For collections of documents, use the link element to identify each document's position in the collection.
The link element in the head, used with the rel attribute, can provide metadata about the position of an HTML page within a collection of documents. The value of rel indicates what type of relation is being described, and the href provides a link to the document having that relation. Multiple link elements can provide multiple relationships. Several values of rel are useful:
Start: Refers to the first document in a collection of documents.
Next: Refers to the next document in a linear sequence of documents.
Prev: Refers to the previous document in an ordered series of documents.
Contents: Refers to a document serving as a table of contents.
Index: Refers to a document providing an index for the current document.
This technique relates to the following sections of the guidelines:
Use HTML header elements h1 through h6 to define the structure of the document.
Since some users skim through a document by navigating its headings, it is important to use them appropriately to convey document structure. Users should order heading elements properly. For example, in HTML, h2 elements should follow h1 elements, h3 elements should follow h2 elements, etc. Content developers should not "skip" levels (e.g., h1 directly to h3).
Long documents are often divided into a variety of chapters, chapters have subtopics and subtopics are divided into various sections, sections into paragraphs, etc. These semantic chunks of information make up the structure of the document.
Sections should be introduced with the HTML heading elements (hx). Other markup may complement these elements to improve presentation (e.g., the hr element to create a horizontal dividing line), but visual presentation is not sufficient to identify document sections.
Editorial Note: Edit this section to clarify "semantic chunks," "other markup," "introducing sections," "navigating its headings," etc.
Editorial Note: There has been some discussion about requiring h1 to be the first header on a page. It seems undesirable to restrict the use of header elements so far but some people support strengthening the semantics of headers. This will need further discussion.
Some authors object to using the HTML header elements because the default presentation in many browsers is unattractive. The appropriate solution is to use CSS to achieve the desired visual effect. Combined with classes and ids, a variety of presentational styles can be achieved while retaining a logical outline in the semantic structure. See CSS fonts for more information.
Editorial Note: Link to General technique about semantic markup.
Note that in HTML, heading elements (H1 - H6) only start sections, they don't contain them as element content. This HTML markup shows how style sheets may be used to control the appearance of a heading and the content that follows:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Cooking techniques</title>
<style type="text/css">
/* Indent heading and following content */
div.section2 { margin-left: 5% }
</style>
</head>
<body>
<h1>Cooking techniques</h1>
<p>
... some text here ...
</p>
<div class="section2">
<h2>Cooking with oil</h2>
... text of the section ...
</div>
<div class="section2">
<h2>Cooking with butter</h2>
... text of the section ...
</div>
</body>
</html>
This technique relates to the following sections of the guidelines:
Do not user headers solely for visual effects.
Do not use headings to create font effects. Instead, use CSS to change font styles. See CSS fonts for more information.
This section explains how and why to mark changes in language as well as identifying the primary language used for content. Many assistive technologies handle a variety of languages. When the language is not identified, assistive technologies often make a best guess using the default language set by the user. This often results in confusing pronunciations or displays.
Editorial Note: Needs clarification. "handle languages" "default language set by user" "confusing pronunciations" Perhaps add some sound clips and transcripts of confusing pronunciations and displays.
Editorial Note: [#580] Note that RFC1766 has now been obsoleted by RFC3066
This technique relates to the following sections of the guidelines:
Use the lang attribute of the html element to define the document's language.
It is good practice to identify the primary language of a document, either with markup (as shown in the example) or through HTTP headers. The lang attribute allows assistive technology to orient and adapt to the pronunciation and syntax that are specific to the language of the page. This attribute may also play a major role in the emerging global, multi-lingual, simultaneous translation web environment.
Editorial Note: Note the HTTP headers is not an HTML technique. But we should have some way of speaking to the effects of HTTP headers and the preference with respect to the lang attribute.
This example defines the content of an HTML document to be in the French language.
<html lang="fr" xmlns="http://www.w3.org/1999/xhtml">
<body>
...document écrit en français...
</body>
</html>
This technique relates to the following sections of the guidelines:
Use the lang attribute to identify changes in the natural language.
If you use a number of different languages on a page, make sure that any changes in language are clearly identified by using the lang or xml:lang attribute according to the HTML or XHTML version you use.
Note that HTML only offers the use of the lang attribute, while XHTML (transitionally) allows both attributes or only xml:lang, respectively, since lang was removed in XHTML 1.1.
Identifying changes in language are important for a number of reasons:
It will allow braille translation software to follow changes in language, e.g., substitute control codes for accented characters, and insert control codes necessary to prevent erroneous creation of Grade 2 braille contractions.
Editorial Note: We may want to put a glossary at the end of the document defining things like "Grade 2 braille contractions").
Similarly, speech synthesizers that "support" multiple languages will be able to speak the text in the appropriate accent with proper pronunciation. If changes are not marked, the synthesizer will try its best to speak the words in the primary language it works in. Thus, the French word for car, "voiture" would be pronounced "voter" by a speech synthesizer that uses English as its primary language.
Marking changes in language can benefit future developments in technology, for example users who are unable to translate between languages themselves will be able to use machines to translate unfamiliar languages.
This example uses the lang attribute of the span element to define one phrase as French and another as Italian.
<p> And with a certain <span lang="fr">je ne sais quoi</span>, she entered both the room, and his life, forever. "My name is Natasha," she said. "<span lang="it">Piacere,</span>" he replied in impeccable Italian, locking the door. </p>
This example demonstrates the use of the xml:lang attribute defining a quote written in German. This snippet could be included by an XHTML 1.1 document where lang is not allowed.
<blockquote xml:lang="de"> <p>Da dachte der Herr daran, ihn aus dem Futter zu schaffen, aber der Esel merkte, daß kein guter Wind wehte, lief fort und machte sich auf den Weg nach Bremen: dort, meinte er, könnte er ja Stadtmusikant werden.</p> </blockquote>
The techniques in this category demonstrate how to add structure to pieces of text. They refer to "inline" tags that allow control over the presentation of specific words and phrases in the document.
This technique relates to the following sections of the guidelines:
Use the strong and em elements, rather than b and i, to denote emphasis.
The em and strong elements were designed to indicate structural emphasis that may be rendered in a variety of ways (font style changes, speech inflection changes, etc.). The b and i elements were deprecated in HTML 4.01 and XHTML because they were used to create a specific visual effect.
Editorial Note: Link to General technique about semantic markup.
This example shows how to use the em and strong elements to emphasize text.
...What she <em>really</em> meant to say was, "This isn't ok, it is <strong>excellent</strong>!...
This technique relates to the following sections of the guidelines:
Use the abbr element to expand abbreviations where they first occur.
Mark up abbreviations with abbr and use title to indicate the expansion.
Editorial Note: Issue 295 Where and when and how often to indicate the expansion is still under discussion.
This also applies to shortened phrases used as headings for table row or columns. If a heading is already abbreviated provide the expansion in abbr. If a heading is long, you may wish to provide an abbreviation as described in
Terse substitutes for header labels (optional)
.
Editorial Note: There are a number of questions about abbreviation and Acronym . Although these have undergone much discussion, there is not yet enough consensus to create solid techniques. These issues include: * uncertain whether these elements need to be marked up on the first occurrence on the page or for every instance, * unclear on the distinction between abbreviations and acronyms, in English and other languages, * the HTML Working group has proposed removing the acronym element in favor of a single abbreviation element for all cases, * how common must a word be before it need not be marked up this way.
This example shows how to use the abbr element properly.
<p>Welcome to the <abbr title="World Wide Web">WWW</abbr>!</p>
This example shows how to use the abbr attribute in a table heading.
<table>
<tr>
<th>First name</th>
<th abbr="SS#">Social Security Number</th>
</tr>
...
</table>
This technique relates to the following sections of the guidelines:
Use the acronym element to expand acronyms where they first occur.
Mark up acronyms with acronym and use title to indicate the expansion.
Editorial Note: Issue 295 Where and when and how often to indicate the expansion is still under discussion.
This example shows how to use the acronym element.
<acronym title="Keep It Simple Stupid">KISS</acronym>
This technique relates to the following sections of the guidelines:
Do not create blinking content with the blink element.
Do not use the blink element. There are several reasons for this:
Blinking content can provide accessibility problems.
The blink element is not part of the HTML specification. Use CSS if you must have blinking content. Refer to the CSS Techniques for WCAG 2.0 Underlining, overlining, and blinking.
This technique relates to the following sections of the guidelines:
Do not create scrolling text with the marquee element.
Do not use the marquee element to create scrolling text. There are several reasons for this:
Scrolling content can provide accessibility problems.
The marquee element is not part of the HTML specification.
Editorial Note: Use script instead? If so, create and link to a technique in Client-side Scripting Techniques for WCAG 2.0.
This technique relates to the following sections of the guidelines:
Use the q element to mark up short inline quotations.
The q element marks up inline quotations.
NOTE:The q element, though designed for semantic markup, is unsupported, or poorly-supported, in most browsers. So this is a future technique.
Editorial Note: Link to General technique about semantic markup.
This technique relates to the following sections of the guidelines:
Use the blockquote element to mark up block quotations.
The blockquote element marks up block quotations.
Editorial Note: Link to General technique about semantic markup.
This example marks up a longer quotation with blockquote:
<blockquote cite="http://www.example.com/loveslabourlost">
<p>
Remuneration! O! that's the Latin word for
three farthings. --- William Shakespeare
(Love's Labor Lost).
</p>
</blockquote>
blockquote
This technique relates to the following sections of the guidelines:
Do not use the blockquote element for formatting effects such as indentation.
Only use blockquote to indicate a quotation. Do not use it to create an indented effect on the page. blockquote is a semantic element and using it improperly can confuse the user.
Editorial Note: We need to provide pointers to alternate ways to achieve the desired effect.
title attributeUse the title attribute where appropriate.
In general, one can provide supplementary information about elements using the title attribute. The attribute value contains the content. Refer to Conditional Content in the User Agent Accessibility Guidelines for information on how this information may be presented to the user.
Note that while the title attribute is permitted and can be used as supplemental content for most elements in HTML, there are some elements for which particular usages are recommended for accessibility purposes. Refer to:
There are also situations in which accessibility requirements are that title should not be used, even though it is permitted by HTML. Refer to:
For tables: The caption element (optional) and Summarizing data tables (optional)
There is discussion about the use of title on images. Issue 654.
Editorial Note: It is expected that the General Techniques will define what "supplementary information" is and how it should be used.
Editorial Note: Refer to Issue 229: we are uncertain about what user agent support is, or should be, for title. Resolution of that issue will impact the recommendations we make here.
This technique relates to the following sections of the guidelines:
Use the span element with the title attribute to provide generic meaning cues.
Words that may have ambiguous meanings, because they are unfamiliar terms, idioms, contractions, or have multiple meanings can be clarified with the title attribute. If there is not a special element for the type of disambiguation to be performed, apply this to a span element.
Use structural markup instead of presentational markup, and use CSS for presentation.
Avoid using the following HTML elements, and use the appropriate CSS instead.
b
i
tt
big
small
strike
s
u
font
basefont
These elements are not prohibited, but it is recommended to either use other semantic elements or use CSS when feasible. Refer to discussion at Strongly emphasizing semantics.
Editorial Note: Include a list of each HTML element that should be replaced, and the CSS property/value(s) that can be used. Talk about structural markup a bit too, and/or cross reference.
This technique relates to the following sections of the guidelines:
If you must use HTML elements to control font information, use big and small, which are not deprecated.
This technique relates to the following sections of the guidelines:
Use structural elements as needed.
The HTML 4.01 specification defines the following structural elements for miscellaneous markup needs:
cite
Contains a citation or a reference to other sources.
dfn
Indicates that this is the defining instance of the enclosed term.
code
Designates a fragment of computer code.
samp
Designates sample output from programs, scripts, etc.
kbd
Indicates text to be entered by the user.
var
Indicates an instance of a variable or program argument.
ins
Indicates text inserted into a document.
del
Indicates text deleted from a document.
Editorial Note: How often are these elements used? Are they supported by assistive technologies? The code element is used often in W3C documents, what about elsewhere? Should we keep this section? Perhaps keep it but make it clear it is for completeness and information?
Editorial Note: This is about several elements so perhaps should be split up. But it's really just a list of structural elements. Do we need that list in techniques? Can we point to some resource (e.g., HTML spec) in a single technique and say "use structural elements per the HTML spec"? Or do we have to list every possible structural element we want people to use - including the obvious ones like p?
Editorial Note: Link to General technique about semantic markup.
This technique relates to the following sections of the guidelines:
Ensure that color contrast is sufficient.
Ensure that color contrasts sufficiently.
Note that it is preferred to use CSS for color, see CSS instead of presentational markup .
Editorial Note: Provide a list of HTML color attributes.
Use relative size instead of absolute.
Editorial Note: From Issue 1066: The issue of relative size (or scalable content) isn't dealt with yet in WCAG 2.0. In part it seems the belief is this should be a user agent issue, not an authoring issue. However, in reality it is currently also an authoring issue. Anyway Web Content guidelines should specify that content should be scalable regardless of whose responsibility it is to fulfill the guideline. Issue 1012 deals with CSS size, and the questions raised there also affect this issue. In particular, there is no home in the guidelines for this technique. Nevertheless the technique should exist in the next draft as a hook for discussion.
The HTML list elements dl, ul, and ol should only be used to create lists. Do not use lists for formatting effects such as indentation. Refer to information on CSS and tables for layout in the CSS Techniques.
Until either CSS2 is widely supported or user agents allow users to control rendering of lists through other means, authors should consider providing contextual clues in unnumbered nested lists. Non-visual users may have difficulties knowing where a list begins and ends and where each list item starts. For example, if a list entry wraps to the next line on the screen, it may appear to be two separate items in the list. This may pose a problem for legacy screen readers.
Editorial Note: Do we still need this note? How is current support for nested lists? Which versions of which screen readers handle nested lists well?
Editorial Note: From 2003-07-30 teleconference: We need techniques for UL, OL, DL, examples that don't rely on CSS, and technique for older AT that don't support nested lists well
This technique relates to the following sections of the guidelines:
Format ordered lists so their items can be followed logically.
Ordered lists help non-visual users navigate. Non-visual users may "get lost" in lists, especially in nested lists and those that do not indicate the specific nest level for each list item. Until user agents provide a means to identify list context clearly (e.g., by supporting the ':before' pseudo-element in CSS2), content developers should include contextual clues in their lists.
For numbered lists, compound numbers are more informative than simple numbers. Thus, a list numbered
1
1.1
1.2
1.2.1
1.3
2
2.1
provides more context than the same list without compound numbers, which might be formatted as follows:
1.
1.
2.
1.
3.
2.
1.
and would be spoken as "1, 1, 2, 1, 2, 3, 2, 1", conveying no information about list depth.
[CSS1] and [CSS2] allow users to control number styles (for all lists, not just ordered) through user style sheets.
Editorial Note: As above, how well do current screen readers support nested lists? How well is the support for CSS control of list styles?
The CSS2 style sheet in this example shows how to specify compound numbers for nested lists created with either UL or OL elements. Items are numbered as "1", "1.1", "1.1.1", etc.
<style type="text/css">
li {
display: block;
}
li:before {
content: counters(item, ".");
counter-increment: item;
}
ul, ol {
counter-reset: item;
}
</style>
This technique relates to the following sections of the guidelines:
Do not use list elements for presentational effects.
Do not use list elements, such as the ul and ol elements, to achieve indentation effects when a list is not indicated. The most common example of this misuse is to use list container elements without li children. li elements are sometimes used outside the context of list containers, which also presents an unclear semantic.
Editorial Note: We need to provide pointers to alternate ways to achieve the desired effect.
This section discusses the accessibility of tables and elements that one can put in a table element.
Editorial Note: The resolution of issue 248 will effect this section. Include definition of "data table" here and "layout table" in the next section.
Editorial Note: Describe how to determine if a table is a data table or a layout table. Discuss why it is so important to mark up data tables correctly. Show bad example (e.g., Matt's W3N stock table) and the issues created by bad markup. Use real examples or create derivatives.
Tables should not be used to position elements graphically. Tables used in this way, known as "layout tables", do not observe the implication of tabular data inherent in the term "table", and can create particular accessibility problems as described in the section Layout Tables. Generally, display technologies such as [CSS2] can achieve the desired layout effect with improved accessibility.
caption element (optional)This technique relates to the following sections of the guidelines:
Use the caption element to describe the nature of data tables.
Provide a caption via the caption element. A table caption describes the nature of the table in one to three sentences. Two examples:
"Cups of coffee consumed by each senator."
"Who spends the most on pollution cleanup?"
An optional method is to use the title attribute on the table element, but the caption is preferred because of the semantics of the element.
Use the summary attribute to describe the purpose and structure of data tables.
It is rare to use both the caption element and the summary attribute since one or the other should be enough to provide a description.
Summaries are useful for non-visual readers. A summary may also describe how the table fits into the context of the current document. Two examples:
"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."
"Total required by pollution control standards as of January 1, 1971. Commercial category includes stores, insurance companies and banks. The table is divided into two columns. The left-hand column is 'Total investment required in billions of dollars'. The right--hand column is 'Spending' and is divided into three sub-columns. The first sub-column is titled '1970 actual in millions of dollars', the second is '1971 planned in millions of dollars', and the third is 'Percent change, 1970 versus 1971.' The rows are industries." [NBA, 1996].
An optional method is to use the title attribute on the table element, but the summary attribute is preferred because of the semantics of the attribute.
Editorial Note: There is still not consensus about the ideal use of summaries for tables. A discussion about summaries began but there is still need for more review and comments on this. See also Summaries of layout tables .
Use the abbr attribute on th elements to provide terse substitutes for header labels.
When supported, short heading labels will decrease repetition and reading time when tables are read aloud.
This technique relates to the following