ADA Compliance for Websites in Plain English

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

(Updated for 2023)

ADA Website Compliance Summary

• The ADA has generally been interpreted by courts to apply to websites
• The DOJ’s stance is that the ADA does apply to websites
• WCAG 2.1 AA conformance and posting an accessibility statement are best practices for material compliance
• There are no automatic or instant “solutions” for website accessibility
• An audit and remediation are necessary to make your website and content accessible

Common Questions

What does ADA compliant mean for websites?

The legal standard under the Americans with Disabilities Act is meaningful access. In terms of preventing litigation, WCAG 2.1 AA conformance is best practice.

Does my website need to be ADA compliant?

Generally, yes — especially if it’s commercial in nature. Private litigation is driving enforcement of the ADA against digital assets, and the DOJ has reaffirmed its stance that the ADA applies to websites of businesses open to the public or “public accommodations”. However, circuit and state courts vary in how they apply the ADA to websites.

Defendants have a great technical argument (there is no explicit law that mandates digital accessibility for private entities), but the cost of defense can be extremely high and there is no guarantee of winning since the ADA has been liberally construed in many courts.

Because plaintiffs’ lawyers don’t mind litigating and the cost to defend is so high, practically, you need to make your website accessible to be compliant with the ADA.

How do I know if my website is ADA compliant?

The best practices for ADA compliance are 1) full WCAG 2.1 AA conformance and 2) publishing an accessibility statement which includes at least one method of contact for support and a means of providing feedback.

[Transcript]

Overview

The best practice making your website compliant with the ADA is making your website conformant with the WCAG 2.1 AA technical standards.

Translation: You have a to-do checklist of 50 accessibility things to account for on your website, app, etc. to be more or less practically compliant with the ADA (i.e., you shouldn’t receive a demand letter / lawsuit if you do these things).

That’s not the law — there actually is no law for private entities in the U.S. that mandates web accessibility — but that’s the practical effect of early DOJ actions, court rulings in recent years, and floods of demand letters and complaints from plaintiffs’ law firms.

As you continue to research, you’ll likely have concerns related to the following:

• WCAG — what is it?
• overlay widgets — why are they worthless?
• automated scans — how much do they catch?
• accessibility audits — do you need one?
• demand letters and lawsuits — how to prevent them?

I’ll touch on each bullet point in this article.

If you’re in a hurry, you can instantly download my WCAG 2.1 AA checklist and guide for free at Accessible.org.

Also, I highly, highly recommend you read my book, The ADA Book.

Oh, and just in case you’re wondering who you’re getting this info from…

My name is Kris Rivenburgh.

I’m an attorney, the author of The ADA Book, and the founder of Accessible.org.

Okay, that’s enough intro, let’s touch on each of the following topics one-by-one so you can dazzle everyone at your next cocktail party.

The Law

George H. Bush signed the ADA in 1990.

The law that primarily governs accessibility in the U.S. is the Americans with Disabilities Act (ADA).

The gist of the ADA is if you can’t discriminate based on disability so you need to make things accessible.

Even though it doesn’t mention websites anywhere, Title III of the ADA has been overwhelmingly been interpreted by the Department of Justice (DOJ) to apply to websites. U.S. courts have mostly held the same way, but courts are uneven in how and when they apply the ADA.

What causes plaintiffs’ lawyer to initiate litigation?

Plaintiffs’ lawyers look for ways your website or web content can arguably be inaccessible, usually by way of technical accessibility issues per WCAG.

If your website isn’t fully WCAG conformant, does this mean you’re in violation of the ADA?

No, again, there is no current formal legal prescription for web accessibility for private entities in the United States.

As it stands now, WCAG 2.1 AA are the technical standards the DOJ and courts reference as a guide for how to make your website compliant (full conformance is mandated when the DOJ enters into a settlement or a court rules against a defendant).

As mentioned above, plaintiffs’ lawyers seek out any number of technicalities where a website could conceivably have an accessibility issue (e.g., there is no skip navigation link).

(Note that the significance of different accessibility issues varies based on issue type and the number of issues. Some are minor inconveniences while others prevent or significantly hinder access.)

