Accessibility Coding Guidelines

Release 3.0 (9/17/2003)

Table of Contents

Accessibility

  General Document Structure

    Structural Markup

    Lists

    Acronyms and Abbreviations

    Languages (Internationalization)

    Use "title"

  Avoid JavaScript

    Application Level Triggers

    Redundant Device Level Triggers

  Links and Maps

  Images and Objects

  Flash

  Forms

    Field Grouping

    Field Navigation

    Field Values

  Tables

    Layout Tables

    Data Tables

      Captions

      Column Headings

Revision History

Accessibility

All generated HTML must pass Section 508 accessibility guidelines. This section contains specific guidelines for writing and generating accessible HTML. These are based in turn on the W3C Web Content Accessibility guidelines and techniques (see the WTG Resources page for links to these and other related documents).

As a general principle, accessibility means creating web pages that can be rendered and used effectively by assistive technologies, e.g., browsers created for people with disabilities. In particular, that means providing textual alternatives for all visual elements and effects, structuring pages to render in linearized form (i.e., without the clues provided by visual layout), enhancing navigation for mouse-less operation (in forms as well as generally on pages) and adding meta-data to clarify page structure and content.

As we move to a more dynamic web site, this means that our ColdFusion code needs to generate enhanced HTML which in turn means that our content object model needs to cater for the necessary textual alternatives and meta-data.

General Document Structure

This first section discusses some general principles of page structure which make pages more accessible.

Use headings to provide structure. Use styles for (purely) visual effects. In other words, if text has several sections, each with some sort of header, then use h1, h2... tags as appropriate to delineate that structure and use style sheets to control their appearance - don't just use visual styles on p tags for structurally important text. Similarly, don't use h1, h2... tags to apply visual style to text that is not structurally significant.

Use logical style tags rather than physical style tags. In other words, use <em> and <strong> for emphasis and inflection rather than <i> and <b>. Browsers that render HTML as speech work better with logical styles. Similarly, use structural markup tags appropriately (for code examples, user input, sample output and variables / parameters) - see below.

Structural Markup

In addition to <em> and <strong>, HTML provides eight logical style tags that convey structural meaning - use them appropriately:

• Use <cite> for citations and references.
• Use <dfn> to indicate that this is the defining instance of a particular term.
• Use <code>, <samp>, <kbd> and <var> for code fragments, sample output, user input (keyboard) and variables (function parameters etc).
• Use <ins> and <del> as annotations for corrections to indicate insertions and deletions in text.

Avoid using the physical style tags: <i>, <b>, <tt>, <u> and <s>.

Lists

Use list markup tags to show structure rather than purely visual styles. Use <ul> / <li> for bulleted lists. Use <ol> / <li> for ordered (numbered) lists. Use <dl> / <dt> / <dd> for definition lists. Style sheets let you specify the exact visual appearance of such lists, including the use of graphics for bullets.

Acronyms and Abbreviations

Annotate acronyms with explanatory tags, e.g.,

<acronym title="World Web Web">WWW</acronym>

Move your mouse over this annotated acronym to see the title text: WWW.

The <abbr> tag works in much the same way to explain abbreviations, e.g.,

<abbr title="Wednesday">Wed<abbr>

Unfortunately, this tag does not show the title text (in Internet Explorer or Netscape Navigator).

In tables, long column headings should be given an abbreviation with the attribute abbr, e.g.,

<th abbr="price">Recommended Retail Price</th>

This allows speech programs to use the abbreviation instead of the full column header when reading cell contents.

If any of this data is generated by ColdFusion from a content object, the content object should also provide the annotation.

Languages (Internationalization)

The language of all text should be specified explicitly, using the appropriate ISO two letter code, e.g., "sv" (optionally followed by the ISO two letter country code, e.g., "sv_SE"). The primary language for a page should be specified in the HTTP headers (and on the html tag), e.g.,

Content-Language: fr

