A customer sued over a button.
Not a shopping cart page. Not a checkout flow. Not a broken video player buried three clicks deep in a support section nobody visits. A single icon-only button, sitting quietly in the header or the product grid, that a screen reader could not name.
We are not going to point at one specific lawsuit here and pretend we have the filing open on the desk in front of us. We do not need to. This is a composite of a pattern we see often enough that the brand, the industry, and the customer's name barely matter anymore. Swap all three out and the button is still the same button: an icon, no visible text, no aria-label, and a screen reader with nothing to say except one flat word.
"Button."
That is the whole case. That is the whole story. And that is exactly why it should make you a little uneasy.
The Stat: WCAG Success Criterion 4.1.2, Name, Role, Value, requires that every UI component have a programmatically determinable name. An icon-only button with no
aria-label, visible text, or equivalent mechanism announces to a screen reader as just "button," with no indication of what it does. (Source: W3C, Understanding WCAG 4.1.2)
Why "Just a Button" Becomes a Federal Complaint
Here is the part that surprises people who have not spent time in accessibility work: the legal exposure almost never comes from something dramatic. It comes from WCAG 4.1.2 Name, Role, Value, a Level A criterion, meaning it sits at the most basic tier of conformance, the tier a site is expected to meet before anyone even talks about "good" accessibility.
The rule itself is simple. Every interactive control on a page, every button, link, and form field, has to expose a name that assistive technology can read and announce. A sighted user glances at an icon and infers "that's the cart" or "that closes the dialog" from context, shape, and placement. A screen reader user gets none of that. They get whatever the code tells the browser to expose, and nothing more.
When a developer drops an SVG icon inside a <button> tag and ships it without a name, the code is not broken in any way a browser will complain about. It renders. It looks fine. It works perfectly for a mouse. It is also, for a meaningful percentage of your visitors, functionally invisible.
What the Customer Actually Heard
Picture the moment. A customer using a screen reader is trying to add an item to their cart. They tab through the page, and their assistive technology arrives at a control and announces exactly one word: "button." Not "add to cart, button." Not "shopping bag, button." Just "button."
Is it the add-to-cart icon? Is it a wishlist toggle? Is it something that opens a modal, submits a form, or deletes their account? There is no way to know without guessing, clicking, and hoping the consequences are reversible. Multiply that single button by the handful of unlabeled icons that show up on a typical product page, hamburger menus, search icons, close buttons on modals, and a customer isn't dealing with one moment of confusion. They are dealing with a site that has quietly opted them out of shopping there.
That is not a hypothetical inconvenience. It is the exact, specific, well-documented failure mode that Level A of WCAG exists to prevent, and it is the failure mode that keeps showing up in complaints.
The Pattern Behind the Filing
This is not a rare or exotic problem. UsableNet's ADA web accessibility lawsuit tracking documents that federal ADA Title III web accessibility lawsuit filings have remained in the thousands per year, with common storefront failures, including unlabeled buttons and controls, recurring across a large share of the complaints.
That detail matters more than any single case ever could. Lawsuits over accessibility are not built around exotic edge cases that only a specialist could anticipate. They are built, again and again, around the same small set of well-known, well-documented, entirely preventable gaps. If you want to understand why the volume keeps climbing rather than leveling off, read the wider lawsuit-volume trend we've covered before, and the throughline is the same one you're reading right now: the failures are basic, and basic failures are the easiest ones to find, the easiest ones to reproduce, and the easiest ones to cite in a complaint.
The Fix Nobody Shipped
Here is the part that should actually sting a little. The fix for an unlabeled icon button is not a redesign. It is not a sprint. It is not a conversation with legal or a meeting with three stakeholders. It is one attribute.
<button aria-label="Add to cart">
<svg/>
</button>
That's it. aria-label="Add to cart" gives the exact same visual button a name that assistive technology can announce. No layout changes. No visual difference for sighted users. No new dependency, no design review, no QA cycle beyond a quick screen reader check. A competent developer can find and fix one of these in minutes. Fixing all of them across a site takes an afternoon, not a quarter.
That gap, between "minutes to fix" and "expensive to ignore," is the entire story this article is telling.
What This Actually Costs You
| Unlabeled button | Labeled button | |
|---|---|---|
| Screen reader announcement | "button" | "Add to cart, button" |
| Customer can complete task | Guesswork, often abandoned | Immediate, confident |
| Engineering effort to fix | N/A (not yet identified) | One aria-label attribute |
| WCAG conformance | Fails 4.1.2 (Level A) | Passes 4.1.2 |
| Legal exposure | Sits in the pattern lawsuits target | Removed from the pattern |
| Time to remediate once found | Minutes | Already shipped |
A Five-Minute Audit You Can Run Today
You do not need a full accessibility program to start closing this gap. You need five minutes and a willingness to look.
- List every icon-only button on your homepage, product pages, cart, and checkout flow.
- For each one, check the rendered HTML for an
aria-label,aria-labelledby, or visible text alongside the icon. - Turn on a screen reader (VoiceOver on Mac, NVDA on Windows) and tab through the page, listening for any control that just says "button" with nothing else.
- Fix each gap with a specific, human-readable label describing what the control does, not what it looks like.
- Repeat the check after any redesign, since icon-only buttons have a way of quietly reappearing.
The Soft Part
None of this requires a lawsuit to matter. It requires someone deciding to look before, instead of after. If you would rather have a second set of eyes go looking for the buttons that could not tell your customers what they do, you can find your own unlabeled buttons before a lawsuit does with a free accessibility audit that checks for exactly this pattern, and the handful of others just like it, before anyone else finds them for you.