The ADA Checklist: Website Compliance Guidelines for 2019 in Plain English
(This article was last updated June 26, 2020.)
- 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
- Super easy WCAG 2.0 AA checklist is near the middle of this article
- Don’t fall for automated accessibility/compliance scams (cheaper prices but worthless widgets)
- There are no automatic or instant solutions (e.g. toolbars, overlays, widgets, plugins, apps) for website accessibility — caveat emptor
- Be careful of purchasing accessibility audits (sometimes priced as high as a few thousand dollars) that are free automated scan results in a fancy PDF
- Digital marketing agencies are claiming ADA Compliance expertise to boost revenue but most know little about accessibility
Critical Legal Points:
- Plaintiffs’ lawyers continue to file ADA and parallel state (California and New York) lawsuits as fast as they can in 2020
- 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 less than 15 employees doesn’t save you from ADA Compliance
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 $8,000+.)
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.
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.
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.
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 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.
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.
Also, ask yourself the following two questions:
- What is the primary purpose of my website?
- 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/practically 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.
I know, I know — even scrolling through my lightning list felt too long.
This is a project and it does take some time but, I promise, it is doable.
Of course, the above bullets are 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.
My 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?
WCAG 2.1 is basically 2.0 + 12 more bullet points to take care of.
The W3C’s Web Accessibility Initiative (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.
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 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 for free (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.
#4 Expensive Subscriptions Are a Waste of Money
There are a handful of accessibility vendors that really want to hook you on an expensive subscription.
Typically you’ll see 24/7 monitoring and/or support being sold.
You don’t need this — even if you’re constantly posting new content.
The only way this would even be mildly useful is if you were constantly redeveloping and redesigning your website but, even then, remember that automated scans only catch 1/3 of accessibility issues.
There are so many bloated contracts out there you just don’t need.
What accessibility companies don’t want you to know is most of the cost is a one-time deal.
Pay up front for an audit and remediation (whether it’s your dev team or an external one) and you’ve got 90% of this done.
The only continuing costs that are worthy of consideration are interval audits (annual or biannual) and accessibility training.
#4 Budget Friendly
There’s no reason to blow your accessibility budget allocation on an overpriced vendor.
A client of mine recently told me he was pitched on a six-figure price tag after he sat through a 30 minute PowerPoint.
Some agencies are hyper inflating their prices so beware of that when you get pitched.
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.
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
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.
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.
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.
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):
Read more of my articles on Web Accessibility and ADA Compliance: