Abstract

This document describes techniques for creating accessible Hypertext Markup Language content [HTML4], [XHTML1]. This document is intended to help authors of Web content who wish to claim conformance to "Web Content Accessibility Guidelines 2.0" [WCAG20]. While the techniques in this document should help people author HTML that conforms to "Web Content Accessibility Guidelines 2.0", these techniques are neither guarantees of conformance nor the only way an author might produce conforming content.

Note: This document contains a number of examples that illustrate accessible solutions in CSS but also deprecated examples that illustrate what content developers should not do. The deprecated examples are highlighted and readers should approach them with caution -- they are meant for illustrative purposes only.

Status of this Document

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 content of this draft has not changed significantly since the September 2000 draft, although we have attempted to provide a code example and "checklist item" for every technique. This draft signifies a renewed effort by the WCAG WG to provide guidance on using X/HTML to create accessible content.

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

Introduction

Cross references to Guidelines have not been included, except for one technique to show how they appear - see Short text equivalents for img elements ("alt-text"). The guidelines are currently in flux and it would be difficult to create meaningful and persistent references. Future versions of this document will include complete guideline information.

To encourage migration to newer technologies, examples for techniques are XHTML unless there is a specific reason to use HTML. Some references have not yet been updated to point preferentially to XHTML. This wil be adjusted in a future draft of this document.

Language about this document is known to contain errors and will be rendered obsolete...

1 Uncategorized techniques

1.1 Use of the title attribute

Checklist item:

The title attribute is used where appropriate.

In general, one can provide supplementary information about elements using the title attribute. The attribute value contains the content.

Note that while the title attribute is permitted and can be used in this way on most elements in HTML, there are some elements for which different usages are recommended for accessibility purposes. Refer to:

Editorial Note: It is expected that the Techniques Gateway will define what "supplementary information" is and how it should be used.

1.2 Meta redirect

Checklist item:

metahttp-equiv of "refresh; url=..." is not used to automatically redirect users.

This element can specify metadata for a document including keywords, and information about the author. Please refer to the section on automatic page refresh for information on why META should not be used to redirect or auto-refresh pages.

Deprecated Example:

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.

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.

1.3 Meta refresh

Checklist item:

metahttp-equiv of "refresh" is not used to periodically refresh pages.

2 Metadata

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.

2.3 The !doctype statement

Checklist item:

The !doctype statement defines the HTML or XHTML version of documents.

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.

2.4 The link element and navigation tools

Checklist item:

The link element is used to describe the structure of documents.

Content developers should use the link element and link types (refer to [HTML4] section 6.12) to describe document navigation mechanisms and organization. Some user agents may synthesize navigation tools or allow ordered printing of a set of documents based on such markup.

Example:

The following link elements might be included in the head of chapter 2 of a book:

All of these grouping mechanisms should be used when appropriate and natural, i.e., when the information lends itself to logical groups. Content developers should not create groups randomly, as this will confuse all users.

3.1 Section headings

Checklist item:

Header elements (h1 through h6) are used, in order, to define the structure of documents.

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 (h1-h6). 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.

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). Do not use headings to create font effects; use style sheets to change font styles for example.

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:

3.2 Style headers

Checklist item:

CSS (not HTML header elements) are used to create font effects.

Editorial Note: Should this be a CSS technique? Or in a category of "don't abuse markup"?

4 Language

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.

4.1 Identifying changes in language

Checklist item:

The lang attribute is used to identify changes in the natural language of a document.

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

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 erroneus 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 developements in technology, for example users who are unable to translate between languages themselves will be able to use machines to translate unfamiliar languages.

Example:

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. &quot;My name is Natasha,&quot; she said.
&quot;<span lang="it">Piacere,</span>&quot; he
replied in impeccable Italian, locking the door.
</p>

4.2 Identifying the primary language

Checklist item:

The lang attribute of the html element is used to define the natural language of documents.

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.

