Guideline 11
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.
h1
{
voice-family: announcer, male;
stress: slow;
richness: 70;
}
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.
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-gb">
<head>
<title>Your Title</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<link href="main.css" rel="stylesheet" media="all" type="text/css" />
<link href="braille.css" rel="stylesheet" media="braille" type="text/css" />
</head>
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.