Best practices to help you create accessible and semantically-rich Web pages
This document is meant to accompany an article written on the subject of accessibility and semantics. The following sections are real world examples of the subject matter discussed in the article and are meant to help illustrate the various techniques outlined therein.
The article discusses various best practices when designing accessible, semantically-rich Web pages and touches upon some of the ways to help you reach your accessibility goals. The article, and this document, are not meant to be a catch-all study in semantics or accessibility. On the contrary, the article is merely an overview to help designers having trouble with the key concepts and provides some industry tested solutions to the accessibility problems we encounter in our daily work.
Please feel free to download a copy of this file for study if you wish. You may also download a PDF version of the article for offline reading. Enjoy!
The following example outlines how to properly structure a document with appropriate heading tags:
<h1>Site/Company Name</h1> <h2>Document/Main Section Name</h2> ...Introductory text and/or content here <h3>Sub-Section Name</h3> ...Sub-section content here <h2>Global Document Sub-Sections (News, Search, Navigation, etc.)</h2> ...Document sub-section content here
What this quickly conveys to the user is:
Using an empty block level element as a CSS style “hook” is
akin to using invisible spacer GIF images
to achieve layout effects. For example, some designers like to use something
like the following to provide a heading to a list of links (*please review
the source code and find the <-- list example
with empty list item --> comment on line 246):
This places an empty, semantically-meaningless tag in the document (the empty
list item) which the designer can assign a class to and apply a background
image to the empty list item. A much more semantic and accessible approach
(since screen readers will still read the empty list item) would be to utilize
the empty list item and add a heading tag like so (*please review the source
code and find the <-- list example with heading
--> comment on line 266):
Ahhh...Much better! We were able to include our style hook and added more semantic meaning to the list with the inclusion of the heading. It is also inherently more accessible since we have removed the empty element that a screen reader would still read aloud to the user.
Most of the deprecated elements and attributes in HTML were
removed from the specification due to their presentational implications. Tags
such as <b>, <i> and attributes such as border="x" are
purely presentational items. They convey no sense of structure to the user
or the user agent (browser, screen reader, etc.). HTML is a structural language
so these items were removed based on the idea that CSS would
provide the same functionality to the document without affecting the markup.
An excellent example of the misuse of HTML for this purpose is removing borders from around linked images. By default HTML applies a border to images that are contained within anchors or links:
<a href="#" title="Some Company, Inc."><img alt="Some Company" src="img/sample_logo.png" width="200" height="42" /></a>
Now with the border="0" attribute added to the image:
<a href="#" title="Some Company, Inc."><img alt="Some Company" border="0" src="img/sample_logo.png" width="200" height="42" /></a>
This achieves the desired effect by removing the border from around the image, but it will not pass WAI Priority 1. With a little CSS we can remove those default borders without affecting the markup:
<a href="#" title="Some Company, Inc."><img alt="Some Company" src="img/sample_logo.png" width="200" height="42" /></a>
This not only applies to linked images, but to tables, form fieldsets, and anything else that may have borders. Use CSS to apply or remove borders and leave the markup lean and clean.
*Note: For this example I have chosen to leave the borders on the linked images and applied a CSS style to the example with no border attribute. This was done purely for aesthetics, and causes this page to fail validation, but the example shows how easy it would be to override a base CSS style with additional style hooks.
Unobtrusive
JavaScript is a technique used to degrade the user experience gracefully
should the user agent not support scripting. The
idea is to build the basic functionality using HTML,
apply an ID or CSS class
attribute (or another attribute, such as rel="") to the element
you wish to affect, and use carefully developed techniques to apply JavaScript
to the intended element. The result is that without scripting capabilities
the user will still be able to use the desired functionality, only without
the fancy effects and extended functionality that JavaScript provides.
To go into the details of Unobtrusive JavaScript here would require more space
than intended for this example. A simple example would be to illustrate the
use of Unobtrusive JavaScript with regards to links that open a new window.
Typically designers would utilize the target="_blank" link attribute
or an onclick event handler attribute to handle this task. Since
the target attribute has been deprecated, and event handler attributes
are obtrusive in nature, it will make a nice example of Unobtrusive JavaScript
techniques.
*Note: The following example was taken from an excellent example of these techniques at SitePoint: http://www.sitepoint.com/examples/popups/
<a href="popup.html" rel="popup|400|200">This is a popup link </a> <a href="http://en.wikipedia.org/wiki/City_Road" rel="external">This is an external link </a>
Viola! Clean markup, minimal presentational CSS, and a really
nice set of JavaScript functions that can reused over and over again for all
the sites that we do. Many thanks to Simon
Willison for the addLoadEvent() function and to the fine folks
at SitePoint for providing an excellent
resource for Web developers and designers everywhere (plus, that catfish
popup ad is just so darned cool!)
Validating your HTML markup
to a specific DOCTYPE is
one of the most basic methods to ensure usability, cross-browser functionality,
and semantics. It can be difficult to ensure that you have not accidently introduced
deprecated elements into your markup without validating your code. Validation
is great way to make sure that you stay on top of your code and that your code
is going to perform as you intend it to.
Using the most appropriate DOCTYPE for the task is often a matter
of designer experience and corporate style. If you have a CMS in-place
that allows your company’s employees to create and edit content using
a WYSIWYG editor, and
that content includes deprecated elements such as the <font> tag,
that system would not validate at anything above XHTML 1.0
Transitional. The Strict or XHTML 1.1 DOCTYPEs are out of the
question without redeveloping the entire system.
In most cases you can, at the very least, use the XHTML Transitional DOCTYPE without
having to change too much internally with regards to the application. Some
times it is as simple as editing the the DOCTYPE, making a few
adjustments to the <html> tag or some of the <head> tags,
and removing a few deprecated attributes from the design/layout templates.
This is not an easy task for large systems, so it may take some careful planning
and research on your part to ensure that you can validate the existing content.
The following list outlines the currently available DOCTYPEs
and highlights some of the changes and/or “gotchas!” to keep in
mind when using a particular document type definition:
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<font> tags and other elements that have since been deprecated in newer versions of XHTML.<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<img /> instead of <img>)<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
It is entirely up to you to choose which specification to follow. The point here is that you should choose at least one specification and validate your code to that particular specification. The easiest way to validate your markup is to use the W3C’s Validator:
The W3C Markup Validation Service
Using the The W3C Markup Validation Service tools you can quickly and easily validate your code directly or by form upload. It also includes an advanced interface to help you locate line numbers as well as see an outline of the page you are validating.
*Note: This list was taken from the W3C QA - Recommended list of DTDs you can use in your Web document page. For the sake of brevity, this listing does not include the XHTML Mobile Profile DOCTYPEs.
Using the right tool for the task at hand in HTML is often a complete matter of style. Too often I have seen documents marked-up with various tags that are completely inappropriate for the task to which they are assigned. Using a <p> tag, with CSS to make it “big and bold”, to highlight a section of a document is akin to swatting flies with a hammer. Sure, it will work, but it is kind of messy and it is not the job a hammer was designed to perform. A cleaner, more semantic approach would be to look at the document structure and assign an appropriate heading tag (<h2> through <h2>, since an <h1> should
be reserved for the site or company name).
Another, all-too-common, example is the use of <p> tags to markup form labels. Not only is this an inappropriate use for a paragraph tag, it is also kind of silly since HTML provides us with the right tool for the job; the <label></label> tag.
For example, say we have a simple form like the following:
<form action="form.cgi" id="form1" method="post"> <p><strong>Search</strong></p> <p>Search this site: <input name="search" type="text" /> <input name="submit" type="submit" value="Submit Search" /></p> </form>
Which looks like this:
This is fine (and most certainly passes validation), but it adds no value for the user and is somewhat unsemantic since there are no associations between the form label and the text input field. A much more accessible and semantic approach would be to use form labels to associate the name of the field to the text input field:
<form action="form.cgi" id="form2" method="post">
<fieldset>
<legend>Search</legend>
<label for="search">Search this site:</label>
<input id="search" name="search" type="text" />
<input id="submit" name="submit" type="submit" value="Submit Search" />
</fieldset>
</form>
Which renders our form like so:
This is so much better than the first example since it now uses the <label> tag to associate the text label to the field that it references. The association is made through the use of an ID attribute on the text input (id="search") and the for="search" attibute on the actual form label tag. If you place focus on the label, either by tabbing through the form or by selecting it with your mouse, you will notice that it gives the text input focus. This is an added accessibility benefit, since it allows screen readers to intelligently announce what a particular input element is, by reading the label.
(—Taken from: Day 28: Labeling form elements - Dive Into Accessibility). Plus we have also added additional accessibility features by removing the <p><strong>Search</strong></p> tags and adding a <fieldset> and form <legend>.
As an aside, if you don’t like the default borders or the formatting for the <fieldset> or the <legend> you can use CSS to easily
control the appearance of these elements and style them as you wish. A really nice touch is to style all <label></label> tags with a cursor: pointer; CSS style attribute to immediately let the user know that the label is selectable.
The Web is an ever-evolving set of interoperable technologies that allow us, the designers and the developers, to create usable solutions for our clients and customers. The concepts of the Web are still somewhat in their nascent stages of development and are constantly being revised and repurposed. That is why it is important for us, as professionals, to stay on top of these changes that seem to happen almost every day.
The following list outlines some important links for staying on top of your game. While not an exhaustive list, it includes some of the more important online resources and a few personal journals from some of the most respected designers and developers in our industry.
*Note: The preceding list is ordered alphabetically and not in order of precedence. If it were in order of precedence I would have placed W3C at the top, since they “write the book” on what the Web is really about.
While this is in no way meant to be an end-all list, it is certainly a great starting point. Once you get in the habit of properly structuring your documents with headings, avoiding presentational “fluff” in your HTML, and avoiding the use of deprecated HTML elements you will find that accessibility and semantics are really not that difficult to implement and are certainly not as separated as most folks would believe.
Semantically-sound and accessible websites are no longer the realm of government agencies but are a large part of your career future if you wish to have a successful Web design or development career. Think outside of the “blocks” and you will do just fine.
© 2006 Outer Banks Design Works · All Rights Reserved