Example:

This example defines the content of an HTML document to be in the French language.

5 Text Markup

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.

5.1 Emphasis

Checklist item:

strong and em elements, (not b and i elements) are used 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.

Example:

This example shows how to use the em and strong elements to emphasize text.

...What she <em>really</em> meant to say was,
&quot;This isn't ok, it is <strong>excellent</strong>!...

5.2 Abbreviations

Checklist item:

abbr elements are used to expand abbreviations where they first occur.

Mark up abbreviations with abbr and use title to indicate the expansion.

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 Data Tables: The caption element.

Editorial Note: Describe the difference between abbreviations and acronyms (a very FAQ).

5.6 Misuse of blockquote

Checklist item:

blockquote elements are NOT used 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.

5.7 Markup and style sheets rather than images: The example of math

Checklist item:

Markup, rather than images is used to convey information wherever possible.

Editorial Note: Does this section fit best here or with images or on its own? Perhaps pull bit about ascii art from images and combine with this into a separate section called "Markup and Style Sheets" ? or perhaps create a more general section in Gateway Techniques that would discuss benefits of marking text as text rather than developing raster images.

Using markup (and style sheets) where possible rather than images (e.g., a mathematical equation, link text instead of image button) promotes accessibility for the following reasons:

Text may be magnified or interpreted as speech or braille.

Search engines can use text information.

As an example, consider these techniques for putting mathematics on the Web:

For more complex equations, mark them up with MathML [MATHML] or TeX. Note. MathML can be used to create very accessible documents but currently is not as widely supported or used as TeX.

Provide a text description of the equation and, where possible, use character entity references to create the mathematical symbols. A text equivalent must be provided if the equation is represented by one or more images.

TeX is commonly used to create technical papers that are converted to HTML for publication on the Web. However, converters tend to generate images, use deprecated markup, and use tables for layout. Consequently, content providers should:

Make the original TeX (or LaTeX) document available on the Web. There is a system called "AsTeR" [ASTER] that can create an auditory rendition of TeX and LaTeX documents. Also, IBM has a plug-in for Netscape and Internet Explorer that reads TeX/LaTeX documents and some of MathML (refer to [HYPERMEDIA]). Note. These tools work primarily in the English environment and may not work so well with speech synthesizers whose primary language is not English.

Ensure that the HTML created by the conversion process is accessible. Provide a single description of the equation (rather than "alt" text on every generated image as there may be small images for bits and pieces of the equation).

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 obviousl ones like p?

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 telecon: 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

6.1 Ordered lists

Checklist item:

Ordered lists are formatted such that 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?

Example:

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.

6.2 Use style sheets to change list bullets

Checklist item:

Images used as bullets are created using CSS.

To change the bullet style of unordered list items created with the li element, use style sheets. In CSS, it is possible to specify a fallback bullet style (e.g., "disc") if a bullet image cannot be loaded.

Editorial Note: Same issue as in Style headers; should this be moved to CSS?

Example:

This example sets bullets in an unordered list to an image called "star.gif", or, alternatively, a disc.

7 Data Tables

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.

7.1 The caption element

Checklist item:

The caption element is used to describe the nature of data tables. (optional)

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

7.2 The title attribute on the table element

Checklist item:

The title attribute is used to provide additional descriptive information. (optional, summary or caption are preferred)

The title attribute does not imply additional meaning or context and can be applied to any element; the summary attribute and caption element were designed specifically for use on tables. Thus, titleis not the preferred method to provide a description of a data table.

7.3 Summarizing tables

Checklist item:

The summary attribute is used to describe the purpose and structure of tables. (optional)

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

7.4 Terse substitutes for header labels

Checklist item:

The abbr attribute on th elements is used to provide terse substitutes for header labels. (optional)

When supported, short heading labels will decrease repetition and reading time when tables are read aloud.

7.5 Identifying groups of rows

Checklist item:

