The ADA Checklist: Website

Compliance Guidelines for 2019 in

Plain English
Kris Rivenburgh

Kris Rivenburgh (me) researches ADA Website Compliance and web accessibility continually.

(This article was last updated April 16, 2020.)

Quick Overview:

Title III of the Americans with Disabilities Act (ADA) is being interpreted
to include websites as “places of public accommodation”
Websites with significant inaccessible components can be seen as
discriminatory against persons with disabilities, in violation of Title III of
the ADA
The ADA is a strict liability law which means there are no
excuses/defenses for violations (e.g. ignorance, web developer is
working on it, etc.)
No current legal prescription exists for web accessibility for private
entities in the U.S. but WCAG 2.0 AA is frequently referenced by courts
Plaintiffs’ lawyers continue to file ADA and parallel state (California and
New York) lawsuits as fast as they can in 2020
There are no 100% automatic or instant solutions (e.g. toolbars,
widgets, plugins) for website accessibility — caveat emptor
Towards the middle of this article is a super easy WCAG 2.0 AA
checklist

Well here we are.

You’re over there trying to figure this stuff out so you don’t get sued. And
I’m over here writing at 4:40 am because I can’t sleep.

Okay, for the record I did watch Bill Burr on Netflix before this but that’s
besides the point.

Anyway, let’s quickly make ADA Website Compliance easy on you so a wild
pack of opportunistic lawyers doesn’t make a paper airplane demand letter
and float it on over to your desk.

(Author’s note: I highly recommend you make it to the end of this article. It’s
kinda long but the next 12 minutes could very well save you $7,700+.)

Don’t let their friendly faces fool you, they’ll sink your battleship with one tiny letter.

Before I start, let’s clear up two terms that are closely intertwined but
distinct: ADA website compliance vs. website accessibility.

The law that primarily governs accessibility in the U.S. is the Americans with
Disabilities Act (ADA). Even though it doesn’t mention websites anywhere,
Title III of the ADA has been interpreted by U.S. courts to apply to websites.

(And, no, you don’t need 15 employees to fall under the ADA.)

For our websites to be ADA compliant, they need to be accessible.

Website accessibility can mean two things depending on the context: 1) the
process of making your website so that its content and functions are
accessible to those with disabilities, or 2) how accessible your website is.

Think of it this way:

The ADA is the legal side, are you in compliance with the law? And
accessibility is the technical or developmental side, how well can persons
with disabilities access your website?

The next question is: how do we make our websites accessible?

The answer is to make it so that everyone, including persons with
disabilities, can enjoy the “full and equal” use of your website; they can
access content, navigate your website successfully, engage with different
elements, etc.

The buzz phrase you’ll see commonly laced in plaintiff’s lawsuits is

“effective communication” — does your website provide effective
communication?

U.S. courts and the Department of Justice (DOJ) have continually

referenced the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA
success criteria as the standard to gauge whether websites are accessible.

The WCAG 2.0 AA success criteria are comprised of 38 requirements

(including level A), individually referred to as success criterion.

George H.W. Bush signed the ADA on July 26, 1990. There’s no way it contemplated websites.

If your website meets all 38 of those success criteria, you’re in great shape.
But, even if you don’t, your website can still be accessible.

We’ll talk more about some of the crucial to-dos a little further down the
page.

For now, let’s talk about the most important thing you can do to avoid that
sinking feeling of receiving a threatening legal letter in your mailbox.

Take Action!

The first thing you need to do is do something.

That’s always my professional legal advice (yes, I’m an attorney too but the
good kind).

So you need to do something. What does that even mean though?

That means don’t turn website accessibility into a huge bureaucratic project
where associate interns are reporting back to senior interns who shuffle a
bunch of papers and then your social media guy gets involved for some
reason and nothing gets done.

Instead of the pretend-to-get-stuff-done maneuvering above, start by

diving into WCAG 2.0 AA and taking care of the biggest obstacles to
accessibility and most common lawsuit complaints.

If you start feeling overwhelmed with WCAG documentation, get my WCAG

