Four Essentials

The Web is a young medium – it’s really only about 10 years old. Consider television at age 10. Or cinema. When we look at examples of these media at age 10 it’s easy to laugh. They were primitive and still finding their way. They were exploring the limits of their new technology.

That’s where we are today. We’re pioneers, still exploring the limits of this new media called the web. Our grandchildren will no doubt look back on what we’re doing and think it’s quaint! We have still so much to discover about what the web can do and how it can be used.

But in order to properly explore the web, we need to start with a solid foundation.

Enter our four essentials, courtesy of Web Essentials 04. They are:

1. Valid code – standards compliance
2. Accessible code
3. Semantically correct code
4. Separation of content and presentation

Web Essentials 04 was a two day conference held in Sydney during 30 September and 1 October 2004, and covered these topics in detail. Speakers included Dave Shea, Douglas Bowman and Russ Weakley, just to name a few. Instead of outlining each part of the program, I’ll deal with the nuts and bolts of these four issues as they were dealt with by the various presenters.

The important distinction to make firstly is that having valid code in itself does not necessarily make your website accessible. Nor does simply separating your content from your presentation. The four points all form part of the puzzle, but are not complete solutions in themselves.

1. Valid Code

Most things that are built or manufactured are built to some form of standard. Would you buy a car that didn’t conform to design rules? Or a house that didn’t comply with your local building code? Or even a toaster that didn’t comply with basic safety standards?

There is no doubt about it – standards exist for a reason, and ignoring them is unprofessional. Validating your pages with the W3C’s HTML validation service should be a standard part of your quality assurance. In the real world, there will be some examples were pages won’t validate. The main point is: if your pages don’t validate, it should be for a reason other than you didn’t bother trying.

2. Accessible Code

Until you’ve heard a website via a screen reader like JAWS you really have no idea how difficult your website can be to people using 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 with 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 SUMARY 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 a tool tip for 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 well, as screen readers can navigate these elements.
6. Use high contrast colours to accommodate other visual impairments.

3. Semantically correct code

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

Semantics deals with the relationship between signs and symbols and the meaning they represent.

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

It’s also important to note that diminishing returns apply to checking your semantics. Getting a few basic things right can vastly improve the meaning of your document. You can also go too far past that point and spend hours only achieving minor improvements!

So what sort of things should you look out for?

1. Again, 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 deal with.
3. Lists are a great way to group related information. Even if you don’t want it to look like a list, think about whether the information has that sort of relationship, 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. Ahhh, everybody’s favourite! Whilst using tables for layout is certainly out of fashion (and with good reason!) tables are still perfectly valid for displaying 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!
   
   1. Use SUMMARY to explain the table to those who can’t see it, CAPTION to explain it to those who can.
   2. <thead>, <tfoot> and <tbody> help explain parts of the table, as well as providing good CSS hooks for later styling.
   3. Similarly, use <th> instead of <td> for header cells to convey the extra significance of these cells.
6. Group your forms into meaningful chunks. Using <fieldset> and <legend> not only helps those with disabilities, it’s also a big usability plus for those without disabilities as well. And using <label> to caption your form elements helps to associate your text with the element as well.
7. <div> and <span> elements have no real semantic meaning, so use them judiciously. I’m not saying “don’t use them”, bit if there is another element that explains the content, use it instead!

4. Separation of content and presentation

No volume of words can describe the significance of this better than a working example. So was born the CSS Zen Garden. 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 on bandwidth, faster download times and improved accessibility, just think of how much simpler your job will be next time a client asks for a redesign. No more re-coding the entire site!

A further benefit was explained by Doug Bowman who discussed his experiences redesigning Blogger. Once he and the Blogger development team had agreed on a basic XHTML structure, he could work on refining the design by accessing the CSS file without interfering with the development team’s work. The two could then work on the site independently and concurrently. Another compelling reason to keep content and presentation separate.

The wrap up

Aiming to achieve these four essentials is basically about best practise. 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. Can’t see a thing, but ignore him at your peril.

This article is a summary of some main points I took away from Web Essentials 04. Much more was covered – for more details check their website as they plan to post full transcripts and presentations in the near future.