thead is used to group repeated table headers, tfoot for repeated table footers, and tbody for other groups of rows. (optional)

Editorial Note: Describe the use and benefits of row structure elements. Clearly explain when it is a good idea to use these. Use Joe's example of tbody.

7.6 Identifying groups of columns

Checklist item:

Editorial Note: Describe the use and benefits of column structure elements. Much of this may be theoretical.

7.7 Specifying the set of data cells for which each header cell provides header information.

Checklist item:

The scope attribute is used to specify the set of data cells for which each header cell provides header information.

When browsers and assistive technologies know which headers apply to which data cells, the header information is available for each cell and can be displayed or read in association with the data.

Editorial Note: Need support information for scope, headers, and axis techniques. Provide information to help determine which technique (scope, headers, or axis) to use.

7.8 Associating header cells with data cells.

Checklist item:

The headers attribute is used on each data cell to associate a list of header cells that provide header information.

For more complicated tables (where the scope attribute can not be applied because the relationship applies to more than two headers), the headers attribute allows you to associate more than two headers with each data cell.

7.9 Categorizing data cells.

Checklist item:

The axis attribute is used to place a cell into a conceptual category.

Conceptual categories can be used to group data that might be similar but fall under different headings. For example, "meals" is a category that could be applied to numbers that fall under both the "San Jose" and "Seattle" headings.

7.10 Misuse of the pre element.

Checklist item:

The pre element is NOT used to create tabular layout.

The pre element is not used to create tabular layout; the table elements is used. Watch out for pre markup within a table.

Editorial Note: Is using br a separate issue or included in the pre issue? Perhaps make this more general? i.e., use tables appropriately, don't use pre or br to format data?

7.11 Row and column headings.

Checklist item:

The th element is used to indicate which cells contain header information. (only applies to data tables)

For information about table headers, refer to the table header algorithm and discussion in the HTML 4.01 Recommendation [HTML4], section 11.4.3

Example:

This example shows how to associate data cells (created with td) with their corresponding headers by means of 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 attribute.

A speech synthesizer might render this tables 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

This example associates the same header (th) and data (td) cells as the previous example, but this time 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. It should be noted that the spoken rendering of this table would be identical to that of the previous example. A choice between the headers and scope attributes is dependent on the complexity of the table. It does not affect the output so long as the relationships between header and data cells are made clear in the markup.

This example shows how to create categories within a table using the axis attribute.

This table lists travel expenses at two locations: San Jose and Seattle, by date, and category (meals, hotels, and transport). The following image shows how a visual user agent might render it.
[Description of travel table]

8 Tables for layout

Editorial Note: Refer to section (to be written) at beginning of "Data Tables" that provides information about deciding if a table is used for data or layout.

Authors should consider using style sheets for layout and positioning. However, when it is necessary to use a table for layout, the table must linearize in a readable order. When a table is linearized, the contents of the cells become a series of paragraphs (e.g., down the page) one after another. Cells should make sense when read in row order and should include structural elements (that create paragraphs, headings, lists, etc.) so the page makes sense after linearization.

Also, when using tables to create a layout, do not use structural markup to create visual formatting. For example, the TH (table header) element, is usually displayed visually as centered, and bold. If a cell is not actually a header for a row or column of data, use style sheets or formatting attributes of the element.

8.1 Table elements allowed in layout tables

Checklist item:

The td, table, and trelements and the border, cellspacing, and cellpadding attributes are only used in layout tables. th, tbody, caption, colgroup, tfoot, and thead are NOT used in layout tables.

The th element is used to create header information for data cells. When the th element is used, user agents and assistive technologies might try to associate the contents of the cell with others in the same column or row. If a user knows the table is used for layout, they can use different navigation strategies to make sense of the table.

Editorial Note: The HTML 4.01 spec seems to preclude using the td element for anything except data. The HTML WG has said that tables are only for data (full stop). We need to solicit HTML WG feedback about this section.

