By Paul Harris in Accessibility on June 5, 2019.
Some of my clients have recently asked me if their websites are ADA (Americans with Disabilities Act) compliant. They are active members of networking groups in their industries and have heard stories of accessibility litigation launched against group members.
While I have read nothing conclusive as to the extent to which the ADA laws strictly apply to website accessibility, the writing is on the wall. There are plenty of examples of websites being sued over ADA issues, and it stands to reason that in a litigious society both lawyers and individuals stand to gain financially by challenging the ADA legality of websites.
So that simple question, “Is my site ADA complaint,” deserves an explanation beyond just a simple yes. The The World Wide Web Consortium (W3C) accessibility guidelines (WCAG), which are the model for ADA compliance1, are often obscure to an ordinary front-end web developer like myself.
The ADA became law in 1990, long before people used the internet and multiple access points as they do today. It prohibits discrimination on the basis of disability in the activities of public accommodations, which are enumerated businesses open to the public. That discrimination prohibition is keeping up with the times and in the case of my business applies to website accessibility.
Clearly nowadays it is incumbent on technology providers to stick to ADA requirements. In my case, that’s the way I build websites and implement preexisting tools and technology platforms despite the fact websites are often a complex mix of technologies beyond my control.
For example WordPress, which some of my clients use, includes third-party theme files which may introduce elements that are not necessarily accessibility compliant. In their defense, developers of web software are aware of the requirements and do, from what I can see, attempt to comply. My advice is to test themes and prebuilt websites to ensure they are compliant.
Here are the basic accessibility criteria to keep in mind:
Of course, there is a lot more to it according to W3C WCAG, and I suggest you read them (WCAG).2
If you work on sites for federal agencies you should also be familiar with Section 508 of the Workforce Rehabilitation Act which also applies to accessibility. “Section 508 of the Rehabilitation Act (29 U.S.C. § 794d), as amended by the Workforce Investment Act of 1998 (P.L. 105-220) requires federal agencies to develop, procure, maintain and use information and communications technology (ICT) that is accessible to people with disabilities – regardless of whether or not they work for the federal government. The US Access Board established the Section 508 standards that implement the law and provides the requirements for accessibility.”3
So how should you check for accessibility? Apart from knowing the rules and applying those in a site build, there are tools available to help identify problem accessibility areas.
I use http://wave.webaim.org/ from https://webaim.org/. Although it can only check one page at a time, there is a more powerful paid option available. My sites are small enough to use the free option. I just check each page.
Another tool I use all the time comes from Google, and it is called Lighthouse4 an open source automated tool for improving web page quality. You can run it against any web page, public or requiring authentication. It is more than just an accessibility tool and has audits for performance, accessibility, progressive web apps, and more.
You can run Lighthouse against any page in Chrome DevTools, from the command line, or as a Node module.
Sources: