Accessibility for Web Developers

Guideline 11: Use W3C technologies and guidelines

The World Wide Web Consortium (W3C) was established in 1994. Amongst other things, the W3C provide specifications that are freely available to everyone. The specifications are reviewed early to ensure that accessibility issues have been considered in the design process. They are developed in an open forum, with industry consensus. This process helps eliminate browser wars, as a lot of thought is given to provide a standard that ensures operability.

Despite this, some browsers still support elements that are not part of the specification. To ensure the widest possible audience, these non-standard elements should be avoided. Other non-W3C technologies require plug-ins or stand-alone applications to run, meaning they can't be viewed with standard user agents. Conforming to W3C standards will result in more accessible pages, available to a much wider audience regardless of hardware or software.

This guideline has 4 checkpoints, ranging in importance from Level "A" (must be addressed for the site to be accessible), to Level "AAA" (beneficial to ensure the accessibility of your site).

11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported

This checkpoint is a priority 2 checkpoint. It should be satisfied for your site to be considered accessible. When W3C technologies are designed, accessibility issues are taken into consideration. You should use the latest version of the specifications, and embrace features that could enhance the accessibility of your site. For example, the longdesc attribute for images isn't supported by all user agents, but is extremely useful for those that do. A browser that is not capable of handling the longdesc element will ignore it, so it doesn't impede the functionality of the document.

Documents should be validated using a validation service such as the W3C's HTML validation service, and their CSS validation service. See guideline 3.2 for details on how to create documents that validate to published formal grammars.

Some user agents implement features better than others, and it's advisable to be cautious should the browser have a dominant market place.

11.2 Avoid deprecated features of W3C technologies

This checkpoint is a priority 2 checkpoint. It should be satisfied for your site to be considered accessible. Deprecated elements or attributes are features that have become redundant due to newer technologies being more efficient at handling them. For example, the font element has been deprecated because it makes more sense to separate content from presentation, and the font can be handled more efficiently with CSS. Similarly, the color attribute has been deprecated in favour of CSS. Deprecated elements should be avoided, as they may become obsolete. Transitional DOCTYPEs allow the use of deprecated elements, but they are not allowed with the strict DOCTYPEs. Because of this, it's advisable to use the strict DOCTYPE, as using deprected elements may decrease the accessibility of your documents.

The object element is far more versatile at handling content from different sources than the deprecated applet element. The object element also has a built in mechanism for ensuring that the content degrades gracefully.

11.3 Provide information so that users may receive documents according to their preferences

This is a priority 3 checkpoint, which will be beneficial for the accessibility of your site. Most browsers allow you to configure them so that when you request a page from a server, you are sent the page in the language of your choice. If you set your language of choice to French, then providing multiple language documents that include French are available on the server, you will be delivered the French version. This is called Content negotiation, and can be extended to content type, and other features that can be determined over HTTP. This needs to be configured on the server. When a request for a page is made, the server sends the best match for the client.

Content negotiation provides an efficient means of delivering content without the need for redundant links. Instead of having a French, German, Spanish, Japanese, and English version, you just serve content dependent on the requirements set up by the client.

In the same way that visual styles such as color, and background-color allow you to define how visual elements will be presented, aural cascading style sheets allow you to define how a voice browser presents aural information.

CSS2 media types allow developers to design style sheets that render more appropriately on certain target devices, such as screen, print, Braille devices, speech synthesisers, TTY devices, etc. Specifying media rules can reduce download times by allowing user agents to ignore rules that don't apply to them. There are two ways to specify media for the style sheets. The first method is to specify the media through the media or import rules from within the style sheet, and the second method is using the media attribute of the link element.

The following example specifies the media attribute for the link element.

A List Apart published a good article by Eric Meyer, on using the media attribute to provide a style sheet for printing.

11.4 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

This checkpoint is a priority 1 checkpoint. It must be satisfied for your site to be considered accessible. If after your best efforts, you are unable to make a page accessible, you should provide a link to an equivalent accessible alternative that is updated as often as the inaccessible version. This should only be done as a last resort, as despite best intentions, alternative pages are generally updated less frequently than primary pages. Automatically generating alternative pages is a good option for pages that are updated regularly, but developers should ensure that the content maintains its context, and is usable and accessible. The best option is to ensure that the original page is accessible.