8.2 Summaries of layout tables

Checklist item:

If the summary is used on a layout table, the value is null (summary="")

Using a null summary is similar to a null alt-text; the author is indicating that the table is used for presentation purposes.

8.3 Linear reading order of tables

Checklist item:

Logical reading order of cells is created in layout tables.

Editorial Note: Instead of providing a linear text alternative, ensure that the table can be linearized.

Tables used to lay out pages where cell text wraps pose problems for older screen readers that do not interpret the source HTML or browsers that do not allow navigation of individual table cells. These screen readers will read across the page, reading sentences on the same row from different columns as one sentence.

For example, if a table is rendered like this on the screen:

There is a 30% chance of Classes at the University
rain showers this morning, of Wisconsin will resume
but they should stop before on September 3rd.
the weekend.

This might be read by a screen reader as:

There is a 30% chance of Classes at the University rain showers this morning, of Wisconsin will resume but they should stop before on September 3rd. the weekend.

Screen readers that read the source HTML will recognize the structure of each cell, but for older screen readers, content developers may minimize the risk of word wrapping by limiting the amount of text in each cell. Also, the longest chunks of text should all be in the last column (rightmost for left-to-right tables). This way, if they wrap, they will still be read coherently. Content developers should test tables for wrapping with a browser window dimension of "640x480".

Editorial Note: Internationalization issues with recommending longest text in last column? Wrapping less of an issue these days? Can test wrapping by increasing font size or resizing window, don't need to give exact dimensions do we?

Since table markup is structural, and we suggest separating structure from presentation, we recommend using style sheets to create layout, alignment, and presentation effects. Thus, the two columns in the above example could have been created using style sheets. Please refer to the section on style sheets for more information.

It is usually very simple to linearize a table used to layout a page - simply strip the table markup from the table. There are several tools that do this, and it is becoming more common for screen readers and some browsers to linearize tables.

However, linearizing data tables requires a different strategy. Since data cells rely on the information provided by surrounding and header cells, the relationship information that is available visually needs to be translated into the linear table.

For example, specify the column layout order. The natural language writing direction may affect column layout and thus the order of a linearized table. The dir attribute specifies column layout order (e.g., dir="rtl" specifies right-to-left layout).

Editorial Note: also the case for layout tables?

Editorial Note: Provide an example

Editorial Note: again, there are tools to help produce linearized versions of data tables. We will provide a link

This markup will also help browsers linearize tables (also called table "serialization"). A row-based linear version may be created by reading the row header, then preceding each cell with the cell's column header. Or, the linearization might be column-based. Future browsers and assistive technologies will be able to automatically translate tables into linear sequences or navigate a table cell by cell if data is labeled appropriately. The WAI Evaluation and Repair Tools Working Group maintains a list of tools some of which help authors determine if tables will linearize in a readable order. Refer to [WAI-ER].

Quicktest!
To get a better understanding of how a screen reader would read a table, run a piece of paper down the page and read your table line by line.

9 Links

This section explains how to create hyperlinks that are compatible and comprehensible to users of assistive technologies.

9.1 Supplement link text with the title attribute.

Checklist item:

The title attribute of the a element is used to clarify links where appropriate.

Editorial Note: We're not sure how the title attribute should relate to the link text.

9.2 Text for images used as links

Checklist item:

Text equivalents are provided for images that are used as links.

When an image is used as the content of a link, specify a text equivalent for the image. The text equivalent should describe the function of the link.

Example:

This example uses the alt attribute of the img element to describe a graphical link.

9.4 Link Groups

Checklist item:

Links are grouped structurally and identified with the title attribute.

Group links via one of the following mechanisms (in descending order of preference):

ul or ol

div

map

When links are grouped into logical sets (for example, in a navigation bar that appears on every page in a site) they should be marked up as a unit. Navigation bars are usually the first thing someone encounters on a page. People who are sighted are often able to ignore navigation parts and start reading the content of the page. Someone using a screen reader must first listen to the text of each link in the navigation bar before reading the interesting content. There are several ways to mark up content so that a user with a screen reader can jump over the navigation bar and avoid reading all of the links.

Although graphical menus and link groups are accessible when alt attributes are used, there
are advantages to creating navigation menus that are completely text-based. Graphical
text is not easily scalable. The size of graphical text cannot be increased
easily by those who may need a larger font. Alternatively, text based menus
allow for relative font sizes to be used on menu links. Relative font sizes
can be easily increased in most browsers without the use of assistive
technology.

Editorial Note: The above paragraph outlines benefits for using text-based navigation. It may be appropriate to expand these ideas into an optional technique in a future draft.

9.5
tabindex to skip link groups (@@ future)

Checklist item:

The HTML 4.01 tabindexattribute is used to allow users to jump to an anchor after the set of navigation links. This attribute is not yet widely supported.

9.6 Skipping Link Groups

Checklist item:

A link that allows users to skip over grouped links is provided.

Editorial Note: Describe how to skip link groups with a link and a bookmark anchor.

Example:

In this example, the map element groups a set of links, the title attribute identifies it as a navigation bar, tabindex is set on an anchor following the group, and a link at the beginning of the group links to the anchor after the group. Also, note that the links are separated by non-link, printable characters (surrounded by spaces).

9.7 Hide link groups

Checklist item:

A style sheet is provided that allows users to hide the set of navigation links.

CSS to hide link groups

9.8 Keyboard access

Checklist item:

The accesskey attribute of navigational elements is used to allow rapid keyboard access.

Keyboard access to active elements of a page is important for many users who cannot use a pointing device. User agents may include features that allow users to bind keyboard strokes to certain actions. HTML 4.01 allows content developers to specify keyboard shortcuts in documents via the accesskey attribute.

Note: Until user agents provide an overview of which key bindings are available, provide information on the key bindings.

Example:

In this example, if the user activates Alt + C (in most user agents), the link will be followed.

<a accesskey="C" href="doc.html">XYZ company home page</a>

Example:

This example assigns "U" as the accesskey (via accesskey). Typing the access key modifier plus the key, e.g., Alt + U, gives focus to the label, which in turn gives focus to the input control, so that the user can input text.

9.10 Using FRAME targets (@@ deprecated)

Checklist item:

Pop-ups or other windows do not appear and the current window is not changed without informing the user.

Content developers should avoid specifying a new window as the target of a frame with target="_blank".

Editorial Note: This should be relaxed to fit current WCAG 2.0 thinking. i.e., "extreme changes in context are identified before they occur so the user can determine if they wish to proceed or so they can be prepared for the change" Thus, pop-ups are allowed as long as the user is notified before the pop-up appears. Also, more and more user agents may be configured to not display pop-ups or display them in the background, thus no change in context effects the user.

10.7 Describe images without longdesc

Checklist item:

Editorial Note: We hope to deprecate this technique in the future but right now felt it is useful.

Guideline 10.1 ASCII Art

10.1 ASCII art

Checklist item:

A means to skip over multi-line ASCII art is provided.

Avoid ASCII art (character illustrations) and use real images instead since it is easier to supply a text equivalent for images. However, if ASCII art must be used provide a link to jump over the ASCII art.

If the ASCII art is complex, ensure that the text equivalent adequately describes it.

Example:

A link, placed before ASCII art, targets a named anchor after the ASCII art.

10.2 Emoticons

Checklist item:

Emoticons and other ASCII symbols are used judiciously.

Another way to replace ASCII art is to use human language substitutes. For example, <wink>might substitute for a winking smiley: ;-). Or, the word "therefore" can replace arrows consisting of dashes and greater than signs (e.g., -->), and the word "great" for the uncommon abbreviation "gr8".

Example:

Another option for smaller ascii art is to use an abbr element with title.