2.0 AA guide for free by subscribing to Accessible.org.

What is Legally Required?

WCAG is not the law but it is the most frequently referenced set of technical standards.

WCAG is not the law but it is a very helpful technical reference.

Because there is no explicit web accessibility law for private entities in the
United States (and nothing is expected in 2020 or 2021), there is no exact
answer as to what is required.

However, if you read through any lawsuits or past DOJ Title III website
actions, you know that the best practice is to bring your website in
conformance with WCAG 2.0 AA.

But…

It isn’t always clear whether your website meets certain success criteria.

WCAG is a technical guide and both the wording and what is being asked
can be hazy or outright difficult to understand. Moreover, it may be tough
for you to know exactly how to apply certain success criteria to your unique
website.
What I recommend is trying your best to meet as many of the WCAG
success criteria as best you can.

After that, ask yourself the following two questions:

1. What is the primary purpose of my website?

2. What are the common paths that visitors take once they’re on my
website?

You want to make absolutely sure both the primary purpose and common
paths are clear of any barriers that could potentially prevent access or
cause frustration.

The good news — if you find yourself defending a claim — is private entities
have a good amount of flexibility when it comes to web accessibility.

Assistant Attorney General, Stephen E. Boyd, stated in a letter of Congress

that entities (individuals, businesses, companies, organizations, etc.) have
flexibility in how to comply with web accessibility.

Absent the adoption of specific technical requirements for websites

through rulemaking, public accommodations have flexibility in how to
comply with the ADA’s general requirements

The Section508.gov blog says the same thing:

Until the DOJ adopts specific technical requirements for web

accessibility in a final rule, if you’re subject to the ADA, you have more
flexibility in determining how to make your website compliant with the
ADA’s general requirements of nondiscrimination and effective
communication.

The Ninth Circuit Court has also expressly stated we have flexibility in
accessibility:
 the ADA and its implementing regulations are intended to give public
accommodations maximum flexibility in meeting the statute’s
requirements

This floating reprieve is certainly welcome as making a website accessible

has its challenges.

What the flexibility language is acknowledging is that although WCAG is

currently the best solution for determining whether a website is accessible,
it’s an imperfect standard.

First, WCAG is a difficult document to get through. It’s long, hard to read,
and at times difficult to know whether you’ve met the guidelines.

Another potential problem is you might not end up meeting all of WCAG 2.0
AA (even if you make your website minimally accessible).

At the very least, the above flexibility language gives you a potential ace in
the hole if you get hailed into court despite having made a strong, good
faith effort.

That said, it’s best if you can check off every last WCAG success criteria. To
help you out, I’ve created a skeleton outline for WCAG 2.0 AA below.

Note 1: Many, many details and exceptions are left out for the sake of
brevity.

Note 2: The section headings were made up by me to describe the following

bullet points and break up the text.

WCAG 2.0 AA
Section 1: Alternatives

Alt text (1.1.1): All images and non-text content needs alt text (there are
 exceptions)
Video & Audio alternatives (1.2.1): All video-only and audio-only
content has a text transcript. Transcripts are clearly labeled and linked
below the media.
Closed captioning (1.2.2): All video with sound contains accurate
closed captioning.
Audio description (1.2.3): For any video, add an alternative video that
includes an audio description of information not presented in the
original video’s soundtrack (exceptions) or include a text .
Live captions (1.2.4): Any live video presentations must have closed
captions.
Audio description (1.2.5): An audio description is optional under 1.2.3
level A but not in 1.2.5 AA.

Section 2: Presentation

Website structure (1.3.1): Use proper markup techniques to structure

your website’s content (e.g. use correct heading tags and HTML for
ordered and unordered lists)
Meaningful order (1.3.2): Present content in a meaningful order and
sequence so that it reads properly.
Sensory characteristics (1.3.3): When providing detailed instructions,
make it so they aren’t reliant on a single sensory ability.
Use of color (1.4.1): Do not rely on color alone to convey information.
Audio control (1.4.2): Any audio must be able to be paused, stopped, or
muted.
Color contrast (1.4.3): There must be a color contrast ratio of at least
4.5:1 between all text and background.
Text resize (1.4.4): Text must be able to be resized up to 200% without
negatively affecting the ability to read content or use functions.
Images of text (1.4.5): Do not use images of text unless necessary (e.g.
logo).
Section 3: User Control

