Last updated on November 14, 2025
I’ve been doing accessibility work long enough that I can confidently say, you cannot avoid lawsuits about accessibility. What you can do is minimize your risk. If you do not have an accessibility effort going on in your company, start one. This guide will help you prioritize where you should be looking first. If you have a program going, this can help focus your efforts into where most lawsuits look first.
I am not an attorney nor do I play one on television. The next are observations made from helping clients with lawsuits and technical advice on how to avoid those pitfalls.
In the beginning…
The first thing to knowing how to get in front of these lawsuits, is to understand how they work. There are two main strategies I’ve run across. These are not the only approaches. But, they are what we’ll focus on today. These techniques cover more than 90% of the cases I’ve reviewed.
Lawsuit Type One
Disability advocates with lived experience act as a “tester” for a class of disabled people. This case will include a list of claims. These are claims the tester encountered. They feel these claims prevent the user from using the site. Many of the claims found will be generated from automatic scans. Yet, there will also be issues that can only be discovered through manual testing.
There was some push back a few years ago about standing in cases like this. The main concern being that the tester does not actually intend to use the company’s products. The challenges in court resulted in confirming this role as an important role and standing is sound.
In the time we’ve applied alternative text to images, an entire generation was born. They grew up and had their own children.
Lawsuit Type Two
This lawsuit type I don’t think anyone will ever admit to. But, with many cases reviewed, most with repeat firms and poorly copied cases, they are real.
What happens is an attorney finds a vertical or group of sites that are somehow related. Maybe high fashion, tech, or use a platform like WordPress or Shopify. They will then set up a tool to run automated scans on all these websites.
With the results in hand, they’ll identify a list of “failures” to put in a claim for each site. These attorneys will then dip into a list of contacts with disabilities, usually blind, and ask to use their name. With the Plaintiff named, they can file the suits. The Plaintiff in this case is not acting as a tester like above. They are acting as if they were the one personally wronged. Beyond the claims, they will conduct a comprehensive automatic scan of your website. They will use tools like WAVE, aXe-core, or Powermapper. This is an intimidation tactic. There may be technical accessibility issues. Nevertheless, I’ve found around 70% have no bearing on the user’s ability to use the product.
Some of the plaintiffs are getting a pay day for doing nothing more than visiting a website once. The average settlement is around $16,000 USD. The lawyers in this type of case usually offer $500 per settlement to the Plaintiff. They keep the rest for their “efforts”. When bundled with 5 or 6 cases, this is a nice little payday. But the lawyers are cautious about overpaying the Plaintiff. They may have Medicare, Medicaid, Social Security Disability Income, or some other financial restriction on their annual earnings.
The Others
There are cases where a specific individual has been irreparably harmed by a site. There is usually significantly more documentation around the harms suffered in these cases. The fixes you need done are the same, but here, your design and development caused actual suffering. This is not a case about equity or equality like Type 1.
“The Carousel region from the website did not comply with necessary accessibility standards. Thus, Plaintiff could not control the moving content on the home page.”
Top Claims
Next, let’s look at what they are claiming.
Images
The number one issue to show up on claims is that images are missing alternative text. This should not be an issue on your site. In the time we’ve applied alternative text to images, an entire generation was born. They grew up and had their own children. This knowledge is ancient in the speed at which tech moves. Any meaningful image must have alternative text reflecting the meaning of the image. Decorative images are hidden using null alt text or aria-hidden. Unless they are provided meaningful SEO based alternative text. I will warn you, many screen reader users dislike SEO content in decorative images.
SVG example
<svg ...> <title>Description of the icon</title>... </svg> <svg aria-label="Description of icon">...</svg>
IMG example
<img src="URL" alt="Alternative text" />
Figure
<figure> <img src="URL" alt="alternative text" /> <figcaption>Longer description and caption</figcaption> </figure>
Picture
<picture>
<source
srcset="/shared-assets/images/examples/surfer.jpg"
media="(orientation: portrait)" />
<img src="/shared-assets/images/examples/painted-hand.jpg" alt="Riding the tube" />
</picture>
Missing labels
The next thing to show up is missing labels. I do like to think of this one as more “missing an accessible name” though. This is because some of the items that are detailed are not actually labels for form controls.
So for anything that requires an accessible name (landmarks, form controls, links, icons, logos) we need to provide one. In most cases this can be added in as HTML. Sometimes you’ll need ARIA.
Form Fields
Form fields are the main focus here. Each input field needs to have a visible, programmatically connected label. This way when the user reaches the field they know what to enter. Additionally, the label element can extend the target area of the field.
<label for="fname">First Name:</label> <input type="text" id="fname" name="firstname" required /> <label for="confirm"> <input type="checkbox" id="confirm" name="confirm" /> I agree to the terms and conditions </label>
Buttons
Buttons also need an accessible name. Most of the time that should be the text in the element. Designers like to offer minimalist buttons with just icons. We can still make them accessible. If using an image, the alt of the image will be the accessible name. If using an SVG, the <title> of the SVG will be the accessible name. If the SVG doesn’t have <title>, then use an aria-label.
There are sites that use icon fonts for this. I understand why, but they create problems in buttons. For one thing, there is no accessible name as the image is loaded in the background. If you use one in the foreground relying on unicode, that is also an issue. Screen reader users hear the unicode, some odd phrasing (if they don’t have the font), or nothing. Speech control users may not recognize the icon thus making it hard to activate.
In these cases, we need to supply off-screen text to fill the gap.
<button type="button">
<i class="icon-font plane"></i>
<span class="visually-hidden">Flights</span>
</button>
.visually-hidden {
position: absolute;
width: 1px;
height: 1px;
margin: -1px;
border: 0;
padding: 0;
outline: transparent;
outline-offset: 0;
white-space: nowrap;
clip-path: inset(100%);
clip: rect(0 0 0 0);
overflow: hidden;
}
Headings
You will see a claim about the misuse of headings. Either that they don’t exist or are out of order. The majority of the time, this will fall under “Not Applicable” but sometimes there may be an issue.
Screen reader users can pull up a list of headings to navigate the page. This would be similar to how a sighted user might skim the headlines of a news site. When those headings don’t exist, they miss out on the scanning of the site. When they are used out of order, screen reader users think information is missing. To prevent this claim, make sure you use semantic headings, in order.
Headings are meant to build an outline of the page. The top level heading explains the page as a whole. If this is the home page, it should explain the site. As content can be divided to add clarity we had the next level of headings. We keep this up until we hit 6 levels of headings.
<h1>Main page Description</h1>
<h2>Section 1 - Why</h2>
<h3>Because I said so</h3>
<h4>I am Authoritay!</h4>
<h2>Section 2 - How</h2>
But here is the fun part. WCAG does not require the use of headings. It simply states to not use implicit headings. Headings that have visual but not programmatic weight are implicit. WCAG declares that a headings visual weight must equal its programmatic weight. It also doesn’t say anything about using the headings in order.
This does mean it is not valid under ADA or WCAG as a violation. Is it wrong? Can we do better? Yes, but there is a big difference between what you should do and what the law says. Right now, we’re focused on what the law says.
Status Messages & Notifications
This applies to everyone, but in my experience, the ecommerce world needs to pay the most attention here. If something visually changes on the page due to the user’s interactions, you must inform the user. Let’s break down some examples.
Add to cart – the user just indicated they wanted to buy a product. Make sure to send a message to an aria-live region announcing the product, by name, was successfully added.
Search – the user performed a search, let them know how many results were returned. If it is a type ahead variant, announce the result count when they pause typing.
Character counters – the user wants to email you via the contact form and you have a size restriction. Let the user know as they run out of words or characters. Don’t announce all of them, but at reasonable levels. On first focus what the restriction is. I then favor to announce every 100 words or characters until we hit 100 left. Then we do 50, 25, 10, and then per letter or word.
Dialogs
Dialogs, modals, and interstitials often appear in claims. When done “well”, they are awful. Especially email sign up and cookie banners.
When a dialog or modal appear from a user action, focus needs to move into the dialog. The recommendations on where focus lands is debated in the community, but is limited to three places:
- The dialog element with an aria-labelledby pointing to the heading
- The first actionable item in the dialog, usually a close button
- The heading itself
If you place focus on the dialog element it will read out the whole contents. If the dialog needs the user to confirm something, avoid placing them on a control to cancel. This why I don’t like focus landing on close buttons. In my opinion the close button should be last in the tab order. We’ll discuss that another day.
Still, dialogs and modals are being used a lot more and they aren’t user triggered. Cookie banners are a prime example. They are usually hosted by a third party and load slightly after the page. Because of this minor delay, the screen reader user may have already started navigating the page. When the banner loads, it steals focus so it can be read. This is very confusing for screen reader users. And if the dialog is implemented wrong, they can’t easily escape.
Broken Links
One in every three cases I see, broken links are listed as a claim. Broken links SUCK. As a good site owner, you should curate links regularly. Anyone encountering broken links will be frustrated if they activate them.
Here is an important tidbit though. WCAG says nothing about broken links. Because a broken link can’t be discriminatory. It doesn’t matter if I use a keyboard, mouse, switch, or eye tracking. It doesn’t matter if I can see the screen or not. It won’t work.
Checkout
Just like adding a product to the cart, any changes to the interface during the checkout need to be communicated. Checkouts get flagged for missing status messages, error messages not connected to fields, and buttons missing clear labels. Quantity and remove buttons often lack the product name. This makes it difficult for the user to know which product they are editing.
Not applicable
In most cases, you will find some claims that are very frustrating to users. Yet, the issue is not related to ADA or WCAG. It falls outside the scope of those rules. Broken links are the premiere example. But there are others. Hopefully, you saw the pull quote about carousels? Yeah, that’s real. And it is the good example.
“The Carousel region from the website did not comply with necessary accessibility standards. Thus, Plaintiff could not control the moving content on the home page.” It’s claiming the carousel doesn’t follow the standards for navigating. Most of the time, this claim is worded, “The carousel doesn’t meet the WCAG criteria for carousels.”
What are the requirements for a carousel according to WCAG? Well, there are none. WCAG doesn’t define a carousel. It tells us if something is moving more than 5 seconds add a way to pause it. It tells us how to make buttons. It tells us how to make lists. It tells how to make navigation. It tells us what should be announced when new content is added to the screen. All these pieces are needed to build an accessible carousel. However, the carousel itself is not a defined element with WCAG specified compliance rules.
Getting ahead
If you haven’t been sued and you don’t have an accessibility team working on the items above, take immediate action. Get someone to address these issues yesterday. Make sure these are clean and you can avoid most lawsuits. If you are doing business in Europe, you’re already late. If you only deal in the USA, April is your new target for new laws that will increase lawsuits.
And while you are working on these items, find someone you can partner with for your accessibility auditing and remediation. This will help you stay ahead.
The last piece I want to leave you with is crucial. Ensure you have an attorney on your counsel. Make sure they are familiar with disability law. It doesn’t matter if they are internal or external. I’m not looking to shame any lawyers. Nonetheless, disability law is very different than civil and corporate law. This distinction is important in a lot of cases.
What are your thoughts on how to prevent accessibility lawsuits? Come chat with me on BlueSky and LinkedIn!