So you need to make your Web site accessible. It's not the purpose of this article to persuade you to do it; let's just assume that you've decided to do it.

Your first port of call should be the Web Accessibility Initiative (WAI)'s Web site at the W3C. They maintain a list of the legislative requirements of countries with specific legislation ( www.w3.org/WAI/Policy). If your country isn't there, you should follow the WAI's general guidelines, found at www.w3.org/TR/WCAG10-TECHS.

Simply put, the guidelines say

• A user should be able to navigate through the site using a keyboard if they can't use a mouse.
• Any information that is not in text that can be copied and pasted (eg, text in images / text in Flash movies) should have alternative text marked up in the HTML.
• Instructions should avoid requiring sight or accurate color vision (e.g., don't say "click on the red button/picture of a cat/ circle").
• Information that requires listening (e.g., audio recording of conversation) should be available as a written transcript or through subtitling.
• Don't induce epileptic seizures or nausea through flashing or flickering screen art.

This article looks at how to use Dreamweaver to ensure that WAI guidelines are adhered to.

Defining Accessibility - How Do Disabled People Use the Web?
A year or so ago, if you mentioned accessibility, it was very common to get a look of blank incomprehension back - how could blind or disabled people possibly hope to use the Web?

For many disabled people (or people with repetitive strain injuries, a broken writing hand, etc.), the biggest obstacle to using the Web is the difficulty in using a mouse. One of the aims of accessibility is to allow any Web site to be operated using the keyboard, tabbing for navigation, and using the enter key to push a button. Once this is achieved - and it's very easy to do - then the site is accessible. It could even be controlled by a mouth-stick for a paraplegic user, given appropriate hardware modifications.

For the blind, or visually impaired, the greatest impediment to Web use is, of course, the inability to see a screen. For blind users whose hearing is unimpaired, there is a technology called a screen reader that works on PCs. This is a speech synthesiser that "reads" the screen through headphones or computer speakers. There are many vendors of these - the main ones are JAWS and Windows Eye, both of which integrate with MSAA (Microsoft Active Accessibility), which is on all Windows machines from Win95 onwards. Any text on the screen is automatically available to MSAA. The challenge is for non-textual parts of the Web page (graphics, photographs, text-inimages) to be available to the screen reader, too. To get the feel of a screen reader, you can download one from www.readplease.com/rpdownload.php

Other assistive technologies exist, too - for the blind and deaf, a Braille pad can move pins, driven by special software, to make Braille characters for the user to feel. However, what you as a Web developer need to know is that in order for any of these assistive devices to work, the HTML must be coded to accessibility standards.

Making a New Site, or Updating an Old One?
If you're creating a brand new site, I suggest (no, actually, I implore) you create your site according to Web standards. This isn't the place to either justify the use of standards, or go into a discussion of how to use them. But while using CSS and XHTML or HTML 4.01 doesn't guarantee accessibility, it makes it considerably easier to make it so.

Tables used for layout can often confuse a screen reader, especially if they're deeply nested. The spacer gifs you'll need to pad the whole thing out will also cause the screen reader to work overtime unless you manually add alt text to them. Using CSS for layout means that the screen reader will ignore all that sexy presentational stuff and concentrate on the structure and the content of the site, which is in your (X)HTML.

If you are using CSS and doing some fancy layout, or using alternate style sheets that allow the user to change where the content is positioned on the page, you might not be worried about the order of your DIVs in the HTML. However, a screen-reader is blithely unconcerned with visual fripperies; it will read the content in the order that it appears in the markup. It's structural markup; it needs to be logical. 'Nuff said.

Setting DW Preferences
The first date I ever had with Cameron Diaz, I spent hours squeezing myself into an Armani suit, getting a $200 haircut, a manicure, and sluicing myself with expensive perfumes, yet forgot to clean my teeth. The moral of the story is, before setting out on the tricky stuff, get the basic preparation work done. (Cameron didn't notice, in case you were wondering, as I'd also forgotten to put on any trousers.) The Dreamweaver equivalent to the pre-date oral hygiene regime - and trousers - is setting Dreamweaver Preferences to do some of the work for you.

Spark up Dreamweaver (MX or MX 2004) and select Edit > Preferences and then the accessibility category in the Preferences dialog box. Under "Show Attributes when Inserting", check all five checkboxes - Form Objects, Frames, Media, Images, Tables (see Image I).

You have just sternly commanded Dreamweaver to remind you, via a dialog box, that you need to add certain extra information. It can't add the information itself, but one of the trickiest things about moving towards designing for accessibility is remembering to add all the extra bits and pieces you need to put in.

Accessible Images
Now you've updated your preferences, add an image to your site. You'll notice that a new dialog box pops up asking you for long description and alternate text, which will be added as attributes to the img tag that Dreamweaver will create. The long description is a URL of a page that will describe the contents of the picture (imagine it's some really complex graph showing profits against the price of fish and the value of the yen). It is entirely optional (and not often used).

The alternate text is the most important, and is mandatory. In a visual browser, you see alt text when you mouse over an image; it pops up like a little yellow 'tool tip'. While screen readers don't care about pictures, they love alt text and proudly read it out. You have 250 characters to describe your image. Here, for example, is some alt text in a blog entry on my homesite (www.brucelawson.co.uk) specifically about the pictures (see Image II).

While a blind person obviously wouldn't see the image, the point of the blog entry is the picture and they'd understand the context by hearing the phrase "scan of 12-week fetus". Otherwise they won't understand what I mean by "meet the new Lawson".

Image III is an example of bad use of alt text on a Web site header made of four separate images:

The alt text here bears no resemblance to the picture. This could just confuse a non-sighted visitor; the purpose of the site is adequately summed up in the text superimposed on the rightmost picture. This text could have been used as alt text for the logo - a much more logical place for it. Finally, it is not necessary to put alt text explaining shiny happy stock photography models at all.

Which brings us to the question, what do you do with "empty"images, like the decorative people in the last example, or in spacer gifs in old nested table layouts? The answer is simple: use empty alt text, which the screen reader ignores.

Unfortunately, adding blank alt text isn't intuitive in Dreamweaver. If you just hit enter on the alt text/ long description dialog box, Dreamweaver rather stupidly adds no alt text at all (making the markup invalid, as well as ignoring your earlier command to help you make an accessible site). Grrr! After reclining back and receiving a stress-reducing massage from Ms. Diaz, you need to go into the property inspector and select the drop down menu next to alt and select blank (see Image IV).

You need alt text on every image, whether it's an empty image, a hotspot in an image map, a photo of a kitten, a chart showing your company's 750% increase in revenue, or that cute animated gif of a crocodile eating your exsweetheart that you put on your blog in a bad mood.

What Do Links Sound Like?
A very Zen question, you might think. But go to any page on the Web and press the Tab key a few times. You'll see the focus move through all the form fields and all the links. This is a handy way of navigating the site if you're visually impaired; the screen reader reads out the links as you're tabbing through. But imagine your frustration if you were tabbing through links on this potentially fantastic site:

To create world peace and
harmony <a href="foo.html">click
here!</a>
To learn the secret of everlasting
happiness <a href="goo.html">press
this!</a>
To ensure that Celine Dion never
sings another note <a
href="poo.html">go to this page!</a>

The screen reader will just read out "link: click here .. link: press this .. link: go to this page!", and you'd be so bored you'd surf off somewhere else, missing out on all the fun.

The moral? Ensure that the text in links adequately reflects what's in the link. It isn't just an accessibility must-do; "click here!" is soooo 1998. Everyone knows links are for clicking.

HTML Navigation
Here's a really simple rule to help accessibility to your site for people with motor skills problems, the elderly, or kids. Don't have tiny, tiny buttons! It can be very tricky to point your mouse onto the active area.

There's a couple of neat HTML accessibility attributes for navigation in forms called tabindex and accesskey. The tab index controls in what order the user tabs through the fields on the screen. If you're not happy with the default order, you can define your own. (With multi-nested table layouts, it can get very complicated, very quickly.)

You can add the tabindex when making a new form in the "input Tag Accessibility Attributes" dialog box that appears when you're adding new fields. However, you probably won't realize until later that your tab index isn't logical; to amend, right click on the field in the design view of Dreamweaver and select 'Edit tag'. In the Tag Editor, select Style Sheet/Accessibility in the left-hand menu. In the right-hand panel at the bottom of the list of attributes you will see Tab Index; you can add this attribute there (see Image V).

You'll see in the dialog box that you can also enter the AccessKey here, which allows jumping to a form element or activating something by pressing alt+ a nominated key - much like activating menu items in Microsoft Word. Take care not to duplicate standard IE keyboard shortcuts. You'll need to let the user know that there are Access keys; use inline CSS or a class that highlights the chosen letter (by underlining, for example, as in MS Word)

Enter <span style="text-decoration:
underline;"> p</span>hone number

would appear on the screen as Enter phone number, and the user could jump to this form field by pressing Alt+P.

JavaScript Navigation
Some browsers, and all screen readers, don't know JavaScript from a wombat. Not usually a problem if you go modern and use CSS for rollovers and are careful with your navigation. The cardinal sin of JavaScript navigation is the use of a drop-down menu that can't be controlled from a keyboard. If you must have a JavaScript drop-down menu for navigation, use a 'go' button for the user to confirm.

For accessible pop-up windows, there's a useful tutorial and solution (which costs $1.99) at www.dmxzone.com/go?5483.

Tables
Tables are evil, right? Well, no. Although tables for layout are a redundant technique in these CSS days, tables are still absolutely the only way to go for displaying tabular data - that is, any data that would be appropriate to display in an Excel work sheet.

Once again, the Dreamweaver preferences you set help you; after inserting your table and entering number of columns, padding, etc., in the normal dialog, an additional dialog requiring accessibility features leaps up like Charlies' Angels to the rescue (see Image VI).

The Caption will be inserted, by default, above the table.

But what's that question about headers? And what's that "scope"in the markup? It tells the browser that the headers are for columns, not for rows. Why does it need to know?

One of the problems that screenreader users have with tables is that you can't scan back up to read the headers with a screen reader as you can with your eyes. Consider the bus timetable in Image VII.

If you're using a visual browser, you'd just look at the name of your bus stop and scan down the column. But, if you're listening to this with a screen reader, by the time you've heard 08.45, you'll have forgotten whether that's the time at Bruce Avenue or DMX zone.

You'll need to add <th> (table header) tags with a scope attribute to tell the screen reader whether the header is for a column or a row. To make a screen reader tell the user the name of the bus stop before each scheduled time, the mark up is

<table>
<tr> (the first row is the row of
headers)
<th scope="col">Bus
station</th>
<th scope="col">Town Hall</th>
etc
</tr>
<tr> (all the elements in the
first row)
<td>07.10</td>
etc
</tr>
<tr> (all the second row)
</tr>
</table>

You can now amend the skeleton code that Dreamweaver has made for you to make accessible data tables, and style it for beauty and grace using CSS.

Accessible Language
This means two things; the first is the use of language that is simple enough to be understood by people with cognitive disabilities. As this term describes everything from Alzheimer's Disease to Parkinson's to Down Syndrome to dyslexia, I leave it to you to decide whether your Web page on Quantum Physics needs to be rewritten for such users.

But , if a screen reader expects to read English and you've got a French phrase in your content, it would probably get in a horrible tangle. Consider this content:

Cameron breathed, "Oh, mon amour", as Bruce poured the champagne, and then she raised her glass, exclaiming "Prost!".

"I must go and save the planet", replied Bruce, swinging on the chandelier out the window. "Ciao!" he waved as he skied down the mountain towards Blofeld's lair.

In order to make the screen reader pronounce the words as accurately as possible, and not as if they were English, you need to mark them up like so:

<p> Cameron breathed, "Oh, <span lang="fr">mon amour</span>", as Bruce poured the champagne, and then she raised her glass, exclaiming "span lang="de">Prost</span>"</p> ....

The language codes are here: www.w3.org/WAI/ER/IG/ert/iso639.htm

Validating for Accessibility
There's a built-in validator for accessibility in Dreamweaver. Some of the warnings it gives you just don't matter; it nearly always tells you not to use color to identify things, for example, whether you are doing so or not. It just isn't that clever. Use it to hunt down mark-up bugs, but nothing replaces the dreaded "t"word ...

Testing
No amount of push-button validation can replace testing. Here's my usual testing regime:

1. Turn off images in the browser. Does every red "ain't got no image" cross have alt text showing?
2. Unplug your mouse. Feed it some cheese. Edam is good. While it's tucking in, use the keyboard to navigate around your site. Can you?
3. Turn off JavaScript in the browser. Can you still use every form and every link - especially if you're using popup windows?
4. Okay, assuming you don't have the large sums of money to invest in a screen reader, you can see what a screen reader would read out by simulating the text-only browser known as Lynx. The Lynx viewer can be found at www.delorie.com/Web/lynxview .html and shows you what your site would sound like with no images, JavaScript, or anything but text. It's a sobering experience.

Accessible - but Usable?
So, your site is now technically accessible - but is it usable? A big problem can be links. A page with a lot of links before the main content is terribly frustrating for a screen-reader user as they have to listen to all the links before they get to the content tthey're looking for.

Consider my local council's Web site. I selected a link to see how to pay business rates (real estate taxes) and got the page shown in Image VIII.

The content I want is right there in the middle of the screen - but I have to listen to all the links first. The solution to this is a "skip links" link right at the top of the page. It can even be white on white (or red on red, or whatever your color scheme is) so that sighted viewers don't see it, but the screen reader will pick it up. It's just a link that goes straight to an anchor tag at the top of the content, thereby bypassing all those pesky links...

Some Useful Resources
Well, it's been nearly 3,000 words and we've only had time for an overview of the main aspects of accessibility; we haven't looked at Flash, SMIL, or even all of the possibilities in HTML. Don't be put off - we've covered 80% of all the techniques that you need to know. Here's some more resources to look over while I get into my tuxedo for tonight's movie premiere with you-know-who. Now... where are my trousers?

• There's a free DMXzone extension that adds good-looking CSS navigation lists to your page - the List-o-Rama! at www.dmxzone.com/go?5618 - as well as a good many $2 tutorials on accessibility and standards at www.dmxzone. com/index.asp?TypeId=28&CatId =691
• www.accessify.com is another great resource for all things accessibility related. Ian Lloyd, who runs the site, has an exceptionally useful collection of favelets that allow you to check pages at www.accessify.com/toolsand- wizards/accessibility-checkingfavelets. asp, as well as many other resources atwww.accessify.com/toolsand- wizards/default.asp#6.
• The industry-standard book on the subject, Constructing Accessible Web Sites (Thatcher et al; Apress) is available on Amazon at www.amazon.com/exec/obidos/tg/det ail/-/1590591488.
• For advice and discussion of all things Web standards-related, go to www.webstandards.org.