If you would like, you can download the source code, examples, and a PDF version of the article to follow along with. You can also simply follow along with the examples provided.
The following article outlines some of my own and industry-accepted best practices which help to quickly outline how to create accessible and semantically-rich Web pages.
The idea of semantics and accessibility are often thought of and implemented in different terms. This idea is flawed in that an accessible website should also be semantic in nature to help support its accessibility. Examples of “text book” websites which are accessible but poorly structured are everywhere. This has led me to aggregate some of my own methods for accessibility and semantics as well as highlight some of the methods respected within the Web design community.
The following list of best practices is broken down into a set of “rules” (for lack of a better term) that help me to achieve full WCAG compliance when necessary. These rules can also be loosely applied as needed to achieve differing levels of accessibility and semantics, but following them to the letter will help you become a better designer and you will be helping countless others who cannot “point and click.”
Most Web designers today can use the different heading tags (<h1> through <h6>,
respectively) effectively without much trouble and tend to use them according
to the proper task. There are a great number of designers out there who tend
to misuse or abuse these easily implemented and highly-flexible indicators
of hierarchy.
While there are some folks with their own ideas of how to properly implement a heading hierarchy, there are also W3C Recommendations to help give us starting points for our own implementations. In my own experience, the following outline helps to quickly and easily achieve a usable document hierarchy:
What this quickly conveys to the user is:
If we think of our websites in terms of “outlines” we can achieve a greater sense of document structure without really doing too much to change the way we code. By applying an outline methodology to working out document sections we can visually separate the document into headings. XHTML 2 promises to give us generic heading tags, with a level determined by their depth within the document structure, but it could be several years before XHTML 2 is stable. In the mean time, we should use the various heading tags as they were meant to be used.
There seems to be a trend amongst some designers new to CSS-based design to use empty block level elements (<a>, <li>, <div>, etc.) strictly for a presentational CSS style “hook.” This a quick-and-dirty way to achieve certain tricks using CSS, but it leads to accessibility concerns as well as issues with the semantics of the document. For example, say we have a navigational list of links that highlight certain key concepts we would like to draw attention to on our site. The quick-and-dirty approach might use HTML like this:
<ul id="some_id"> <li class="list_start"><!--empty block level element --></li> <li><a class="item_1" href="somepage.html">Some link to content</a></li> <li><a class="item_2" href="somepage2.html">Some link to more content</a></li> <li><a class="item_3" href="somepage3.html">Some link to even more content</a></li> </ul>
And the CSS to control the appearance of the above list might look like this:
ul#some_id {
height: 300px;
list-style-type: none;
margin: 0;
padding: 0;
width: 200px;
}
ul#some_id li {
height: 75px;
margin: 0;
padding: 0;
width: 200px;
}
ul#some_id li.list_start {
background: #cc0000 url(images/list_start_bg.png) no-repeat 0 0;
}
ul#some_id li a {
display: block;
height: 75px;
margin: 0;
padding: 0;
width: 200px;
}
/*additional style rules for the links (item_1, etc.)*/
While this does the trick for a person who is not visually-impaired, it leads to some repetitive and non-essential information to be repeated throughout the website for those using assistive technologies like screen readers. A more semantic and accessible approach would be to utilize the empty block level and wrap it around a heading tag or other block level element like so:
<ul id="some_id"> <li class="list_start"><h2>Some Cool Stuff to See</h2></li> <li><a class="item_1" href="somepage.html">Some link to content</a></li> <li><a class="item_2" href="somepage2.html">Some link to more content</a></li> <li><a class="item_3" href="somepage3.html">Some link to even more content</a></li> </ul>
And the CSS to markup this list would look like so:
ul#some_id {
height: 300px;
list-style-type: none;
margin: 0;
padding: 0;
width: 200px;
}
ul#some_id li {
height: 75px;
margin: 0;
padding: 0;
width: 200px;
}
ul#some_id li.list_start {
background: #cc0000 url(images/list_start_bg.png) no-repeat 0 0;
}
ul#some_id li.list_start h2 {
font-size: 0;/*set the font size to zero*/
height: 0;
margin: 0 0 0 -999em;/*move the left margin off the page*/
width: 0;
}
ul#some_id li a {
display: block;
height: 75px;
margin: 0;
padding: 0;
width: 200px;
}
/*additional style rules for the links (item_1, etc.)*/
Not only have we added additional structure to our document, we have also removed the accessibility concerns regarding the use of an empty, redundant list item. By adding the heading to the list and applying the necessary CSS to control the look we have instantly added structure to the document. This also helps to ease any future maintenance of the site for those other than ourselves.
There also numerous other methods to achieve the same results that I have noted above. Simply find one that fits you best or that fits within the project constraints (e.g. DOCTYPE, budget, time limit, your own experience with CSS, etc.) This same methodology can be applied to navigational lists that utilize the vertical bar, or “pipe” character (|), separator to visually achieve link separation. Any non-essential markup that we can remove from the document and hand over to CSS to achieve the same result is a good thing.
Another scenario involves the use of a low-end DOCTYPE, such as HTML 4.01 Transitional or XHTML 1.0 Transitional, to utilize deprecated HTML elements and element attributes. The whole idea behind accessible and semantic Web design is to separate the three key layers of Web design:
In programming terminology this would be referred to as being “loosely-coupled” and encapsulated. When we utilize presentational elements or attributes, like the <i> tag, the <b> tag or the HTML border attribute, we have tied the presentation layer to the structure of the document. The <i> tag represents “italicized” text which is a visual element that has no meaning to some one who is visually-impaired. The same holds true for the <b> tag, since it is meant to convey bold text. The more semantic approach would be to use the <em> tag to convey emphasis (italics) and the <strong> tag to denote stronger emphasis (bold).
The use of the border attribute is often used to remove or add borders to certain objects on the page. Some designers use the following code to remove the border from around linked images:
<a href="somepage.html"> <img alt="some image" border="0" height="24" src="images/some_image.png" width="100" /> </a>
While this markup will validate, even at XHTML 1.0 Transitional, it is also an implied visual attribute that is better suited for CSS. It will also fail validation for WAI Priority 1, which is the lowest possible level of accessibility. The more accessible approach would be to remove the border attribute from the image tag like so:
<a href="somepage.html"> <img alt="some image" height="24" src="images/some_image.png" width="100" /> </a>
And use CSS to remove the default border from linked images:
a img {
border-style: none;
}
I wish that I could take credit for this neat trick, but I actually picked up this technique from Dan Cederholm’s great book, Web Standards Solutions. If you do not own this book I strongly suggest you head over to Dan’s website and pick yourself up a copy. You won’t regret it.
I love the way that JavaScript adds that little bit of “peppiness” and visual impact to some browser-based applications. I also really hate it when websites no longer function with JavaScript disabled. I tend to disable it for testing purposes or for security reasons, but there are folks who do not have JavaScript capabilities at all. This leads to a nice blank page in most cases, but in other, more usability-focused, instances this cause certain key navigational or form elements to stop functioning at all.
When you rely upon certain add-on technologies (like JavaScript or Flash) to be present in order to use your website you are effectively taking an elitist stance. You are saying to those who do not have (or have no use for) JavaScript and Flash that your website is an exclusive club to be used by only those with said technologies. While it may be okay to present your own personal site or blog in this way, it is a really big snub to those without scripting to build a commercial, business, or educational website that relies heavily on JavaScript for content access.
One of the easiest ways to provide alternate content in case JavaScript is disabled is to provide <noscript> content. Not exactly the most elegant approach, but it will certainly give you a place to put alternate functionality should the user have no scripting capabilities. Another approach is to provide the basic functionality you seek using HTML and augmenting the functionality of the desired HTML element using DOM scripting techniques. In other words, provide the basic functionality in the HTML markup and use unobtrusive JavaScript to “hook” into the elements you want to control.
Far too many sites are useless when you disable JavaScript, so keep that in mind when you absolutely must have that killer “Fade In and Reveal” JavaScript effect on your search forms. (*Note: disable JavaScript in your browser and try to use the search form to see an example of the kind of “Technology Lock-Out” I am describing). If you must have this sort of frosting on your cake at least make sure your users can still get to the cake underneath.
A quick and easy way to ensure that the user has scripting is to use a standard checkpoint before trying to execute any JavaScript code:
/**
* Only run the function on browsers that
* understand 'getElementsByTagName' - new browsers
*/
if(!document.getElementsByTagName) {
return;// return nothing
}
Most browsers support this check if they have scripting capabilities. Ensuring that the script actually works as intended is a whole other topic and would require more space than I have room for here. A great book on the subject of JavaScript is “JavaScript: The Definitive Guide” by David Flanagan. While extremely verbose, it will help to outline some of the ways for your scripting to become more flexible and offers some insight into degrading gracefully should the visitor not have scripting capabilities.
This should really go without saying, but you should always validate your HTML. Even if you do not care whether your personal website validates at a given specification you should keep the following in mind when designing commercial sites: Most screen reading software relies on valid markup in order to function properly. It also makes perfect sense from a semantics viewpoint since it may help you to pinpoint markup errors within your code. It will also help you to write better code by allowing you to actually see where certain elements or attributes fail.
And while this is purely opinion, I feel that we should stop using an outdated DOCTYPE for our pages. This relates to Rule #3 in that some designers utilize an old DOCTYPE so that they can keep using deprecated elements or attributes (like the border attribute or <b> tag) without failing validation.
We are no longer working in the 1990’s; stop using HTML 4.01 Transitional for new pages. For that matter, stop using XHTML 1 Transitional as well, since that was meant as a baby step into the world of XHTML. The time has come for us to stop relying on old tricks and make the switch to XHTML 1.1 (or at least XHTML 1 Strict). Once you get used to writing proper XHTML it will no longer seem to be a chore to use the language and it will become second nature for you.
As Web designers we have become accustomed to relying on hacks and tricks to get the job done. Often times these tricks come at the expense of accessibility and semantics. It is argued that using a table to markup a form is okay. I disagree since tables were meant to display tabular data (think: spreadsheets) and not for controlling layouts. This is a prime example of misusing a basic HTML construct.
There are numerous opinions regarding how to markup a form properly and I
will leave that up to you to find your own suitable method (I prefer to use
a definition list, but that is my own method and may not suit your needs).
The main thing is to use the right tool for the job. If you need to draw attention
to a section of your document, don’t use a paragraph tag with a CSS class
to make it “big and bold.” Look at the structure of the document,
determine where it falls within the hierarchy of the document, and use a heading
tag to markup the text. Also keep this in mind when designing forms. Quite
a few designers tend to use an unrelated block level element, such as a paragraph
tag, to markup the form’s labels. This is kind of silly since HTML provides
us with a ready-to-use container element for just this purpose: the <label> tag.
Plus, if you associate the labels with their corresponding form inputs you
have added accessibility and semantic value. Just use the right tag for the
intended purpose and stop hacking your pages to bits.
After many years now you can write HTML pages in your sleep, but can you properly structure those documents? What about CSS? Can you create a two-column CSS layout from scratch without “Googling” for tips? Do you really understand the WCAG priorities? If so, good job! You seem to have been able to keep your skills up-to-date and keep pushing yourself to have a better understanding of the Web as a whole. If not, then it is time to get off the couch, stop using old techniques and start learning new methods and technology implementations for yourself. And yes, I am also talking to you folks who are still allowing your code editors to cook-up some “tag soup” for you. You cannot create accessible, semantically-rich documents using modern Web Standards if you cannot actually write HTML and CSS yourself. While not exactly an accessibility or a semantics issue in and of itself, having the knowledge to be able to write some proper JavaScript can help you to overcome (or code around) certain accessibility issues with regards to scripting.
Don’t rest on your past achievements thinking that the Web will stand still for you. Anyone that is really into the aesthetics of modern Web design will tell you that it is a constantly changing and updating field. Things that were considered best practices only yesterday are now being challenged, deprecated, and overthrown by new methods.
There are millions of designers and developers out there who are willing to share their tips and techniques with you on just about any Web-savvy topic. Don’t be afraid to be the “n00b” and ask questions or even challenge a particular viewpoint. Don’t be afraid to learn all that you can about any technology you use regularly, no matter how complex the subject matter. And, last but not least, share your experiences with others. That is how we all learn and grow. Got a neat trick that you learned using CSS? Share it with others on your own site or a public forum. In any case it is okay to share your knowledge. There are lots of folks out there who may be glad you did.
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.
Let me know what you think about this article by leaving a comment on the blog.