Also:

<html lang="fr">

See Globalization for more information on Content-Language since the same will apply to specifying lang on the html tag.

If there is text (or graphics) on a page that is in a different language it should be annotated as follows:

As the French say, <span lang="fr">Vive la difference!</span>

This is only likely to be true on our site for the navigation that allows a user to select an alternative international site, e.g.,

<a href="..." border="0"><span lang="sv-SE"><img src="loc_se.gif" alt="Svenska"></span></a>

Which looks like this:

Note: Be careful to use the correct language code values, e.g., Japanese is "ja" but Japan is "JP", Swedish is "sv" but Sweden is "SE".

Use "title"

Many tags now allow the attribute title to provide an annotation or additional information to assistive technologies. Some specific examples where this is beneficial are:

• Links, e.g., <a href="..." title="Description of the target page">Target link</a>
• Objects - see Images and Flash below.
• Tables - see Tables below.

Avoid JavaScript

As a general rule, avoid making user interaction dependent on JavaScript. Purely visual effects, such as rollovers, are acceptable but any important user hints or navigational information should be accessible outside the JavaScript too.

Application Level Triggers

Instead of device-level triggers, use application-level triggers where possible: onfocus, onblur and onselect. This will provide greater accessibility.

Redundant Device Level Triggers

Where device-level triggers are needed, provide redundant triggers so that mouse-less operation is possible. For onmousedown, also provide onkeydown. For onmouseup, provide onkeyup. For onclick, provide onkeypress.

Links and Maps

As noted above, links should provide a title attribute describing the target page contents. It is also helpful to indicate that a series of links are related by grouping them in a map tag, e.g.,

<map title="Navigate this tutorial">
    [
    <a href="..." title="Go back to the beginning">start</a> |
    <a href="..." title="Go to previous page">prev</a> |
    <a href="..." title="Go to next page">next</a> |
    <a href="..." title="Go to the last page">end</a>

    ]
</map>

If there is a standard set of links on every page, as page of the global navigation, there should be an additional link to allow users to skip over the standard navigation:

<a href="#SkipNavigation" title="Skip navigation">skip</a>
... standard navigation links ...

<a name="SkipNavigation></a>

This format can also be used for client-side image maps, using a tags with shape and coords attributes rather than the more usual area tags. Combining this with using an object tag instead of an img tag - see Images and Objects below - will provide a complete textual navigation alternative to the image:

<object data="map.gif" type="image/gif" usemap="nav">
    <a href="#SkipNavigation" title="Skip over the navigation">skip</a>

    <map name="nav" title="Navigate this tutorial">
        [
        <a href="..." shape="rect" coords="0,0,30,30"

            title="Go back to the beginning">start</a> |
        <a href="..." shape="rect" coords="30,0,60,30"
            title="Go to previous page">prev</a> |
        <a href="..." shape="rect" coords="60,0,90,30"

            title="Go to next page">next</a> |
        <a href="..." shape="rect" coords="90,0,120,30"
            title="Go to the last page">end</a>

        ]
    </map>
    <a name="SkipNavigation"></a>
</object>

If links are generated by ColdFusion, the content model may need to cater for the title text.

Images and Objects

Every single image should have an alt attribute containing a brief description of the graphic. The alt attribute value for spacer graphics should be a single space, enclosed in quotes. It is also possible to provide a long description for a graphic using the longdesc attribute, whose value is a URL that renders the long description.

An alternative approach is to use object tags instead of img tags. This allows for a complete textual alternative to the image. Since object tags can be nested, with the contents invoked only if the specified object cannot be rendered in the browser, this also allows alternative media to be presented.

<object classid="..." ...>
    <param name="movie" value="dwlogo.swf">
    <object data="dwlogo.gif" type="image/gif">

        An animation of the Dreamweaver logo
        changing into a cinema ticket that says
        "Admit One".
    </object>
</object>

