Skip to content

You Mean the ADA Doesn’t Already Cover Web Sites?

Department of Justice building

The US Department of Justice has issued an Advance Notice of Proposed Rulemaking (ANPR) and is holding public hearings on the topic of applying the Americans with Disabilities Act (ADA) to private-company web sites. While many in the web accessibility community are lauding the move, many others — including more than a few web professionals — have been left scratching their heads. It seems there are two sources of this confusion.

But if Section 508 Doesn’t Cover the Web, What Does It Cover?

The first thing that throws people for a loop is the number “508”. Especially here in the US, “Section 508” or often just “508” has become a shorthand way to refer to web accessibility in general. This is not surprising. It’s easier to say “508” than “web accessibility” and it’s a lot lot easier to write. I’ve even heard it referred to as “501” (Levi Strauss & Co. should be thrilled at how much brand awareness their line of blue jeans commands).

The thing is, though, that however convenient a phrase Section 508 might be, it’s a particular piece of legislation with a relatively limited scope. Many people think Section 508 is part of the ADA. This, too, makes sense, since both deal with accommodating people with disabilities. But it’s not correct.

Section 508 is actually part of the Rehabilitation Act of 1973 as amended by the Workforce Investment Act of 1998. There’s a mouthful! Not to mention that within Section 508, there are several sections covering various technologies. §1194.22 is the part that specifically covers web sites. In any case, Section 508 is not part of the ADA and it only applies to the web sites of the US federal government, its agencies, and those sites provided by private companies contracted by the federal government.

The reach of Section 508 sounds very limited, but a couple of things are worth noting. First, the idea was the government’s considerable purchasing power would broaden the reach of Section 508 to the private sector. The thinking was that companies would not create one accessible version of their product for sale to the government and another non-accessible one for sale to the public at large, they would just create a single accessible version for sale in both markets. The second thing to keep in mind is that when companies as well as state and local governments looked to make their own sites accessible, they often took their lead from prevailing law, even if they weren’t explicitly covered by it. In the US this has meant Section 508.

So, Section 508 does cover the web, but it legally only covers a very specific part of it: the US federal government.

OK, but Doesn’t the ADA Cover Everything?

As the public at large becomes accustomed to seeing Braille on elevator buttons, access ramps to buildings, and grab bars in public restrooms, it might seem that in the 20-plus years the ADA has been law, that it really does cover pretty much all aspects of life. In fact, Title III of the Act does explicitly cover a remarkable range of human activities such as restaurants, theaters, bowling alleys, and places of public accommodation.

The ADA was passed in 1990 when the internet and the web effectively didn’t exist. While the Act is explicit on such private entities as bowling alleys, it couldn’t have anticipated the huge role web sites would quickly come to play in daily life. While the Department of Justice has long maintained that it considers private company web sites to be covered under the ADA — a letter written to Senator Harkin is most often cited — the question of whether web sites are “places of public accommodation” has been an issue at the heart of several prominent lawsuits, including the case against Southwest Airlines and the Target.com case. As of this writing, whether the web is covered under the ADA is an open legal question.

So, What Exactly Is the DOJ Proposing Then?

If Section 508 covers the federal government’s web sites, the US Department of Justice feels that the ADA does cover private company web sites, but the courts have not come down decisively one way or the other, what is going on with this “proposed rulemaking” on the part of the DOJ?

Effectively, the Department is exercising its administrative role and making explicit its interpretation of whether and how the ADA will apply to private company web sites. By issuing its advance notice, it is giving the public at large the opportunity to comment on these changes and have input on the final decisions.

While many of the details are still open — the Department has asked for comments on 19 different questions — the end result of this rule making will be that private companies’ web sites will be explicitly subject to the ADA. No longer will plaintiffs have to first argue that the ADA is applicable, they can now go directly to arguing the specific violation. Presumably the DOJ will also be in a position to take enforcement measures of its own.

Conclusion

The net effect will be that instead of having a reactive responsibility to make their web sites accessible because of the threat or fear of lawsuits, companies will now have a pro-active responsibility to ensure their sites are accessible from the beginning.

This will mean an adjustment in how web sites are developed, but these adjustments can be economically made by even small companies. Adding in an accessibility review can add 5% or less to development costs when planned correctly and with good, committed developers. These costs can be further reduced with as little as two days’ worth of training. And it is much much cheaper to build a web site correctly with accessibility in mind in the first place than to retro-fit an existing non-accessible one.

