Accountability of Accessibility and Usability

In: Articles

By Anitra Pavka

Published on November 5, 2002

Lawsuits make me nervous. Even if I’m not involved, precedents may be set that affect me or my life. As a person who makes my living off of the Web, it concerns me that Access Now, Inc. and Robert Gumson have sued Southwest and American airlines because Southwest’s site is allegedly “inaccessible”. This isn’t the first time something like this happened, either. In 1999, the National Federation of the Blind filed a lawsuit against AOL because AOL’s internet services were inaccessible. Over the past two years, Access Now has also sued Barnes & Noble and claire’s because their sites were inaccessible. Filing lawsuits against inaccessible private business sites is a growing trend that may shape the future of the Web.

I wanted to find out why Southwest’s site became a target of this litigious trend and determine ways to prevent such lawsuits against sites I help build. I examined the Southwest site and focused on their Home page and Reservations page.

These are their two most important pages since the site’s main goal is to sell Southwest airline tickets or travel services of affiliated companies. The Home page is their face to the Web and the Reservations page gets users on the path to make purchases. Because of their high visibility, these pages will test the site’s level of commitment to usability and accessibility.

A Closer Look

Let’s start with a few positive points about Southwest’s site. The Home page uses a simple visual layout. It doesn’t display too much information or other “clutter” to distract users. The page design is “fluid”, meaning it resizes nicely to fit different screen resolutions. Using the keyboard, I can tab through links in the correct order. The text is resizable, (excluding text in graphics, but we’ll cover that later). It’s what you can’t see at first glance that’s the problem.

First, I checked out Southwest’s Home page using LynxViewer. LynxViewer lets you see roughly how a page will look in Lynx, a text-only browser. Though Lynx doesn’t substitute for a screen reader, its results can still be an eye-opener. It’s a good way to quickly check a page for some common accessibility problems. Then, I viewed the page source code and used a screen reader to confirm my suspicions. The two biggest accessibility and usability problems I found were how Southwest’s site handled images and forms.

Cardinal Sin of Web Accessibility

Southwest’s site committed the cardinal sin of Web accessibility: They did not use the ALT attribute for images that convey information. While ALT attributes aren’t necessary for spacer images or purely ornamental images, ALT attributes are essential for all images that convey content. The text in an ALT attributes describes to users of non-graphical browsers (including screen readers) what information is displayed by the image. On the Southwest Home page, their company’s logo didn’t even have ALT text.

The links that make up the top row of Southwest’s site navigation are images of text, but they have no ALT text. In LynxViewer, they show up generically as the image above. Lynx users have no clue where that link will go until they select it. They stumble from unlabeled link to unlabeled link. People using graphical Web browsers who have poor eyesight or who forgot their reading glasses may be out of luck, too. Unless they use a screen magnifier, they probably can’t increase the size of the images to increase the font size. That’s not the only group to which the text in graphics is inaccessible.

I used IBM Home Page Reader version 3.02 to test how a screen reader handled Southwest’s linked images that lacked ALT attributes. (Screen readers are usually more forgiving than Lynx). Since these images had no ALT text, it read part of the URL. For example, one link read: [cgi-bin/buildItinerary]. That text doesn’t clearly indicate to screen reader users that the link goes to the “Reservations” page. Users shouldn’t have to guess.

Some of the graphical links did have ALT attributes. For the most part, the ALT text was accurate and descriptive. It gave users a reasonable idea of where the link would go. However, not all ALT text was useful. This is a common pitfall. For example, one of the links read “SWABIZ”. Say what? That’s also what the ALT attribute read. As a new user, (disabled or not), it didn’t tell me anything meaningful. This was a case where it’d be useful to explain what the acronym meant or use a different phrase. The acronym is only user-friendly to people who already know the site. From their Home page, I clicked through two links to figure out what it meant. It’s their online tool for planning and booking business travel. It could be a really useful tool, but if people don’t know what it is, they won’t use it. This is a case where a simple label (like “Plan Business Travel”) wins out over a snazzy, unfamiliar acronym. The same label could be used in the ALT text to clarify it for users of non-graphical browsers.

Making Forms Usable and Accessible

Forms also posed accessibility and usability problems on Southwest’s site. Creating forms that are user-friendly for all users can be one of the greatest challenges Web builders face.

