Practical Accessibility Tips with WCAG 2.0

Derek Featherstone recently wrote a blog entry titled “When is the right time for accessibility?” in which he looks at when is it appropriate to invest in accessibility. Is it better to release your product and add accessibility later, or build-in accessibility from the start?

As far as building web sites is concerned, I’m with James Edwards when he says it’s our job as web developers and designers to ensure content accessibility:

We should make an effort to create accessible content, because it’s part of our job. And frankly, it doesn’t take much effort; it’s not difficult.

I have to admit that for me, accessibility has often appeared to be a minefield, where every seemingly minor decision has the potential to create an accessibility disaster. I’ve looked for a central resource that will show me practical examples of correct markup, so that I can avoid making accessibility mistakes that will be hard to fix in the future. I think the “Techniques for WCAG 2.0” document is a great starting point.

Usually W3C documents are tedious, technical, and hard to wade through — trust me, I did a lot of wading when I was editing the SitePoint CSS Reference. But “Techniques for WCAG 2.0” is unlike that at all; it’s written for web developers and designers — instead of browser makers — which makes it very accessible (ha ha).

As a quick sampler of the techniques presented, here are a few tips for constructing forms. You’ll notice straight away that the techniques frequently seem like basic common sense, but that’s often the case with accessibility.

Use Standard HTML Form Elements

As described in H91: Using HTML form controls and links, the recommendation is to use standard HTML form controls and links. Standard form elements have established keyboard shortcuts provided by user agents, and assistive technology software makes use of the associated accessibility APIs built into every operating system. Yes, it can be as simple as that.

Always Use Explicit Labels

H44: Using label elements to associate text labels with form controls makes the recommendation that you should always have a label element with an appropriate for attribute value for all your form fields:

<label for="fname">First Name:</label> 
<input type="text" name="fname" id="fname" value=""/>

It also recommends that you avoid implicit labels like the following because of compatibility problems with some screen readers:

<label>First Name: <input type="text" name="fname" id="fname" value=""/></label>

Use the tabindex Attribute

H4: Creating a logical tab order through links, form controls, and objects highlights the importance of the tabindex attribute. Adding the attribute to all your form elements to create a logical tab order allows for efficient keyboard navigation of your form:

<label for="fname">First Name:</label> 
<input type="text" name="fname" id="fname" value="" tabindex="1"/>

Indicating Required Fields

H90: Indicating required form controls is my favorite of the few I’ve mentioned here and an example of the practical help you’ll find in the guidelines. It outlines three simple, accessible ways to indicate that a field is required.

Use the word required in the field label:

<label for="fname">First Name (required):</label> 
<input type="text" name="fname" id="fname" value="" tabindex="1"/>

If you use an asterisk to indicate required fields (like so many sites do) then try using the abbr element to add the much needed information:

<label for="fname">First Name <abbr title="required">*</abbr>:</label> 
<input type="text" name="fname" id="fname" value="" tabindex="1"/>

If you use an icon, make sure to use the alt attribute:

<label for="fname">First Name <img src="required.png" alt="Required field"/>:</label>
<input type="text" name="fname" id="fname" value="" tabindex="1"/>

There are many more tips on the WCAG 2.0 Techniques page, enough for a firm grounding in the art of accessibility. When you read through them you realize that accessibility is more about how to make your content accessible to everyone — regardless of user agent, device, or circumstance — rather than just various screen readers. Which is what the Web is all about anyway.