Wherever an image, or other rich media element, is selected by ColdFusion code, that code must also provide suitable alternative text. This means that for every media element in a content object, there must be a matching element for the alternative text.

Flash

Wherever Flash is used on the site, an object tag should be used to specify the movie for Internet Explorer and within that tag, the Netscape Navigator alternative embed tag should be used (or another object tag containing an animated GIF, as in the example above). If the embed tag is used, a textual alternative must be provided, enclosed in noembed tags. If the nested object tag is used (to show an animated GIF instead of Flash) then that tag should enclose a textual alternative (as shown above).

The HTML syntax for Flash object/embed tags is shown on this Macromedia support page.

As with images above, if the Flash movie is part of HTML generated by ColdFusion, that ColdFusion code is responsible for generating the noembed textual alternative. This in turn may impact the content object model.

See also the Flash Coding Guidelines which contain additional accessibility information.

Forms

The two greatest accessibility issues for forms are:

1. intuitive field navigation and grouping,
2. mouse-less operation.

In order to address these issues, forms should have fields arranged in logical groupings, with an intuitive tab order, i.e., pressing the tab key should give each field focus in most intuitive order. It should be possible to complete a form using only the keyboard, using the tab key to select fields, the up / down arrow keys to select items from drop-downs, and finally pressing enter to submit the form.

Field Grouping

Arrange related fields together and enclose them in a fieldset tag. Use the legend tag to describe each grouping, e.g.,

<fieldset>
    <legend>Full name and nickname</legend>

    <p>courtesy title <select>...</select></p>
    <p>first name <input ...></p>
    <p><acronym title="Middle Initial">MI</acronym> <input ...></p>

    <p>last name <input ...></p>
</fieldset>
<fieldset>
    <legend>Primary address information</legend>
    <p>address <input ...></p>

    <p>city <input ...></p>
    <p>state <select>...</select></p>
    <p>country <input ...></p>

</fieldset>

Options in a select tag can also be grouped and annotated to improve accessibility, e.g.,

<select name="state">
    <optgroup label="U.S. States">
        <option value="AL">Alabama</option>

        <option value="AK">Alaska</option>
        <option value="AZ">Arizona</option>
        ...
    </optgroup>
    <optgroup label="Canadian Provinces">

        <option value="AB">Alberta</option>
        <option value="BC">British Columbia</option>
        <option value="MB">Manitoba</option>

        ...
    </optgroup>
</select>

If an option list is generated by ColdFusion, the content object model may need to consider option grouping.

Field Navigation

Explicitly specify the tabindex attribute for every field and the submit button. The above example would become:

<fieldset>
    <legend>Full name and nickname</legend>
    <p>courtesy title <select tabindex="1" ...>...</select></p>

    <p>first name <input tabindex="2" ...></p>
    <p><acronym title="Middle Initial">MI</acronym>
        <input tabindex="3" ...></p>

    <p>last name <input tabindex="4" ...></p>
</fieldset>
<fieldset>
    <legend>Primary address information</legend>

    <p>address <input tabindex="5" ...></p>
    <p>city <input tabindex="6" ...></p>

    <p>state <select tabindex="7" ...>...</select></p>
    <p>country <input tabindex="8" ...></p>

</fieldset>

It is also good practice to associate the text labels with their associated fields, using the label tag, e.g.,

<p><label for="firstName">first name
    <input tabindex="2" name="firstName" ...></label></p>

The label tag allows you to specify keyboard shortcuts to jump directly to fields with the accesskey attribute, e.g.,

<p><label for="address" accesskey="A">address
    <input tabindex="5" name="address" ...></label></p>

In a dynamically generated form, the tabindex values and label tags should be automatically generated. This may affect the meta-data model if the most intuitive field order is not that in which fields are typically generated. This may be especially true when generating fields in a multi-column form layout (e.g., Macromedia > Membership > General Info - Your Profile). Additionally, any generated accesskey values will likely affect the meta-data model.

