HTML Techniques for WCAG 2.0

Editorial Note: Would like to say something other than "describe." Perhaps "label?"

All documents, including individual frames in a frameset, should have a TITLE element that defines in a simple phrase the purpose of the document.

Note that the (mandatory) TITLE element, which only appears once in a document, is different from the "title" attribute, which applies to almost every HTML 4.01 element. Content developers should use the "title" attribute in accordance with the HTML 4.01 specification. For example, "title" should be used with links to provide information about the target of the link.

Editorial Note: Propose that we delete this example (title on link) since use of title on link depends on context and can be redundant with link text.

@@

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.

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. Refer to the Technologies Reviewed for Accessibility.

Editorial Note: This used to say, "validate to W3C grammars."

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.

The LINK element may also be used to designate alternative documents. Browsers should load the alternative page automatically based on the user's browser type and preferences.

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.

Editorial Note: Edit this section to clarify "semantic chunks," "other markup," "introducing sections," "navigating its headings," etc.

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:

• Users who are reading the document in braille will be able to substitute the appropriate control codes (markup) where language changes occur to ensure that the braille translation software will generate the correct characters (accented characters, for instance). These control codes also prevent braille contractions from being generated, which could further confuse the user. Braille contractions combine commonly used groups of characters that usually appear in multiple cells into a single cell. For example, "ing" which usually takes up three cells (one for each character) can be contracted into a single cell.

  Editorial Note: Do we need this level of detail? Do developers find it confusing or helpful? In the next item, how about "say" instead of "generate?"

• Similarly, speech synthesizers that "speak" multiple languages will be able to generate 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.

• Users who are unable to translate between languages themselves, will be able to have unfamiliar languages translated by machine translators.

  Editorial Note:  This is really forward thinking. Does including this here help build the case for marking up changes in 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.

Editorial Note: Need more. Why is it good practice? What are the benefits?

The proper HTML elements should be used to mark up emphasis: em and strong. The b and i elements should not be used; they are used to create a visual presentation effect. 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.)

Editorial Note: Propose this be rewritten to be less dogmatic. i.e., move the bit about em and strong to the front and ease up use of "proper."

Mark up abbreviations and acronyms with abbr and acronym 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.

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

The Q and BLOCKQUOTE elements mark up inline and block quotations, respectively.

NOTE:The Q element, though designed for semantic markup, is unsupported, or poorly-supported, in most browsers. While the Q element is preferable to the " entity, which adds no structure to the document, it is recognized that support for Q is insufficient.

Editorial Note: Thus, we are not recommending the use of Q at this time? If so, say that explicitly.

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

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:

• Ensure that users know what variables represent, for example, in the equation "F = m * a", indicate that F= Force, m = mass, a = acceleration.

• For straightforward equations, use characters, as in "x + y = z"

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

  Editorial Note: Eventually, "MathML Techniques for WCAG 2.0" will exist and give more guidance.

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

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

2. 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).

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?

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?

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: Need to break each of these into a separate technique with a separate checklist item. Also good to break up the long examples to focus on particular pieces of markup. Perhaps include complete table examples in the appendix.

• Provide a caption via the CAPTION element. A table caption describes the nature of the table in one to three sentences. Two examples:

  1. "Cups of coffee consumed by each senator."

  2. "Who spends the most on pollution cleanup?"

  A caption may not always be necessary.

• If a CAPTION is not provided, use the "title" attribute on the TABLE element to describe the nature of the table in a few words.

• Provide a summary via the "summary" attribute. Summaries are especially useful for non-visual readers. A summary of the relationships among cells is especially important for tables with nested headings, cells that span multiple columns or rows, or other relationships that may not be obvious from analyzing the structure of the table but that may be apparent in a visual rendering of the table. A summary may also describe how the table fits into the context of the current document. If no caption is provided, it is even more critical to provide a summary. Two examples:

  1. "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."

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

• Provide terse substitutes for header labels with the "abbr" attribute on TH. These will be particularly useful for future speaking technologies that can read row and column labels for each cell. Abbreviations cut down on repetition and reading time.

• Identify structural groups of rows (THEAD for repeated table headers, TFOOT for repeated table footers, and TBODY for other groups of rows) and groups of columns (COLGROUP and COL).

• Label table elements with the "scope", "headers", and "axis" attributes so that future browsers and assistive technologies will be able to select data from a table by filtering on categories.

• Do not use PRE to create a tabular layout of text -- use the TABLE element so that assistive technologies may recognize that it is a table.

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

Authors should use 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.

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 of Wisconsin 
rain showers this morning, but they     will resume on September 3rd. 
should stop before the weekend.

This might be read by a screen reader as:

There is a 30% chance of Classes at the University of Wisconsin rain showers this morning, but they will resume on September 3rd. should stop before 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).

@@also the case for layout tables?

@@example

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

Good link text should not be overly general; don't use "click here." Not only is this phrase device-dependent (it implies a pointing device) it says nothing about what is to be found if the link if followed. Instead of "click here", link text should indicate the nature of the link target, as in "more information about sea lions" or "text-only version of this page". Note that for the latter case (and other format- or language-specific documents), content developers are encouraged to use content negotiation instead, so that users who prefer text versions will have them served automatically.

Editorial Note: Warning about designing content negotiation? e.g., serving text-only versions if people have a particular browser?

In addition to clear link text, content developers may specify a value of the "title" attribute that clearly and accurately describes the target of the link.

If more than one link on a page shares the same link text, all those links should point to the same resource. Such consistency will help page design as well as accessibility.

If two or more links refer to different targets but share the same link text, distinguish the links by specifying a different value for the "title" attribute of each A element.

"Auditory users" -- people who are blind, have difficulty seeing, or who are using devices with small or no displays -- are unable to scan the page quickly with their eyes. To get an overview of a page or to quickly find a link, these users will often tab from one link to the next or review a list of available links on a page.

Editorial Note: Difficult to read. Update with "link list" mechanism.

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

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.

Editorial Note: I modified this note slightly to make it easier to read and got rid of the bit about "In the future, user agents may allow users to skip over elements such as navigation bars."

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.