ADA Compliance for Websites in Plain English

Kris Rivenburgh standing in business center lobby.
Kris Rivenburgh (me) researches ADA Website Compliance and web accessibility continually.

The most popular ADA website compliance questions:

What does ADA compliant mean for websites?

Your website provides full and equal access, effective communication, and/or meaningful access. In terms of preventing litigation, WCAG 2.1 AA conformance is best practice.

Does my website need to be ADA compliant?

Very likely, yes — especially if it’s commercial in nature.

How do I know if my website is ADA compliant?

Although not definitive, the best practices for ADA compliance are 1) full WCAG 2.1 AA conformance and 2) publishing an accessibility statement.

ADA website compliance essentially comes down to 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 lawsuits from plaintiffs’ law firms.

I’ve provided the simple solution for you: WCAG conformance.

But what I haven’t done yet is unravel the ball of tangled hangers that is ADA compliance and digital accessibility.

There’s a lot for you to think about including:

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

This article is long and probably boring.

Super important, yes, but most people (and the stats show this) weren’t ready for the informational gauntlet of ADA compliance and digital accessibility when they clicked on this article.

If you’re in a hurry, you can instantly download my free ADA website compliance kit from Accessible.org:

  • WCAG 2.1 AA Checklist
  • WCAG 2.1 AA Guide
  • Accessibility Statement Template

All three documents are free at Accessible.org.

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 creator of Kris’s WCAG 2.1 AA Checklist and Guide.

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

  • law
  • WCAG
  • overlay widgets
  • automatic scans
  • accessibility audits
  • demand letters and lawsuits
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 don’t make things accessible, then you’re discriminating against those with disabilities.

Even though it doesn’t mention websites anywhere, Title III of the ADA has been overwhelmingly been interpreted by the Department of Justice (DOJ) and U.S. courts to apply to websites.

Websites and mobile apps are now considered “places of public accommodation”.

Basically — and I really do mean basically — what this means is if you have a website and there’s anything remotely commercial about it (i.e., money is involved), you’re a potential target for plaintiffs’ law firms.

What causes plaintiffs’ lawyer to initiate litigation?

Sometimes just the mere fact that you have a website.

But, for the plaintiff’s lawyers who actually look, they’re looking for any technical ways your website doesn’t meet 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.0 AA and WCAG 2.1 AA are the referenced technical standards (from the DOJ and courts) and plaintiffs’ lawyers seek out any number of technicalities where a website could conceivably have an accessibility issue (e.g., a redundant 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 solely in plaintiffs’ lawyers hands, they frequently opt for litigation. If they sue you or send you a demand letter, you lose time, money, and mental energy.

While this doesn’t mean you technically violated the law, it has the effect of a loss.

Supreme Court building
Supreme Court building
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 and effective communication to those with disabilities.

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.

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

I’m going to guess that it’s about now that you’re starting to realize that you’re in for more than you bargained for…

I’ve got four more legal bullet points and then we’ll call it a day for the legal section.

Sure, there are bucketfuls of information I could serve up but you’ve got the point.

Legal bullet points

  • 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.)
  • Parallel state court lawsuits alleging violation of state anti-discrimination laws (Unruh Act in California and New York Human Rights Law in New York) have become extremely popular because they’re essentially the same as the ADA but provide for more damages to plaintiffs.
  • Fair Housing Act and other anti-discrimination laws are also being used to sue website owners and target specific industries (e.g., FHA for real estate)
  • 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)
Source code of a website.
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 with 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.

So all this means is 2.1 AA conformance just adds 12 more things to 2.0 AA (50–38=12).

I call 2.0 the classic standard and 2.1 is the current 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 mid 2021.)

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

Two big accessibility items that I constantly see in lawsuits are 1) missing alt text and 2) missing labels.

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.

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): 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.

I know, I know — even scrolling through my lightning list felt too long.

Website accessibility is a project and it does take some time but, I promise, it is doable.

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

What I recommend is trying your best to meet as many of the WCAG success criteria as best you can.

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.

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 a magical widget that can instantly make your website accessible / ADA compliant by injecting 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.

The way it works is they get you to paste some code into your website and a menu widget with an array of supposed “accessibility” options will be available.

Before we even get to the non-accessibility of these #worthlesswidgets, you’re taking on huge security and privacy risks by injecting this code into your website.

Now, getting to the accessibility part, these widgets don’t make your website’s code or content accessible / WCAG conformant.

Instead, you get a JavaScript menu that lays over (hence, “overlay”) your website once activated.

The menu is largely redundant with screen reader options.

Activating the menu 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

A widget is also a separate and unequal experience which is a violation of the ADA.

Think about it, why would one person have to go through a separate toolbar 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:

  • Automatic website accessibility
  • Instant website accessibility
  • Instant ADA compliance
  • Effortless ADA compliance
  • Fully automated solution
  • Install a single line of JavaScript
  • Install a simple plugin
  • Easy toolbar or app for accessibility
  • 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.

Real accessibility takes genuine time and manual effort.

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

P.S. Yes, websites with overlays from a variety of vendors have received lawsuits.

P.P.S. Forbes: Largest U.S. Blind Advocacy Group Bans Web Accessibility Overlay Giant AccessiBe

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

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 a ruse.

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

A scan is a useful accessibility tool that can identify a handful of accessibility issues that can automatically be flagged.

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.

Scans work as a series of rules that are if-then statements.

For example, if an image has no alt attribute, then show an alt text error.

But, in this example, we still need to manually determine whether the image is decorative or meaningful and, if meaningful, what a good concise, descriptive alt text value would be.

And thus, scans are only a small part of the accessibility picture.

They’re helpful but limited.

Single page scans are free with WAVE or Axe.

Multiple page scans (e.g., to scan your entire website at once) will cost but prices are very fair.

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?

An audit is a formal evaluation performed by an accessibility expert 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.

There are many digital marketing agencies (I highly advise against having an SEO/social media company handle your accessibility) and even some accessibility agencies who attempt to pass off a scan as an audit.

A good accessibility audit from a reputable provider will be in the 4 or 5-figure range for most websites.

Professional man and woman in business suits with fake smiles at desk with laptop and gavel on it.
Professional man and woman in business suits with fake smiles at desk with laptop and gavel on it.
Don’t let their friendly faces fool you, they’ll sink your battleship with one tiny letter.

COVID-19 only slowed lawsuit filings for a few months in 2020.

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

But what we do know is that a cottage industry around digital accessibility litigation has formed and is here to stay for the foreseeable future.

Of significance is that there has been a surge in state lawsuits including Unruh Act lawsuits in California and Human Rights Law lawsuits in New York.

So even if you hear that ADA website accessibility cases have gone down, this doesn’t speak to the number of state-filed cases since the ADA is a federal claim.

The answer to reducing risk of litigation is easy: make your website or mobile app accessible; the solution, however, is not, and takes time.

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 in ADA website compliance cases typically range from $3,000 to $25,000+ depending on the size of the entity.

The best course of action is to get started as soon as possible. Auditing and remediating your current website can take multiple months to complete.

And here’s the kicker: if you do get hit with a demand letter before you’ve made your website accessible 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.

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.

I talk to people who have been sued or received demand letters on a daily basis.

From mom bloggers and small motels in tiny towns to the biggest corporations in the world, all sizes of entities are the target of litigation.

Attorney. Author of The ADA Book (I swear I’ll re-publish it on Amazon by 2022). https://Accessible.org founder.