Keyboard only (2.1.1): All content and functions on a website must be

accessible by keyboard only (i.e. no mouse).
No keyboard trap (2.1.2): Keyboard-only users must never get stuck on
any part of the website; they must be able to navigate forwards and
backwards.
Adjustable time (2.2.1): If there any time limits on a website, users have
the ability to turn it off, adjust it, extend it.
Pause, stop, hide (2.2.2): If there is content that blinks, scrolls, moves,
users must have the ability to pause, stop, or hide it.
Three flashes or below (2.3.1): Web pages do not contain anything that
flashes more than three times in any one second period.
Skip navigation link (2.4.1): A “Skip to Content” or “Skip Navigation”
link allows users to bypass the heading and go straight to the main
content.

Section 4: Understandable

Page titles (2.4.2): Each page of a website needs to have a unique and
descriptive page title.
Focus order (2.4.3): Users must be able to navigate through a website
in a logical sequential order that preserves meaning.
Link anchor text (2.4.4): The purpose of each link should be clear
based on its anchor text (e.g. don’t use “click here”)
Multiple ways (2.4.5): There are multiple ways to access different
pages/information on a website (e.g. search bar, nav menus, sitemap,
breadcrumbs, helpful links after content).
Descriptive headings and labels (2.4.6): Headings and programmatic
labels must be clear and descriptive. They do not need to be lengthy.
Focus indicator (2.4.7): Any “user interface control” that receives focus
from a keyboard user should indicate that focus on the current
selected element (e.g. add a visible border around a text link).
 Website language (3.1.1): Set the language for your website.
Language changes (3.1.2): Indicate any language changes for an entire
page or within the content.

Section 5: Predictability

No focus change (3.2.1): Nothing changes merely because an item

receives focus; a user must actively choose to activate an item (e.g. hit
enter to submit) before a change takes place.
No input change (3.2.2): Nothing changes just because information is
inputted into a field (e.g. form doesn’t auto submit once all fields are
filled out).
Consistent navigation (3.2.3): Keep navigation layout consistent
throughout all pages of the website (e.g. same links in the same order).
Consistent identification (3.2.4): Components that have the same
function within a website are identified consistently (but not
necessarily identically) (e.g. two check marks can indicate two different
things as long as their function is different — one indicates “approved”
on one page but “included” on another).
Error identification (3.3.1): Make any form errors easy to identify,
understand, and correct.
Form labels and instructions (3.3.2): Programmatically label all form or
input fields so that a user knows what input and what format is
expected.
Error suggestions (3.3.3): If an input error is automatically detected,
then suggestions for correcting the error should be provided.
Error prevention on important forms (3.3.4): For pages that create legal
commitments or financial transactions or any other important data
submissions, one of the following is true: 1) submissions are reversible,
2) the user has an opportunity to correct errors, and 3) confirmation is
available that allows an opportunity to review and correct before
submission.
Parsing (4.1.1): Make sure HTML code is clean and free of errors,
 particularly missing bracket closes. Also, make sure all HTML elements
are properly nested.
Name, role, value (4.1.2): For all user interface components (including
forms, links, components generated by scripts), the name, role, and
value should all be able to be programmatically determined; make sure
components are compatible with assistive technology.

Of course, this is just a quick outline. I’ve created an expanded WCAG in

Plain English guide that goes into more detail. If you would like to get this for
free, you can subscribe to Accessible.org and I’ll email you the guide
within 24 hours.

This guide is written in as simple terms as humanly possible so you can

better understand what to do for each of the bullet points above.

WCAG 2.1 AA
You may have heard about WCAG 2.1 AA.

What’s the deal here?

All WCAG 2.1 is is an updated version of 2.0 with 12 more bullet points to
take care of.

