(Note: I have contacted the webmaster at the section508.gov web site and

haven't received any response concerning these issues.)

In 1998, the U.S. Government drew up guidelines for accessibility for

internet and IT initiatives within the Federal Government, known as Section

508. They have since set up a title="Section 508 - New window" target="_blank">Section 508 web site to help government agencies meet

the necessary guidelines. Unfortunately, a quick href="http://bobby.cast.org/bobby/bobbyServlet?URL=http%3A%2F%2Fwww.section508.

gov%2F&output=Submit&gl=sec508" title="Bobby Check for Section508.gov - New window" target="_blank">Bobby

check shows that the Section 508 web site fails to achieve some of the

guidelines they outline. Let's look at what they missed and what we can learn

from it.

When electronic forms are designed to be completed on-line, the form shall allow

people using assistive technology to access the information, field elements,

and functionality required for completion and submission of the form, including

all directions and cues.

Section 508, Part 1194.22, Paragraph n

Mistake 1: Explicitly associate form controls and their labels with the

LABEL element.

Basically, every device must have some cue to associate any given form

control with a label defining what it is. This is done, quite simply, by using

the <label> tag around the text label of the form field, and

adding the id attribute to the associated

<input> or <select> tag.

<label for="first">First Name:</label><br>

<input type="text" name="first_name" id="first"

value="First Name">

This technique also has the added benefit in some browsers of allowing the

text label to be clickable for some form elements, as has been described href="http://www.evolt.org/article/Form_Labels/4090/15823/index.html"

title="Form Labels evolt.org Article">elsewhere on evolt.org.

Mistake 2: If there are logical groupings of form controls, use FIELDSET

with LEGEND on each group.

This requires that groupings of form elements (usually meaning groups of

radio buttons or check boxes) be marked as such using the

<fieldset> and <legend> tags, like



<legend>What is the airspeed velocity of an unladen


<input type="radio" name="velocity"

id="velocity1"> <label for="velocity1">1.8


<input type="radio" name="velocity"

id="velocity2"> <label for="velocity2">2.1


<input type="radio" name="velocity"

id="velocity3"> <label for="velocity3">What do

you mean, an African or a European swallow?</label><br>


What is the airspeed velocity of an unladen swallow?


for="velocity3">What do you mean, an African or a European swallow?

The most immediately obvious change is that many browsers (IE5.X+ and NN6.X+)

will render the <fieldset> tag by default with a border

around the element. However, a CSS definition of border-width:0px

will remove that.

Mistake 3: Include default, place-holding characters in edit boxes and text


This guideline is probably the most problematic of the three, because it can

be at odds with usability. This states that since some devices will skip form

elements that do not have a default value, that you predefine a default value

for every form element. Obviously, this can cause problems with users

unwittingly leaving default data in form fields. You could use JavaScript to

empty out the form field using an onfocus attribute, but you don't

want to rely on JavaScript exclusively (especially for accessibility purposes).

The better solution would be to use JavaScript to empty the form field (which

would be fine for most users) and then use a trimming function on the backend

to remove excess whitespace.


I really don't mean to hang Section 508 out to dry. I am happy that the U.S.

Government is making a concerted effort to push for accessibility on the

internet. However, we need to be careful that as we promote accessibility

online, our sites are also accessible.

If you are looking for further information on accessibility, and these rules

in particular, see these sites: