Web Accessibility: Solving basic, inaccessibility features
While WCAG 2.0 AA is the current “gold standard” in web accessibility for most organizations, a review of lawsuits indicate that plaintiffs do not sue organizations based on minor inconsistencies with the WCAG 2.0 AA—instead, the analysis above suggests that they tend to sue organizations based on one of three factors.
1. Inherently Inaccessible Web Applications
Complaints against the NBA, Foot Locker and Winn Dixie illustrate that organizations that use websites which rely on inherently inaccessible technology may quickly become the target of an accessible complaint. This makes sense because these technologies entirely block disabled users from accessing the site. Fortunately, most organizations do not use such technologies.
2. Inaccessible Features Block Key Features of a Website
The Netflix and Walt Disney complaints demonstrate that a lawsuit is more likely if a key purpose for visiting a website is defeated by an inaccessible feature.
3. Lack of Basic, Well-Known Accessibility Features
In the majority of cases, however, the key motivator in generating complaints or lawsuits appears to be the lack of basic, easy-to-implement web accessibility features. The lack of these features suggests an indifference to the needs of users with disabilities because these accessibility techniques are well-documented and easy to implement. A refusal to take even the simplest steps towards meeting the needs of users with disabilities could result in a complaint.
Solving basic, inaccessibility features
To avoid facing a complaint, taking steps to solve basic inaccessibility features is essential. They are easy-to-implement and can save an organization a lot of money in legal fees. These accessibility features include:
Alt-Text on Graphics
Failing to provide alt-text on graphic images is perhaps the simplest step that an organization can take to improve its accessibility and reduce the risk of litigation. Adding alt-text in the HTML content for most graphics is illustrated by the following comparison.
|<img src=”p01.gif”>||(inaccessible image)|
|<img src=”p01.gif” alt=”picture of flag”>||(accessible image)|
Labels on Form Controls
Form controls (such as text boxes, check boxes, and radio buttons) are essential to any marketing or e-commerce application. They can also present a bewildering set of unidentifiable controls to a screen reader user, without proper labeling. Here is an example of an inaccessible form element requesting the user to provide their last name.
<input type=”text” name=”lastname”>
The second line (“<input….”) is the code that creates the empty box for the user to type their last name into. Here is the same form element now made accessible.
<label for=”l_name”>Last Name:</label>
<input type=”text” name=”lastname” id=”l_name”>
The “label” tag identifies the text “Last Name:” as a meaningful label for the element with “id=l_ name”—in this case, the input field that immediately follows it.
For more advice on solving basic, inaccessibility features, download the whitepaper on Four Key Issues that Attract Web Accessibility Litigation (And How to Solve Them) for a brief overview of some of the litigation that is driving organizations to take web accessibility seriously. It offers information on additional accessibility violations that almost all complaint letters include and advice on how to solve them.