Field Values

When a user is updating information, initial field values will be whatever is currently held in the database, possibly empty. When a user is entering data for the first time, we normally provide no initial text and display empty fields. To help assistive technologies, it is better to fill empty fields with brief instructions on how to complete the field. This is especially true of textarea fields. The form processing code can always strip such instructions out of field values, to store empty fields again.

These brief instructions - hints - should form part of the meta-data model for the underlying form data. ColdFusion components provide displayName and hint attributes that may help here.

Tables

Tables are used for two primary purposes in web pages:

1. to display data in a structured manner,
2. to provide visual layout.

The former helps a user make sense of the data being presented and can be enhanced with annotations that can be used by assistive technologies.

The latter creates a pleasant look and feel but can actually hamper assistive technologies.

Each of these uses of tables will be discussed in more detail below.

Layout Tables

Where a table is used solely to provide visual layout, it needs no accessibility annotations (in fact, it must not contain any). When such a table is rendered by assistive technology, it will most likely be linearized, i.e., rendered as a list of paragraphs. The order of those paragraphs is usually determined by simply stripping the HTML markup tags. Bear this in mind when laying out information: it may make sense when rendered in a normal browser with tables but may not make sense when it is linearized!

That means the default linearized rendering will be by row, so the following table:

will render as:

Feature A description

Product Info

Feature B description

Reviews and Awards

Feature C description

Showcase

To avoid this, use nested tables for each column:

Data Tables

Where a table is used to enhance meaning by providing structure, e.g., the catalog page of our store, then assistive technologies benefit from a number of annotations in the code.

Captions

Provide a caption for each table, either through the title attribute on the table tag or through the caption tag within the table. A caption is usually a sentence or two. If more information is needed to explain the table, add a summary attribute to the table tag with several paragraphs of explanatory text.

<table title="Our products and prices"
    summary="This table lists all of our products
            with prices for new purchase, upgrade
            and, where applicable, ten user licenses.">
    ...
</table>

Column Headings

Label each column, using the id attribute on the th tag, and associate each cell with its heading, using the headers attribute on the td tag, so that assistive technologies can render the data structure more easily. As mentioned elsewhere, provide suitable abbreviations for column headings, using the abbr attribute on the th tag. Explain column headings, if necessary, with the title tag.

<tr>
    <th title="Product name"
        abbr="product" id="product"></th>
    <th title="Price of new purchase"

        abbr="new" id="full>Full</th>
    <th title="Price of upgrade"
        abbr="upgrade" id="upgrade">Upgrade</th>

    <th title="Price of ten user license, if applicable"
        abbr="ten user" id="ten">10-Pack</th>
</tr>
<tr>

    <td headers="product">Dreamweaver 4</td>
    <td headers="full">US $299</td>
    <td headers="upgrade">US $169</td>

    <td headers="ten">US $2,399</td>
</tr>

This might render in speech, with the caption example above, as:

Table title: Our products and prices.
Summary: This table lists all of our products with prices for new purchase, upgrade and, where applicable, ten user licenses.
Heading title: Product name. Abbreviated to product.
Heading title: Price of new purchase. Abbreviated to new.
Heading title: Price of upgrade. Abbreviated to upgrade.
Heading title: Price of ten user license, if applicable. Abbreviated to ten user.
product: Dreamweaver 4; new: US $299; upgrade: US $169; ten user: US $2,399.

There are other tags and attributes that can be added to complex data tables in order to make them more accessible using assistive technologies. These include the thead, tbody and tfoot tags to group rows, the colgroup and col tags to group columns and the scope and axis attributes (of the th tag). Consult the W3C documents for more information.

In order to generate the annotations described in this section, the meta-data model for a content object may need to cater for the captions, summaries, titles and so on.

Source: http://livedocs.macromedia.com/wtg/public/coding_standards/accessibility.html