Skip to page content or Skip to Accesskey List.

Work

Main Page Content

Hit And Miss With Section 508

Rated 3.81 (Ratings: 3)

Want more?

 
Picture of OKolzig37

Ben Dyer

Member info

User since: 08 May 2001

Articles written: 4

(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

so:

<fieldset>

<legend>What is the airspeed velocity of an unladen

swallow?</legend>

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

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

m/s</label><br>

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

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

m/s</label><br>

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

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

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

</fieldset>

What is the airspeed velocity of an unladen swallow?

m/s


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

areas.

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.

Conclusion

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:

Ben Dyer has been tinkering with computers his entire life (starting with a TI-99 around age 3), and has been doing internet stuff for around six years now. For five years (about two ice ages in internet time), he was Senior Internet Developer for Imaginuity Interactive, an internet development firm in Dallas, Texas, before leaving in March 2003 to co-found ToSon BT, a company that provides creative and technical services (presentations, audio/video, live shows, internet) for churches and ministries.

His personal projects include DFW Anime.com, which keeps track of anime goings-on in the Dallas/Fort Worth Metroplex and Anime Blog Muyo! which is a group blog about anime. You can also read all about his nonexistant escapades (or at least find a bunch of stupid links) at his personal blog.

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.org Evolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.