The WAI added in some stuff to help mobile accessibility and then things
they wished they had put in 2.0.

The good news is nothing in 2.0 AA has been undone so you’ll always want
to start there anyway.

You’re in great shape if you have 2.0 AA conformance and if you’re able to
take it to the next level with 2.1, that’s dynamite.

Read my WCAG 2.0 vs. 2.1 article where I fully breakdown how to view
each.

Subscribe to Accessible.org and you’ll get both my 2.0 AA and 2.1 AA

plain English guides for free.

Alright, you’ve earned a 15 minute break just by getting this far down the page.

Okay, you definitely earned that victory lap you just took around the office
by getting through the 8-minute informational gauntlet above but let’s not
get ahead of ourselves here, you’ve got at least another 20 minutes of hard
labor to finish off this whole “make-your-website-accessible” project.

Some quick notes:

#1 Legal Best Practices

There is a separate set of legal best practices to ADA compliance as well:

training, having a web accessibility policy page, making a web accessibility
statement, appointing an accessibility coordinator, hiring an independent
consultant, and inviting feedback.

For smaller businesses, you’ll likely go without the coordinator and

consultant formalities above due to budget constraints, but the bigger you
are, the more thorough I recommend you become with your approach to
web accessibility.

#2 Don’t Fall for Instant Gimmicks

Don’t waste your money buying any automatic solution to making your
website accessible.

Automatic solutions are any quick installs where you get a clickable toolbar
on your website. They’re usually referred to as toolbars, overlays, widgets,
plugins, or apps.
I die a little inside every time someone emails me after buying one and asks
what I think.

These things are absolutely garbage and don’t actually make your website
accessible.

And plaintiffs’ lawyers are starting to sue websites that are using them.

A lot of people thought they would be safe using one but they’re not at all.

I posit that they actually put you at higher risk.

Read my article on why overlays are dead.

#3 Don’t Pay for Automated Scans

The way you get started with accessibility is typically you 1) audit and then
2) remediate your website.

Be extremely careful who you hire.

I’ve had clients who pay $1,500 and get a fancy PDF that contains issues
that were found using only free automated scans.

Anyone can easily use the WAVE and AXE accessibility browser extensions
(these are good automated accessibility checkers that give you a feel for
where you stand) — you don’t need to hire someone to run these for you.

Another good automated tool is Tenon.io. This one is premium and gives
you more of a technical deep dive.

Automated scans or audits only tell 1/3 of the accessibility story so you
can’t solely rely on them. Automated checks can be helpful but are limited
to being supplemental guides that point you in the right direction.

To get a complete picture of your website’s accessibility, you need an

accessibility expert to manually review your site. Many agencies won’t offer
manual audits because it takes several hours and real effort and (GULP!)
potential liability.

The main point here is if you are looking for a DFY (Done For You) solution,
be careful that you aren’t just getting an automated scan — make sure
you’re getting a comprehensive manual audit.

Parallel State Lawsuits

By far, the most ADA Website Compliance litigation comes from California,
New York, and Florida.

Let’s focus on California and New York because their state courts have seen
a surge in web accessibility lawsuits.

Why?

In a nutshell, California and New York have their own state versions of the
Americans with Disabilities Act (Unruh Act in California and New York
Human Rights Law in New York) which act essentially the same as the ADA
but provide for more damages to plaintiffs.

So the same thing is happening as with the ADA (taking advantage of a

loophole in the law) but now it’s not only happening in federal court but
state court too.

Again, your best move is to make your website accessible ASAP.

You can get dinged from so many angles by so many different plaintiffs.

What to do next

I wrote the book on this stuff. No, really, it’s called The ADA Book.
The most common complaint in demand letters and lawsuits is a very easy
one to fix: alt text.

I call alt text a gateway complaint because it’s easy for plaintiff’s lawyers to
spot and, then, once they have it, they’ll pile on as many other items as they
can find to make you look bad and increase their settlement amount.

To fix alt text, just change the value of your alt attribute to convey the
meaning of an image.