For accessibility purposes, people who create forms may need to add extra markup to help screen readers translate a visually-based association of a text label (like a question or description) and its form input field into a literal association of these elements. The forms on Southwest’s Reservations page did not have any additional markup to make them accessible and were further complicated by poor table layout. Here are a few ways to make forms more accessible.

Enclose the question or description associated with a form field in a <label for=””> tag. Then, add an ID attribute to the input field and make both the ID and FOR equal to the same value. (Please note that an ID value must be unique. You can’t give multiple form inputs on a page the same ID value). Here’s a sample of HTML 4 markup for a text field that uses this approach:

<label for="firstName">First Name</label>
<input type="text" name="fName" id="firstName" size="10" maxlength="20" value="foo">

If the form elements are laid out correctly on a page by using tables or CSS, adding that extra markup isn’t as important. What’s important is that the users know what the question or description is for a form’s field immediately before they’re prompted to enter a response. Unfortunately, Southwest’s forms were laid out in tables that “linearized” poorly, creating a confusing layout when accessed with a screen reader.

Most modern screen readers read table content in the same order it’s listed in the markup. In a simple table, they read table data cells from left to right across a table row, then continue to the next row down. On Southwest’s forms, the text describing what to pick for each select menu (“drop-down list”) is on a row above the select menus. All of the text descriptions are read together first, (since they’re in the same table row). Then, all of the select menus are read. There are no non-visual associations between a text description and its particular select menu. This forces screen reader users to have to remember in the right order what the description is for each select menu, so they can correctly enter responses later.

A simple modification to the form’s layout can improve its accessibility. Instead of putting the text description in a separate row, place it in the same table data cell as its associated select menu. Place the text description first, followed by a line break, and then the select menu. You can specify the background color of the text description using CSS. The result will look much like it does now. Plus, it’ll linearize correctly. It will read the description, then the select menu options. This dramatically increases the form’s accessibility.

To improve usability, clearly indicate which fields on a form are required and display any form errors on the form’s page, (not a separate one). If all fields are required and you think placing indicators by each field will clutter the page, add one instruction indicating everything is required. Highlight that instruction. Don’t bury it in a chunk of other information. If users don’t fill out all required fields or don’t fill them out properly (and input formatting checks are performed), display the error message on the form page. Briefly tell users what they need to do to fix the errors. Repopulate (keep) data the user entered, so they don’t have to fill out everything again. Clearly indicate each incorrectly entered or missing field. Server side form verification is recommended. Some users may have JavaScript turned off or it may not be supported by their user agent. Don’t rely on it for essential functionality unless you have no other choice. Gathering valid input from forms, especially on e-commerce sites, is too important to leave to chance.

Lack of Consistency

Consistency (predictability) is another key to improving a site’s usability and accessibility. As much as people like getting surprise presents or surprise parties, no one likes surprise changes in page layout and navigation. Users might feel startled or lost when they notice the change. They may check to ensure they’re still on the same site. Once they confirm it’s your site, they’ll wonder why it changed.

Users of assistive technology will feel especially lost or confused. Navigating a page with substantially different layout or navigation is like navigating a new site. They have to relearn how to get around your site on each page that’s inconsistent.

Inconsistency distracts users from their tasks or goals on your site. It can undermine trust in your site. Every site, especially e-commerce sites, should form a relationship with users based on trust. If you don’t build trust into your site, people won’t buy, even if they can access your Web site.

Maybe the ADA Doesn’t Cover the Web

Following such accessibility and usability principles results in a better site, but some people still ask: “Do I have to do that extra work?” It depends on who you are and the purpose of your site. If your site relates to government or a government service, some level of accessibility is probably required. If your site is a purely personal site, such as a Weblog, then accessibility is not required but is considered a common courtesy. If your site is a business site, then the answer depends on who interprets the law.

Some people believe that we shouldn’t be required under the ADA to make Web sites accessible. After all, previous lawsuits filed against “inaccessible” private company Web sites were settled out of court. Southwest’s case also set a precedent. On October 18, 2002, U.S. District Judge Patricia A. Seitz ruled that the ADA does not apply to the Web.

Access Now and Gumson’s case against Southwest hinged on the assumption that Southwest’s “virtual ticket counter” (Web site) was considered a “place of public accommodation” covered by Title III of the ADA. Judge Seitz interpreted ADA Title III very literally. The statute identifies 12 categories of “places of public accommodation”, all of which mention only physical locations or facilities. She interpreted “places of public accommodation” as physical ones, not “virtual” ones.  The ADA was enacted in 1990, when the Web was young. In her ruling, Seitz asserted, “To expand the ADA to cover ‘virtual’ spaces would be to create new rights without well-defined standards.” ¹ The “well-defined” standards do exist today, for example the U.S. Section 508 Guidelines. However, the ADA preceded these standards and could not take them into account.

I expect the ruling will be appealed or a new, similar lawsuit filed. Even if the case had been ruled in favor of Access Now and Gumson, I would expect an appeal or similar action. The applicability of the ADA to the Internet is far from decided. The case against the Metropolitan Atlanta Rapid Transit Authority’s (MARTA) and their “inaccessible” Web site demonstrates that the ADA might apply to the Web in some instances.

Maybe the ADA Does Cover the Web

Vincent Martin, et al., (three physically disabled individuals), filed a lawsuit against Atlanta’s mass transit system (MARTA) for alleged violations of Title II of the ADA. One portion of their lawsuit focused on the lack of availability of information about bus routes. The MARTA Web site offers current bus schedule information, but it is inaccessible to blind users. Their only alternatives are to call or to request a printed Braille version. Neither of these are equivalent alternatives. It takes over a week to receive the Braille version and the calls only permit inquiries on a specific bus route. Vincent Martin, et al., claimed they could not receive sufficient bus schedule information in a timely manner. Title II of the ADA requires entities that provide a public service to “take appropriate steps to ensure that communications with applicants, participants, and members of the public with disabilities are as effective as communications with others.” ² In this case, the MARTA Web site serves as an auxilliary aid for “effective” communication, and thus Title II of the ADA seems to apply to it.

On October 15, 2002, U.S. District Judge Thomas W. Thrash, Jr. ruled that MARTA had 30 days to address their violations of the ADA. Judge Thrash was not specific about what actions would be taken if MARTA failed to remedy their violations in time. They have been working to make their site accessible, but might not finish by the 30 day deadline. It’ll be interesting to see the outcome of MARTA’s status report in November.

Accountability Online and to Other Web Professionals

More people increasingly use the Web to conduct business, sell products and services, interact with government, learn, and touch the lives of other people. Where people go, rules follow. If the ADA cannot be applied to the Web, then other laws may be created that will cover the Web. Technological advances continue to blur the lines between online and in-person. Laws that currently govern people in face-to-face affairs are being or likely will be applied to the Web. It’s often difficult to translate the intent of the law to appropriately cover technology. Many laws were not designed to take Web technology into consideration. The poorly-worded laws that result can be frustrating to people who understand the technology and work with it daily.

If the people who build Web sites don’t hold themselves accountable to a set of basic standards, then someone else, probably the government, will create standards. (Consider U.S. Section 508 of the Rehabilitation Act, as an example.) Either we can push initiatives and create change from within the industry or we can sit around and wait for someone else to tell us what to do. Self-policing is the best policy. If a peer encourages you to excel, the results are better than if someone forces you to do it. Let’s encourage everyone who works on the Web to create sites built upon sound usability and accessibility practices.

Focus on your users, all of them. Learn from mistakes currently made on the Web. If a user can’t fill out a form, they can’t buy anything from your site. People turned away by unusable sites will probably try a competitor’s site. Don’t be the site that turned people away. Make your Web site as usable and accessible as possible. It’s the business savvy thing to do. It’s the right thing to do. If you don’t, someone just might force you legally to do it or threaten to sue.

Endnotes:

¹ UNITED STATES DISTRICT COURT SOUTHERN DISTRICT OF FLORIDA CASE NO. 02-21734-C1V -SEITZ/BANDSTRA (October 18, 2002) p. 7 (PDF format)

² ADA Regulation for Title II, Subpart E, Section 35.160 General (originally published in the Federal Register, July 26, 1991)

Resources:

W3C HTML Validator:
http://validator.w3.org/

Lynx browser
http://lynx.isc.org/

Lynx Viewer
http://www.delorie.com/web/lynxview.html

A-Prompt (free) accessibility verification software:
http://aprompt.snow.utoronto.ca/

W3C WAI homepage:
http://www.w3.org/WAI/

W3C Web Accessibility Initiative Web Content Accessibility Guidelines 1.0:
http://www.w3.org/TR/WAI-WEBCONTENT/

Section 508 Standards

Related Topics: Accessibility, Usability