With the discretion to litigate in plaintiffs’ lawyers hands, they almost always opt for litigation. If they sue you or send you a demand letter, while this doesn’t mean you technically violated the law, it has the effect of a loss.

The Supreme Court declined to review the Robles vs. Dominoes case.

When we examine Title III of the ADA, since it doesn’t speak directly to websites or mobile apps, we have to go by the broad language of the statute which requires:

the full and equal enjoyment of the goods, services, facilities, privileges, advantages, or accommodations of any place of public accommodation

So the technically correct legal 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.

Restated, generally, we have to make sure our websites provide for meaningful access to those with disabilities.

U.S. courts and the Department of Justice (DOJ) have continually referenced the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA success criteria as a technical standard to gauge whether websites are accessible.

But, just because our website doesn’t fully meet a WCAG success criterion doesn’t mean we’re in violation of the ADA.

For example, let’s say my text color contrast ratio is 4.4:1 and doesn’t meet the 4.5:1 guideline set in WCAG, does that mean I’m violating the ADA?

No.

Here are some quotes from authoritative sources on this:

Assistant Attorney General, Stephen E. Boyd, stated in a letter to 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 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

Here are four more relevant legal bullet points:

Legal bullet points

• The ADA is essential a strict liability law which means there are no excuses/defenses for violations (e.g., ignorance, web developer is working on it, etc.)
• Parallel state court lawsuits alleging violation of state anti-discrimination laws (Unruh Civil Rights Act in California and New York Human Rights Laws in New York and New York City) have become extremely popular because they’re similar to the ADA (in that they prohibit discrimination based on disability) but provide for more damages to plaintiffs.
• Other anti-discrimination laws are also being used to sue website owners and target specific industries (e.g., FHA claims rose at one point)
• Having fewer than 15 employees doesn’t exempt you from ADA compliance as a place of public accommodation (Title I is what you’re thinking of, it’s for employers)

WCAG

Now we’re getting into the technical stuff.

The ADA is the legal side — are you in compliance with the law?

But what about WCAG?

Think of WCAG as the technical side: do you conform to the technical standards?

WCAG is not the law. It may be incorporated into the law — and already has in many territories — but it’s not the law.

WCAG stands for the Web Content Accessibility Guidelines.

These guidelines are published by the World Wide Web Consortium (W3C) under their Web Accessibility Initiative (WAI).

In a nutshell, the W3C publishes standards to make the web more uniform and run better; if we’re all using the same accessibility guidelines, it makes things better in many ways.

There are different versions (1.0, 2.0, 2.1) and conformance levels (A, AA, AAA) for WCAG but let’s keep things simple and focus in on the two that matter most to you:

• WCAG 2.0 AA
• WCAG 2.1 AA

2.0 AA has 38 success criteria.

2.1 AA has 50 success criteria.

Think of success criteria as bullet points or things to do to make your website more accessible.

What’s great to know is that 2.1 AA includes all of 2.0 AA.

This means 2.1 AA conformance adds 12 more things to 2.0 AA (50–38=12).

I call 2.0 the classic standard and 2.1 is the present standard. 2.0 was published in 2008 so it’s missing some key mobile accessibility issues.

(Note that 2.2 is the future standard - it’s release is expected in late 2022, but don’t let the 2.2 release disrupt you, focus on 2.1.)

Keep in mind that some of these 50 to-dos are much more critical than others (both in terms of accessibility and legal risk).

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

Part of the problem with WCAG is that it’s extremely technical, long, and difficult for anyone to read which makes it that much more difficult to make a website or mobile app accessible.

Here’s the WCAG source documentation. Nobody wants any part of reading that.

To help get you started, I’ve included a WCAG 2.0 AA checklist below.

Note 1: Many, many key 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 Checklist

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 with relevant information not conveyed by audio, add an audio description of information conveyed visually or include a text transcript.
• Live captions (1.2.4): Any more formal, live 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 header / navigation menu 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): 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.

You can get my WCAG 2.1 AA checklist and full WCAG 2.1 AA Guide for free at Accessible.org (no subscription required).

Overlay Widgets

[Transcript]

By now I’m sure you’ve seen some vendors claiming instant accessibility.

