Web Accessibility

Web Content Examples

Most of the examples in this section are the same as the ones you will find on the W3C web site.

Each page provides details or examples of one or more techniques that are associated with a particular checkpoint. Where possible, the examples are actually coded so that you will see how that particular technique displays or renders on your browser or user agent. In most cases, the markup that creates the ¨live¨ example is also provided although you can also ¨View Source¨ to get the exact coding).

In this set, the examples of techniques are drawn from various sources: some from the authors' experience, some from other W3C sources, and some from the document ¨Techniques for Web Content Accessibility Guidelines 1.0¨. Please note that the ¨Techniques¨ document is the definitive source

For an alternative view of the Web Content Accessibility checkpoints that arranges them according to priority and function, see the appendix that accompanies the Guidelines: List of Checkpoints for Web Content Accessibility Guidelines 1.0

Checkpoint:11.1 - Priority 2

W3C Technologies

Use W3C technologies and use the latest versions when they are supported by browsers.

Why W3C technologies?

First and foremost, because all emerging W3C technologies will undergo a thorough review for accessibility issues. This is a commitment that immediately places W3C technologies at the forefront of many other emerging technologies.

At the time of this writing, several of the latest HTML 4.0 attributes that may significantly increase accessibility of Web pages have not been implemented in user agents. Therefore, authors may be asking:

Why should I use these attributes or elements if they aren't supported?

The authors believe that many of the new attributes and elements will be supported in the very near future, as companies release new versions of their products. Pages written to be accessible now will be ready when the technology catches up. This is the reverse of the ¨old¨ system where people with disabilities always had to play ¨catch up¨ to the new technology.

Another question authors may be asking:

Will using these attributes or elements break my pages as they are displayed today?

User agents are supposed to ignore HTML attributes they don't support.

For example, the HTML 4.0 <A> element has an attribute, ¨charset¨ that lets you specify the ISO character set of the linked document, but no browser currently supports it. Therefore, it is simply ignored. This means that you don't have to worry about what will happen if you include an attribute that is not yet supported. The WAI hopes that user agent manufacturers will soon implement all the HTML 4.0 attributes.

User agents are also supposed to render the content (the markup between the start and end tags) of unsupported elements.

In this case, lets pretend that HTML has an element called <SHAKE> that makes an image appear to vibrate quickly. We know this is not supported by any browser. So, browsers are expected to display the content or markup the author puts between the start and end tag of the element. For example:

Since <SHAKE> is not supported, then the content is displayed:

Why do we encourage you to use the new features included in W3C Recommendations (like the HTML 4.0 elements and attributes ABBR, OPTGROUP and longdesc) even if they aren't presently supported by common browsers or aren't backwards compatible with older browsers?

The previous example shows that the author can ensure that users of older technology will get the ¨meat¨ by including equivalent markup in the content of the element. It will also ensure that users of the ¨latest and greatest¨ will benefit from the use of the new element as soon as it is supported.

Please note: SHAKE is not an element of any W3C language specification and therefore this page will not validate. This example is not meant to encourage you to create your own markup.

Other questions that authors may be asking are:

Which browsers support these features and which don't?

There are also other issues with backward compatibility. We require that pages transform gracefully across browsers, but how can one author test all possible browser and user scenarios?

Please see User Agent Support for Accessibility. This page documents user agent support for accessibility features discussed in WCAG 1.0.

Checkpoint:11.4 - Priority 1

If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.

Because of the difficulty in keeping alternative pages up to date with the full content of the original page, alternative pages should be provided only after you have tried all of the other pertinent techniques outlined in the Web Content Accessibility Guidelines to make your original page accessible (unless the alternative page is automatically generated from the same source as the original page).

Here is one way you might give visitors the choice:

When the user chooses a link, the appropriate page will be served.

Please remember that this checkpoint should only be used as a LAST RESORT. As more browsers support the latest versions of HTML, XML, CSS1 and 2 and other accessible W3C languages, pages that cannot be made accessible by following the other guidelines will become rarer.

Checkpoint:13.9 - Priority 3

Document Collections

Provide information about document collections (i.e., documents comprising multiple pages).

• The example for Metadata shows one way of providing information about a sequential document - it shows how this curriculum uses the ¨LINK rel=next¨ and ¨LINK rel=prev¨ markup to indicate the URL of the next and previous pages for extra navigation information.
• The W3C curriculum also includes a page counter indicating which page you are on in relation to the whole set.
• A table of contents or site map also provides useful information about a collection of related documents.
• Use archiving tools such as zip, tar and gzip, and stuffit to create an easily downloadable package of related files or pages.