Web Accessibility of Checkboxes, Radio Buttons: the Fieldset

Code review

When I talk with other developers who don’t have a strong background in web accessibility, they are often taken aback when I tell them that radio buttons and checkboxes should be wrapped in a <fieldset> tag.

The Problem with the Usual Approach

Here’s a simple two-option set of radio buttons:

Radio buttons "female" and "male" answering the question "Gender"

Although I’ve seen some absolute coding atrocities on even large e-commerce sites, most polished developers produce something like this:

<h3>Gender</h3>
<input type="radio" name="gender" id="gender_f" checked="checked" />
<label for="gender_f">female</labe>
<label for="gender_m">male</label>

This is not bad for what it is, but it’s not quite right, either. But most importantly, it’s not really accessible.

The problem is that the “question” (gender) is not programmatically associated with the possible answers (female or male). This can be a problem for screen readers. Most screen readers operating in their default mode, like JAWS’s PC Cursor mode, will read the word “gender” in the example above and “guess” that it’s related to the radio buttons that follow it.

But when the screen reader goes into forms mode, allowing the user to skip from form field to form field using the tab key, it doesn’t always work, leaving the user guessing what the question is that the particular radio button is answering. In this simple example, it’s probably easy enough for the user to guess if the screen reader speaks “female” without also speaking “gender”, but if this were a mortgage application, for instance, it could leave the user guessing, “Is it asking me for the applicant’s gender or the co-applicant’s gender?”

<fieldset> to the Rescue!

The solution is to wrap everything — the question and all the answers — in a <fieldset> tag. The question itself gets wrapped in a <legend> tag so the code looks something like this:

<fieldset>
<legend>Gender</legend>

  <input type="radio" name="gender" id="gender_f" checked="checked" />
  <label for="gender_f">female</label>
  <label for="gender_m">male</label></fieldset>

It produces something that looks like this:

Radio buttons "female" and "male" with fieldset box around them. The word "Gender" is inset in the boxIf the default display of the fieldset doesn’t fit with the design of the rest of the page — and often it won’t —, it can be styled using CSS. The Man in Blue site has some examples on styling the <fieldset> tag.

Wait, There’s One More Thing to Consider

There’s one more thing, though. There is only limited styling support for the <legend> tag itself. Thanks to my colleague, Dan Herbert, for forwarding me a post from Marc Pacheco about just how poor browser support is for styling this tag.

Not surprisingly, the second part of my conversation with my developer colleagues is about how to style the <legend>. Usually the aim is to make it not look like a legend. The simple answer is to wrap the content of the <legend> tag in another tag. The <span> tag is the most common choice. Those of us who fret about semantic code rightly squirm at this solution, but as far as accommodations go, this one is a pretty minor compromise. Tyssen Design’s article, Legends of Style is a few years old but shows some of the nitty-gritty style coding.

Except for…

Radio buttons and checkboxes work largely the same way and should both almost always be wrapped in a fieldset. “Almost”? There is one exception for checkboxes for which a fieldset should not be used. This is when a single checkbox is used to answer a true/false yes/no question.

A checkbox followed by the words "I accept the terms of use"The code for this looks like this:

<input type="checkbox" name="acceptterms" id="acceptterms" value="accepted" />
<label for="acceptterms">I accept the terms of use</label>

In this case, having a <fieldset> tag would be redundant and would actually harm accessibility.

Conclusion

Even front-end developers who are strict adherents to Web Standards might not be aware of the correct web accessibility approach to checkboxes and radio buttons. These form elements should be wrapped in a <fieldset> tag with the question they answer held in the <legend> tag. Because of the limited browser support for styling the <legend> tag, its contents often have to be wrapped in another tag, like <span>. The one time when a fieldset should not be used is when a single checkbox is used to answer a yes/no question.

Welcome!

Accessibility Associates is pleased to launch its blog on all things associated with web accessibility/Section 508 matters.

Expect to see posts on developments in the legal environment for web accessibility, the evolution of standards, and general trends in this domain. Accessibility Associates takes pride in its strong web development background and training, so there will be technical material, too, but always related to web accessibility.

Keep up to date with this blog by subscribing to the RSS field (link on the side column), or following our tweets, either from this page (again on the side column) or directly on Twitter. Or just drop by from time to time.

Let us know what you think! We love to hear from you.

%d bloggers like this: