HTML Techniques for WCAG 2.0

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.

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 hte page.

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.

If your page uses terms that are defined in a glossary document, use linkrel = "glossary" to reference the glossary of terms used on the page. This enables users to access the glossary quickly using user agent features.

metahttp-equiv of "{timeout}; url=... " is often used to automatically redirect users. The meta element should be used 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.

It is acceptable to use the meta element to create a redirect when the timeout is set to zero. However, it is preferrable to use server-side methods to accomplish this Refer to @@.

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

Content developers should use the link element and link types (refer to [HTML4] section 6.12) to describe document navigation mechanisms and organization. This allows user agents to implement standardized navigation tools for your site, or allow ordered printing of a set of documents.

The link element may 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.

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.

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.

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

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.

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 Terse substitutes for header labels.

Mark up acronyms with acronym and use title to indicate the expansion.

Do not use the blink element to create blinking content.

Do not use the marquee element to create scrolling text.

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.

The blockquote element marks up block quotations.

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.

In general, one can provide supplementary information about elements using the title attribute. The attribute value contains the content. Refer to @@appropriate part of AU 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:

• Abbreviations

• Acronym

• Supplement link text with the title attribute.

• Providing a frame title

There are also situations in which accessibility requirements are that title should not be used, even though it is permitted by HTML. Refer to:

• The title attribute on the table element

• Image titles

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.

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.

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

Avoid using the following HTML elements, and use the appropriate CSS instead.

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.

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.

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.

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.

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

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.

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:

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

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

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.

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.

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.

The pre element is not used to create tabular layout; the table elements is used. Watch out for pre markup within 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 consider using style sheets for layout and positioning. This technique deprecates the use of layout tables. Do not use the table element for layout purposes unless the desired effect absolutely cannot be achieved using CSS.

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.

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

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

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

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.

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.

Many kinds of links have both a text and iconic link adjacent to each other. Often the text and the icon link are rendered in separate links, in part to create a slight visual separation from each other. Visually they appear to be the same link, but they are experienced by many people as two identical links and can be confusing. To avoid this, some authors omit alternative text from the image, but then there is a link with an unclear destination. The preferred method to address this is to put the text and image together in one link, and provide null alternative text on the image to eliminate duplication of text.

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.

If there are five or more navigation links and/or other content that comes before the main content of the page then the skip navigation technique should probably be used. If there are twenty links and other elements before the main content, one of these techniques definitely should be used. The link should be at or very near the top of the page; it is a link with a local target just before the beginning of the main content.

Some designers would prefer not to have the skip link visible to all users. There are several techniques used to hide the skip link.

• Use an image that otherwise needs no text equivalent and place the link text as alt text on that image. When using the tab key the link text will be heard by a screen reader and without a screen reader the href can be observed in the status bar of IE. E.g., <a href="#main"><img src="spacer.gif" width="1" height="1" alt="Skip Navigation"></a>

• Use the same foreground and background colors on the link text (assume back text on white background in code example). When using the tab key the link text will be heard by a screen reader and without a screen reader the href can be observed in the status bar of IE. It may be useful to consider making the link visible when the mouse is moved over the link or the link receives focus with the tab key.

• Hide the skip link by positioning it off screen with CSS, e.g., a.skip {position: absolute; left: -1000em; width: 20em;}. When using the tab key the link text will be heard by a screen reader and without a screen reader the href can be observed in the status bar of IE.

Do not hide the skip link using the display property; either display:none or display:hidden. Screen readers will not speak text with display:none and sometimes will not speak text with display:hidden.

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.

The HTML specification indicates that when keyboard shortcut defined with accesskey is used, the element is focused and, for some elements, activated (see the accesskey definition). If the Web page will be viewed in browsers that conform to this specification, do not use accesskey because automatic activation may cause accessibility problems.

On many common browsers, the key combination to activate accesskey is the same as the combination to activate the browser's own interface mnemonics. For most such browsers, when a particular accesskey is defined in a Web page, the HTML takes precedence and the feature of the browser's user interface becomes unavailable or more difficult to access with the keyboard. Avoid using the accesskey until user agents resolve this problem.

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

When using the img element, specify a short text equivalent with the alt attribute. Note. The value of this attribute is referred to as "alt-text".

Alternative text is sometimes used to provide textual information that is not an appropriate text equivalent of the image. Most often this is used to affect search engine results. This alt text can present major barriers to users of text views of the document.

While the title attribute can be used on most elements, it should not be used on the img element. The semantics of title are too easily confused with alt and longdesc (see Short text equivalents for img elements ("alt-text") and Long descriptions of images) and user agent support is extremely inconsistent

When usingobject, specify a text equivalent in the body of the object element.

When a short text equivalent does not suffice to adequately convey the function or role of an image, provide additional information in a file designated by the longdesc attribute.

When using object, specify longer text equivalent within the element's content.

Note that object content, unlike "alt text", can include markup. Thus, content developers can provide a link to additional information from within the OBJECT element.

For user agents that don't support longdesc, provide a description link as well next to the graphic.

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.

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

Present text as HTML rather than in a bitmap images. There are several reasons for this:

• Text is directly available to assistive technologies without requiring text equivalents

• Text can contain HTML structure elements

• Color contrast can be adjusted by the user

• Size can be adjusted by the user

Do not use the background attribute to display a background image.

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.

Content developers should create client-side image maps (with usemap) rather than server-side image maps (with ismap) because server-side image maps require a specific input device.

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.

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.

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.

If area is used to create the map, use the alt attribute.

If object is used, provide a text equivalent in the content of the element:

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.

Provide alternative content for the embed element in the alt attribute.

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:

For more information refer to [MACROMEDIA].

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.

Provide a name for frames in addition to title. it is useful to have a name attribute that is at least meaningful to benefit technologies that do not support title, and a title attribute that takes advantage of the fact that you can have several words in it.

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.

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.

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.

Provide alternative content for iframe by providing meaningful and accessible content between the start and end tags.

For each form control, provide an explicit label in a label element. A label is attached to a specific form control through the use of the for attribute. The value of the for attribute must be the same as the value of the id attribute of the form control.

Reset and submit buttons (<input type="reset"/> or <input type="submit"/>), image buttons (<input type="img"/>), and script buttons (<button></button>) do not need explicit labels since they have labels implicitly associated via their value or alt attributes or via element content for button.

According to the HTML 4.01 specification, the label element can be wrapped around both the form control and its label text to create an "implicit label", as in

<label>First name: <input type="text" name="firstname" /></label>

. In practice this is not supported by user agents and should not be used. Use explicit labels as described in Explicit form labels.

Content developers should group information where natural and appropriate. When form controls can be grouped into logical units, use the fieldset element and label those units with the legend 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.

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.

See [#300]

See .

Provide redundant input mechanisms (i.e., specify two handlers for the same element, both of which have the same code associated with them):

Note that there is no keyboard equivalent to double-clicking (ondblclick) or mouse movement (onmousemove) in HTML 4.0. Avoid using these elements.

Avoid device-dependent, particularly mouse-dependent, event handlers. Use logical event handlers such as onfocus, onactivate, etc. Provide fallbacks to keyboard or logical event handlers for mouse event handlers.