These guys claim, in some form or fashion, that they have an automated “solution”, magical widget that can instantly make your website accessible / ADA compliant by pasting JavaScript code into your website.

This is an outright lie.

These vendors are taking advantage of the confusion and ambiguity of the current situation to sell worthless widgets.

(Because of this, numerous website owner / operators have still been sued for discriminating on the basis of disability. Plaintiffs’ lawyers disregard these automated widgets.)

To be clear, there are absolutely no automated “solutions” that can make your website accessible / WCAG conformant. This is because nothing can actually remediate your code or content.

And, no, the claimed artifical intelligence or AI does not remediate anything. What the AI is referencing is basic image recognition software that is a part of the widget. Image recognition software at best generically describes an image and at worst provides a wholly inaccurate or misleading description.

Also, the menu settings are largely redundant with already existing assistive technology and/or browser capabilities (e.g., read text, zoom, enlarge text, color changes, etc.).

Activating the overlaymenu forces someone into a different experience that they likely do not want for a variety of reasons:

• users don’t want to learn how to use the widget
• users don’t want to decide what options to choose
• the options don’t behave like they’re supposed to
• the options don’t make the website accessible
• the widget conflicts with their assistive technology
• users don’t want to disclose their disability

Relying upon an accessibility widget also creates a separate and unequal experience which is a violation of the ADA.

Think about it, why would one person have to go through a widget to access a website when everyone else can simply access the website?

And, beyond all of this, even if we assumed that the widget didn’t have these problems, it still doesn’t make your website accessible.

And it doesn’t take into account all disabilities.

Accessibility professionals have repeatedly and routinely denounced overlay widgets.

Here are some claims or slogans that signal you’re dealing with an overlay:

• Solution for web accessibility
• Instant website accessibility
• Instant ADA compliance
• Fully automated solution
• Install a single line of JavaScript
• Install a simple plugin
• Leading artificial intelligence
• AI powered

If it seems like you’re being a sold an instant fix to website accessibility, you’re on the wrong path.

There are none.

There’s a reason none of the established, reputable companies never claim instant accessibility.

Automated Scans

Website accessibility scans give the ability to flag about 20-25% of WCAG 2.1 AA success criteria for further review.

Some of the issues flagged are more conclusive while others are only a partial catch (e.g., 50% of a success criterion is able to be automatically flagged).

It’s important to understand that overlays and scans are two completely different things.

Scans are useful. Overlays are garbage.

An overlay claims that it can instantly make your website accessible.

A scan is a useful accessibility tool that can detect a handful of accessibility issues.

Scans are helpful but very limited.

A scan saves time and reduces human error in catching accessibility issues but there’s only so much automation can catch.

And even on the issues that can be caught with a scan, it’s important to know that they still require a manual review.

Single page scans are usually free. I recommend using the WAVE tool.

Note: Logically, if the best scans on the market can only catch 25% of issues — not fix but catch — how can there be a software (i.e., an overlay) that not only catches but even fixes most, if not all, accessibility issues?

Accessibility Audits

An audit is a formal evaluation performed by an accessibility professional who manually evaluates and tests a website against WCAG 2.0 AA or 2.1 AA.

Once an audit is completed, a report is delivered to the client detailing all of the accessibility issues for a given scope (e.g., the primary 15 layouts of a website or 10 screens of an app).

The key here is that the audit is conducted manually.

Demand Letters and Lawsuits

[Transcript]

I predict that we will see a decrease in “ADA website” complaints / lawsuits filed in 2023. This is because courts in California and New York are finally starting to realize many plaintiffs’ lawyers are abusing the legal system (vs. having legitimate complaints).

However, while the number of complaints filed has already decreased, it hasn’t stopped.

And we don’t know about demand letters because those don’t go on public record.

So while I’m confident litigation will decrease, there is still a significant amount of litigation — enough to constitute a real legal risk.

Settlements in “ADA website” cases typically range from $3,000 to $25,000.

The best course of action to prevent litigation is to get started remediating accessibility issues as soon as possible.

Also, 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.

Read The ADA Book (affiliate link) to understand the legal and practical digital accessibility landscape.

Go to The ADA Book YouTube channel to watch me answer FAQ about ADA compliance and website accessibility.