<abbr title="smiley in ASCII art">:-)</abbr>

Guideline 10.2 Image Maps

An image map is an image that has "active regions". When the user selects one of the regions, some action takes place -- a link may be followed, information may be sent to a server, etc. To make an image map accessible, content developers must ensure that each action associated with a visual region may be activated without a pointing device.

10.1 Use Client Side Image Map

Checklist item:

Client-side image maps are used instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

Image maps are created with the map element. HTML allows two types of image maps: client-side (the user's browser processes a URI) and server-side (the server processes click coordinates). For all image maps, content developers must supply a text equivalent.

10.2 Provide text links for server side image maps.

Checklist item:

Redundant text links for each active region of a server-side image map are provided.

If server-side image maps must be used (e.g., because the geometry of a region cannot be represented with values of the shape attribute), authors must provide the same functionality or information in an alternative accessible format. One way to achieve this is to provide a textual link for each active region so that each link is navigable with the keyboard. If you must use a server-side image map, please consult the section on server-side image maps

When a server-side image map must be used, content developers should provide an alternative list of image map choices. There are three techniques:

Include the alternative links within the body of an object element (refer to the previous example illustrating links in the object element).

If img is used to insert the image, provide an alternative list of links after it and indicate the existence and location of the alternative list (e.g., via that alt attribute).

If other approaches don't make the image map accessible, create an alternative page that is accessible.

Example:

A server side image map with duplicate text links provided on the page.

10.3 Provide redundant text links for client side image map.

Checklist item:

Redundant text links for each active region of a client-side image map are provided.

In addition to providing a text equivalent for client side image map regions, provide redundant textual links. For each area, provide an a on the page with the same href and the same link text as the alt of the area. If the a element is used instead of area, the content developer may describe the active regions and provide redundant links at the same time.

Editorial Note: The last sentence describes a practices that works inconsistently if at all. See Roberto Scano's post. Should we remove it?

Editorial Note: In WCAG 1 this is an "until user agents" requirement. Wat should we do with it?

10.4 Provide alt for area.

Checklist item:

Alternative text for the area element is provided.

Provide text equivalents for image maps since they convey visual information. As with other links, the link text should make sense when read out of context. Refer to the section on Links for information on writing good link text. Users may also want keyboard shortcuts to access frequently followed links. Refer to the section on Keyboard access to links.

11 Programmatic objects and applets

The object element in HTML allows authors to embed programmatic code written in other languages, such as Java or Macromedia Flash. However, not all user agents are able to process these objects. Many users of assistive technologies are not able to access the content in programmatic objects. This section explains how to ensure that the content you provide is accessible to those users.

11.1 Text and non-text equivalents for applets and programmatic objects

11.2 Alt content for embed

Checklist item:

Alternative content for embed is provided with noembed.

Provide alternative content for the embed element in a noembed element. The noembed is rendered only if the embed is not supported. While it can be positioned anywhere on the page, the best location is beside or as a child of embed.

Editorial Note: Is it true that noembed can go either beside or inside embed? Is there a preference?

11.4 Embedding multimedia objects

Checklist item:

The embed element within the object element is provided for backward compatibility.

Some objects, such as those requiring a plug-in, should also use the object element. However, for backward compatibility with Netscape browsers, use the proprietary embed element within the object element as follows:

12 Frames

For visually enabled users, frames may organize a page into different zones. For non-visual users, relationships between the content in frames (e.g., one frame has a table of contents, another the contents themselves) must be conveyed through other means.

Frames as implemented today (with the frameset, frame, and iframe elements) are problematic for several reasons:

Without scripting, they tend to break the "previous page" functionality offered by browsers.

It is impossible to refer to the "current state" of a frameset with a URI; once a frameset changes contents, the original URI no longer applies.

Opening a frame in a new browser window can disorient or simply annoy users.

12.1 Providing a frame title

Checklist item:

The title attribute of the frame element is used.

Use the title attribute of the frame element to describe the contents of each frame. This provides a label for the frame so users can determine which frame to enter and explore in detail.

Note that the title attribute labels frames, and is different from the title element which labels documents. Both should be provided, since the first facilitates navigation among frames and the second clarifies your current location.

The title attribute is not interchangable with the name attribute. The title labels the frame for users; the name labels it for scripting and window targeting. The name is not presented to the user, only the title is.

12.2 Describing frame relationships (@@ deprecated)

Checklist item:

The longdesc attribute of the frame element describes the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.

The use of longdesc (long description) in frames is not recommended
because the longdesc attribute in frames is currently not well supported by user
agents.

Editorial Note: Note that if the a frame's contents change, the text equivalent will no longer apply. Also, links to descriptions of a frame should be provided along with other alternative content in the noframes element of a frameset.

Example:

This example uses the longdesc attribute of the frame element to link to a document called "frameset-desc.html", which contains this copy:

#Navbar - this frame provides links to the major sections of the site: World News, National News, Local News, Technological News, and Entertainment News.

#Story - this frame displays the currently selected story.

#Index - this frame provides links to the day's headline stories within this section.

12.3 Writing for browsers that do not support FRAME

Checklist item:

The noframes element is used to support user agents that don't support frames.

Provide meaningful content in the noframes element. noframes follows the frameset and contains a body element.

Meaningful content can include a version of the entire content of the frames in the frameset, or it can consist of instructions and links for users to find the content. Often the links point to the frame documents, outside their frames context. noframes content must not consist of instructions for users to switch to a frames-capable browser.

Example:

In this example, the user will receive a link to table_of_contents.html, which would allow him or her to navigate through the site without using frames.

12.4 Frame sources

Checklist item:

Only HTML documents are used as frame sources.

Content developers must provide text equivalents of frames so that their contents and the relationships between frames make sense. Note that as the contents of a frame change, so must change any description. This is not possible if an image or other object is inserted directly into a frame. Thus, content developers should always make the source (src) of a frame an HTML file. Images may be inserted into the HTML file and their text alternatives will evolve correctly.

Editorial Note: This is worded as if there are no exceptions. Isn't it possible to design an accessible frameset that uses non-html resources as the frame source?

This incorrect example links directly to an image. Note that if, for example, a link causes a new image to be inserted into the frame: the initial title of the frame ("Apples") will no longer match the current content of the frame ("Oranges").

13.3 Grouping options of select elements

Checklist item:

optgroup is used to group options logically under the select element.

Content developers should group information where natural and appropriate. For long lists of menu selections (which may be difficult to track), content developers should group select items (defined by option) into a hierarchy using the optgroup element. Specifies a label for the group of options with the label attribute on optgroup.

Example:

This example uses the optgroup element to logically group several options (using the option element) into categories labeled "PortMaster 3", "PortMaster 2", and "IRX".

13.5 Place-holding characters in empty controls (@@ super-deprecated)

Checklist item:

Default, place-holding characters are included in edit boxes and text areas.

Editorial Note: This is a negative technique, an example of something you shouldn't do. This technique corresponds to a WCAG 1.0 checkpoint. There is a proposal for an erratum that states the until user agents clause is met and this checkpoint (and thus technique) are no longer necessary.

Example:

This example fills a textarea element with code so that legacy assistive technologies will recognize it.

13.6 Text equivalents for submit buttons

Checklist item:

For image submit buttons, use the alt attribute of the input element to provide a functional label. This label should indicate the button's nature as a submit button, not attempt to describe the image. The label is especially important if there are multiple submit buttons on the page that each lead to different results.

The input element is used to create many kinds of form controls. Although the HTML DTD permits the alt attribute on all of these, it should be used only on image submit buttons. User agent support for this attribute on other types of form controls is not well defined, and other mechanisms should be used to label these controls.

Example:

This example uses the alt attribute of an image submit button to label it as a "submit" button.