By: Jason Foss

October 27th, 2004

Reader Rating: 8.5

The Web is a young medium: it's really only about 10 years old. Consider television at age 10, or cinema. Back then, these media were primitive, still finding their way. They were exploring the limits of new technology, but huge developments were yet to be made.

Web professionals are at that same point today. We're pioneers, still exploring the limits of a new medium. Our grandchildren will, no doubt, look back on what we're doing and think it's quaint. We still have much to discover about what the Web can do, and how it can be used.

Enter: conferences such as Web Essentials 04 [1].

Web Essentials 04 was a two-day conference held in Sydney, Australia, from 30 September to 1 October 2004, which explored in detail the essential pillars of the Web. Speakers included Dave Shea [2], Douglas Bowman [3] and Russ Weakley [4], just to name a few.

The four essential practices on which the conference focused were:

1. Valid code (standards compliance)


2. Accessible code


3. Semantically correct code


4. Separation of content and presentation

In this article, I'll deal with the nuts and bolts of these four issues as they were addressed by the various presenters.

The first important distinction to make is that having valid code in itself does not necessarily make your Website accessible; nor does the separation of your content from presentation. Each of the four points is part of the puzzle, but none is a complete solution in itself. Now, let's take a look at what was said about each of these points.

1. Valid Code

   Most manufactured items are built to some sort of standard. Would you buy a car that didn't conform to design rules? Would you purchase a house that didn't comply with your local building code? What about a toaster that didn't comply with basic safety standards?

   There's no doubt about it: standards exist for a reason, and it's unprofessional to ignore them. The validation of your pages with the W3C's HTML validation service [5] should be a standard part of your quality assurance. In the real world, there will be some examples of pages that won't validate.

   The main point is: if your pages don't validate, it should be for a reason other than that you didn't bother to try.

2. Accessible Code

   Until you've heard a Website rendered via a screen reader like JAWS [6], you really have no idea how difficult sites can be for people who use assistive devices. Often, it's the basics that can cause problems:
   

   1. The <title> element should contain a description of the specific page, not just the company name.
   
   
   2. The <h1> element on your page should do likewise.
   
   
   3. Make sure you can navigate your site with your keyboard. If you have navigation that requires 'onclick' or 'onhover', make sure you include a standard <a href> link as well.
   
   
   4. Similarly, "select and go" menus are impossible to use via a screen reader. If you must use a combo box for navigation, use a separate "Go" submit button to activate the choice.
   
   
   5. Use ALT text for all your images and SUMMARY for your tables. A table summary is much like the alt text for your images. Use it to describe the table to someone who can't see it, rather than to present a tool tip to those who can. Tool Tip-style comments should be used in the TITLE for images (and other elements) and CAPTION for tables. While we're on the subject of tables, make sure you use <th> elements, as screen readers can navigate these elements.
   
   
   6. Use high contrast colours to accommodate other visual impairments.

   Basic accessibility is not difficult to achieve, but can spare some users substantial agony. It's about being a good Web citizen and making a positive contribution to the Web being "world wide".

3. Semantically Correct Code

   This word gets thrown around a lot. But what does it mean?

   Semantics deals with the relationships between signs and symbols and the meanings they represent.

   To translate that into English, the (X)HTML elements you use should describe the content they contain. Your (X)HTML markup should explain the document itself, not how it looks.

   It's also important to note that the law of diminishing returns does apply to checking your semantics. Get a few of the most basic aspects right, and you can vastly improve the meaning of your document. However, you can also go past that point and spend hours to achieve only minor improvements!

   What sorts of things should you look out for?
   

   1. The <title> element. Describe the specific page, rather that using the same title for the whole site.
   
   
   2. <h1> to <h6> should be used to "chunk" your document into meaningful pieces. Announce the topic that the following paragraphs will address.
   
   
   3. Lists are a great way to group related information. Even if you don't want your presentation to look like a list, think about whether the information fits that presentation, and use CSS to change its look later if desired.
   
   
   4. In the case of images, use ALT to explain the image to someone who can't see it, and use TITLE for Tool Tips for those who can.
   
   
   5. Tables -- everybody's favourite! Using tables for layout is certainly out of fashion (and with good reason!), but tables are still perfectly valid for the display of tabular data. Tables help establish relationships between pieces of information, so don't use floating <div> elements if it makes sense to use a table!
   
   
   • Use SUMMARY to explain the table to those who can't see it, and CAPTION to explain it to those who can.
   • <thead>, <tfoot> and <tbody> help explain parts of the table, and provide good CSS hooks for later styling.
   • Use <th> instead of <td> to convey the extra significance of header cells.
   
   
   6. Group forms into meaningful chunks. Using <fieldset> and <legend> not only helps those with disabilities, it's also a big plus for those without disabilities. Use <label> to caption your form elements and help associate your text with those elements.
   
   
   7. <div> and <span> elements have no real semantic meaning, so use them judiciously. I'm not saying "don't use them", but if there is another element that explains the content, use it instead!

   Semantics alone will not earn you accessibility or validation – they're simply part of the big picture. What semantically correct code does provide is a solid platform for use on alternative devices, both now and in the future.

4. Separation of Content from Presentation

   What does the separation of content from presentation really mean? In a nutshell, it advises that your HTML contains no "presentation" markup: nothing that describes how it looks. All the "how it looks" instructions should be part of your CSS.

   No words can describe the significance of this any more clearly than can a working example, thus, the CSS Zen Garden [7] was born. Explore some of the designs, and keep in mind that you're looking at exactly the same XHTML document the whole time.

   Aside from all the perfectly valid arguments about saving bandwidth, faster download times and improved accessibility, just think how much simpler your job will be the next time a client asks for a redesign. No more re-coding the entire site!

   A further benefit to the separation of content from presentation was explained by Doug Bowman [8], who discussed his experiences with the redesign of Blogger [9]. Once he and the Blogger development team had agreed on a basic XHTML structure, he could work to refine the design through the CSS file without interfering with the development team's work. Designers and developers could work on the site independently and concurrently -- another compelling reason to keep content and presentation separate.

   Granted, a CMS may be in the way for some, but if it is within your power to separate your content and presentation, the practical benefits far outweigh the initial learning curve.

The Wrap-Up

The adoption of these four essential pillars of Web development is basically a matte of adopting best practice. If you take your work seriously, it's where you need to be.

Even if you know you don't have any potential customers with a disability; even if you know that nobody will ever view your site in anything other than Internet Explorer; even if you like the idea of charging a huge fee and spending months doing your next redesign; consider this:

There is at least one blind user you need to accommodate. His name is Google. He can't see a thing, but ignore him at your peril.

This article is a summary of some of the key points I took away from Web Essentials 04 [10]. Much more was covered, though. For more details, check the Website -- they plan to post full transcripts and presentations in the near future.

[1] http://www.we04.com
[2] http://www.mezzoblue.com
[3] http://www.stopdesign.com
[4] http://www.maxdesign.com.au
[5] http://validator.w3.org/
[6] http://www.freedomscientific.com/fs_products/software_jaws.asp
[7] http://www.csszengarden.com
[8] http://www.stopdesign.com
[9] http://www.blogger.com
[10] http://www.we04.com