This fix amounts to editing your code so that you include a text description
of what images are.

Another big ticket item is having closed captioning on your videos. If you
have your videos hosted on YouTube, adding closed captions is fairly easy
to do.

Right off the bat, these are two very simple yet very big steps towards
becoming accessible/ADA compliant.

Here are four other critical items:

Making your website fully usable by keyboard only (you can unplug the
mouse and still fully use the website)
Coding in labels for form fields (you program your forms so that the
field labels such as “first name” are read by screen readers)
Using descriptive anchor text for links (you write links so that someone
can tell what the linked page is about — not “click here” or “learn
more” but “donate to the XYZ dog rescue” or “specs on the new
iPhone 11 Pro Max”)
Structuring your headings (e.g. h1, h2) so that they are correctly
nested

Remember, updating your website to become ADA compliant is a process,

not a flip of a switch so the best way to become compliant is to start doing
what you can and not get caught in planning and procrastination mode.

ADA website compliance lawsuits are being filed like crazy right now. 2018
was a record year for number of lawsuits filed, 2019 eclipsed 2018, and
2020 is very likely going to set another record (look out for a surge in state
lawsuits including Unruh Act lawsuits in California and Human Rights Law
lawsuits in New York).

The answer to preventing a lawsuit is easy: make your website accessible;

the solution, however, is not (especially because many of the supposed
providers don’t actually offer remediation).

The Supreme Court declined to review Domino’s web accessibility case.

And while you figure out your plan of action and are in the process of
making your website accessible, you might get hit by a demand letter or
lawsuit.

Settlements on ADA website compliance typically range from $10,000 to

$50,000.

Remember, the best course of action is to attack website accessibility now.

Do not wait on this or it could cost you.

And here’s the kicker: if you do get hit with a demand letter and end up
settling, you still have to make your website accessible.

Want another kicker? Just because you’re sued once doesn’t mean you
can’t get sued again by someone else (this is actually very common —
many companies have already had this happen).

How about a third kicker on your fantasy football team? Here it is: the
Americans with Disabilities Act is a strict liability law which means there are
no excuses to non-compliance (even though I’d say there’s a good one in
there not being a federal law for private entities).
Working diligently on your accessibility but still missing a few things? Too
bad, you lose. Pay up.

Hired a reputable web development agency last week? Too bad, you lose.
Pay up.

Just heard website accessibility was a thing yesterday? Too bad, you lose.
Pay up.

The above three examples are an oversimplification of the actual process

but they drive home my point: Strict liability means the only saving grace is
compliance which means your website is currently a sitting duck as-is.

Corporations and small businesses alike are being targeted.

Obviously deep pockets are a target but you may wonder why small
businesses are also pursued. It’s because they’re easy wins and can’t afford
to put up much of a fight.

Get started as soon as possible. Remediating your current website will take
some time.

If you do get sued, if you immediately remediate your website, you may be
able to get the lawsuit dismissed on mootness (there’s no longer anything in
dispute, i.e. plaintiffs are arguing your website is inaccessible but you’ve
already made it accessible). This definitely does not mean you should wait
to fix your website but it does mean you may have an out if you’re up for
playing defense to a lawsuit.

Accessible Theme is a Wordpress theme that I personally designed and

developed with the help of an expert web developer.

It addresses web accessibility at the code level and is a great way for
information websites, blogs, and other sites to quickly and affordably
become accessible.

It has 0 WAVE (popular automated scan used by plaintiffs’ lawyers) errors

out of the box.

You can buy it at AccessibleTheme.com.

Get my WCAG checklists and sign up to get my plain English guide on what
all of WCAG 2.0 AA + 2.1 AA success criteria actually mean (free):

Sign up free at Accessible.org

Read more of my articles on Web Accessibility and ADA Compliance:

Lowering your risk of a demand letter

Why accessibility toolbars/widgets/plugins aren’t compliant

Does every website need to be ADA compliant? (Yes)

Cheapest options for making your website accessible

Web Accessibility for Beginners