What gets sued: A field guide to the UI patterns behind 6,666 accessibility complaints

The header is the first interactive surface on every page, and the hamburger button is often the first thing a keyboard user reaches. When that button is rendered as a <div> with a CSS background image, has no accessible name, or expands a menu that traps focus or fails to communicate its open/closed state, the entire site becomes structurally inoperable from the keyboard before the user has touched any actual content.

The skip link is the companion failure. A working "Skip to main content" link is a five-line fix, but it is also the single most efficient screen for whether a development team has accessibility on their checklist at all. Complaints frequently cite both in the same paragraph, because a missing or broken skip link is the canary — if the team didn’t ship a skip link, they almost certainly didn’t ship aria-expanded states either.

Render the menu trigger as a real <button> with a visible or screen-reader-only text label and a managed aria-expanded attribute. Provide a "Skip to main content" link that becomes visible on focus and lands inside the <main> landmark. Make sure focus enters the menu when it opens, returns to the trigger when it closes, and that Esc dismisses the menu.

Search is rebuilt as a custom component on most large sites — a debounced text input that fires a request on every keystroke and renders a floating list of suggestions inside an absolutely-positioned <div>. The text input itself is usually fine. The suggestion list almost never is. It is rendered outside the input’s DOM context, has no role="listbox", no aria-activedescendant, and no live-region announcement when results appear. A screen-reader user types, hears nothing, hits Enter, and gets a results page they did not know was waiting.

The same architecture pattern recurs in faceted-search filter panels and in the results-list itself: keyboard-focusable elements that are visually present but never announced. Complaints about search are rarely about the search box; they are about everything that appears after the user types.

Use the established WAI-ARIA Combobox pattern: role="combobox" on the input with aria-expanded, aria-controls, and aria-activedescendant wired to a role="listbox" of suggestions. Add a polite live region that announces result counts. Make sure the suggestion list is reachable with the down-arrow key, not just the mouse.

The PLP grid concentrates several anti-patterns into one screen. Each tile is typically a clickable card with three or four interactive children — image link, title link, color swatches, quick-add button — wrapped in another link to the product page. The result is nested interactive elements (an HTML error), redundant link text (“Hero Dash Three Graphic Image Link” repeating four times), and color swatches built from <div> elements with click handlers but no role and no name.

The filter sidebar adds a second category of failure. Filter facets are usually checkbox lists, but built with custom div-and-span elements styled to look like checkboxes, with the actual <input> hidden offscreen. When that hidden input loses its association — through a CSS rule, a JavaScript event handler that swallows space-key presses, or a missing for attribute on the visible label — the filter becomes operable by mouse only.

Use one anchor per tile with descriptive text, not three links per product. Render swatches as real <button> elements inside a role="radiogroup". Build filter facets on actual <input type="checkbox"> elements with associated <label> tags; style the inputs visibly rather than hiding them. Announce filter changes with a polite live region.

The product detail page is where a screen-reader user must make several specific choices in the right order: pick a color, pick a size, set a quantity, then add to cart. Every one of those choices is implemented in modern eCommerce as a custom widget — usually a horizontal row of <button>-shaped <div>s for sizes, color tiles built from CSS-styled divs, and a numeric stepper made from two icon buttons flanking an input. The increase and decrease buttons are routinely shipped with no accessible name; complaints describe them as announced as “button, button” with no indication of what they do.

Size guides and size charts are a separate sub-failure: they almost always live behind a “Size Chart” link that opens a modal, and the link itself frequently has no label, the modal frequently has no announced title, and the table inside frequently has no row or column headers.

Use real form controls. Color swatches and size selectors should be a role="radiogroup" of role="radio" buttons (or actual radio inputs styled invisibly), each with an accessible name like “Size: Medium”. The quantity stepper should be a labeled number input with paired increment / decrement buttons whose accessible names include the action and the current quantity. Wrap the entire selection block in a fieldset with a legend.

Add-to-Cart is the most-tested moment in any eCommerce funnel and one of the most consistently broken for assistive-tech users. The pattern is mechanical: a visitor presses the button, a small confirmation toast or mini-cart drawer appears for two or three seconds, and the cart icon updates a count badge in the header. Sighted users see all three signals. Screen-reader users typically receive zero. The toast renders outside any live region, the drawer appears without focus management, and the cart-count change is delivered as plain DOM mutation that no screen reader will announce.

The result is a button that, from the user’s perspective, does nothing. They press it, they hear nothing, they assume it failed, they press it again. Some complaints describe pressing the button five or six times before realizing the cart had silently accumulated five or six items.

Wrap the cart-status region in aria-live="polite" and update its text on every successful add. If the design uses a confirmation drawer, move focus to the drawer when it opens and return focus to the original button when it closes. Update the cart-count badge with a screen-reader-only announcement like “1 item added. Cart total: 3 items.”

Icon-only controls fail in a predictable way: the visible content is an SVG or icon-font glyph, the accessible content is empty, and screen-reader output collapses to the element’s structural role with no name. The cart icon ends up announced as “link” or “collapsed”; the chat bubble as “button”; the row of social icons in the footer as “link, link, link, link, link”. The user has no way to know what any of them do.

Cart icons fail more often than other icons for an architectural reason: many implementations render the cart count inside the icon’s accessible name (e.g., the icon shows “0” inside the SVG), and the screen reader picks up only the digit. Complaints describe the cart icon being announced as “3, link” or “0, link”, with no indication that “3” refers to a quantity in a shopping cart.

Every icon-only control needs an accessible name. Add an aria-label on the button or wrap a visually-hidden text label inside it: "Shopping cart, 3 items". Avoid putting count digits inside the icon’s accessible name without context. For decorative icons that sit alongside visible text, use aria-hidden="true" on the icon and let the text carry the label.

Checkout concentrates more compliance risk per square pixel than any other page on a commerce site, and the pattern of failure is dense. Address dropdowns rendered as custom <div> components that ignore the space key. Required-field markers shown only as a red asterisk, with no aria-required and no programmatic association. Inline error messages painted in red text below the field, with no aria-describedby linking the field to the error and no live-region announcement when validation fails. The user fills in the form, presses “Continue,” is silently bounced back, and has no way to know which fields failed or why.

The same complaint language recurs across hundreds of cases: error message is not announced, error messages are vague, cannot enter billing information. These are not isolated bugs. They are the default behavior of most commerce checkout components shipped without explicit accessibility work.

Use real <label> elements associated to inputs by for/id. Mark required fields with aria-required="true" and indicate requirement in visible text, not just color. On validation failure, render the error message inside the input’s aria-describedby target, give the failing field aria-invalid="true", and move keyboard focus to the first invalid field. Provide a summary error region at the top of the form with anchor links to each failing field.

The payment block is unusual because it is often delivered by an embedded third-party iframe — Stripe Elements, Braintree Hosted Fields, an Adyen drop-in. Inside the iframe, the payment vendor’s own form is usually well-labeled. But the moment a site builds its own card capture, or wraps the embedded fields in custom layout that overrides the labels with visual placeholders, the four fields — number, expiration, CVV, postal code — become a row of blank inputs to a screen reader.

The CVV field is the most consistently mislabeled because designers commonly replace its label with a question-mark icon that opens a tooltip explaining what a CVV is. The tooltip is not the label; the field still needs a programmatic name. When it doesn’t have one, the screen reader announces the entire payment block as “edit, edit, edit, edit” and the transaction stops.

If using a third-party hosted-fields integration, follow the vendor’s accessibility guidance — most provide a documented way to label fields from outside the iframe. If building custom card capture, every input needs a real <label> element with a visible text label, plus autocomplete="cc-number" / cc-exp" / cc-csc" attributes so password managers and assistive tech can identify the fields by purpose.

The cart page repeats the PDP quantity-stepper failure but at higher stakes: a screen-reader user who cannot operate the stepper cannot complete the order. The “Remove” control is its own anti-pattern — it is usually a small × icon next to each line item, often with no visible text, no aria-label, and no announcement when the row is removed. The user presses what they hope is the remove button, the row disappears, and the screen reader stays silent. There is no way to confirm the action succeeded.

Several complaints describe a related failure mode: the cart’s running total updates dynamically when quantities change or items are removed, but the new total is rendered as ordinary DOM text outside any live region, so the user has no idea what they will be charged.

Each line item should expose a labeled remove button (e.g., "Remove Blue T-Shirt, size M, from cart"). Quantity steppers should announce their current value as part of the accessible name or via paired live-region updates. The cart subtotal should sit inside an aria-live="polite" region so changes are announced. Confirm removals with an undo affordance.

This is the single largest category in the dataset because it is the lowest-cost issue to detect and the highest-cost issue to ignore. A screen reader walks the DOM, hits an <input>, and reads its accessible name — which it computes from, in order: aria-labelledby, aria-label, an associated <label for>, the title attribute, or the placeholder. If none of those exist, the screen reader announces only the role: “edit box” or “edit, blank.” That phrase, almost verbatim, recurs in hundreds of complaint records.

The reason it is so common is structural. Modern design systems frequently render placeholder text inside the input as a stand-in for the visible label, and developers assume the placeholder is doing the labeling work. It isn’t. The placeholder disappears when the user types, leaves no programmatic name, and renders the field unusable for anyone who arrives at it later in the flow or returns to it after an error.

Every interactive control gets a visible label, programmatically associated. <label for="email">Email</label><input id="email" type="email"> is the canonical pattern. Placeholders are supplementary hints, not substitutes. For controls where a visible label is genuinely undesirable (search boxes, icon buttons), use aria-label with descriptive text — never with the placeholder duplicated.

The phrase “not announced or given focus” appears verbatim in over 400 complaint entries and is one of the most replicated sentences in the entire dataset. It describes a specific failure mode: a modal or dialog appears on the page (often automatically — newsletter signup, age gate, location confirmation), the visible content shifts, but the screen reader is given no signal that anything has changed. Focus remains on the underlying page. The user continues tabbing through whatever was beneath the modal, completely unaware that a blocking dialog has appeared.

This is the textbook case of a modal that fails on every dimension simultaneously: no role="dialog", no aria-modal="true", no programmatic focus shift on open, no focus trap while open, no Esc-to-close behavior, no announced title. Because all of these failures travel together, fixing any one of them in isolation does not move the case meter.

Use an established dialog pattern (the WAI-ARIA Authoring Practices spec is the reference). On open: move focus to the first focusable element inside the dialog, set aria-modal="true" and role="dialog", label the dialog with aria-labelledby pointing to its heading. While open: trap focus within the dialog. On close: return focus to the element that triggered it. Honor the Esc key. If the modal interrupts a flow (e.g., autoplaying on page load), give the user a single mechanism to dismiss it permanently.

Focus indicators are usually killed deliberately, by a developer or designer who saw the default browser outline as visual noise and wrote *:focus { outline: none; } into a global stylesheet. The page now looks cleaner to a sighted mouse user. To a sighted keyboard user — including most low-vision users, motor-impaired users, and users navigating without a mouse — the page becomes unusable. The user can press Tab, but they cannot see where they are.

This is one of the few failure modes that is visible without any assistive technology. A QA reviewer who tabs through the home page once, with no other tooling, will spot it in under a minute. That accessibility teams find it consistently in litigated sites, while internal review missed it, is one of the most reliable signals in the dataset that the site has no keyboard-testing pass at all.

Never blanket-disable :focus outlines without a replacement. Provide a visible focus style — typically a 2-3px outline with sufficient contrast against both the element and its background — using :focus-visible so the indicator appears for keyboard navigation but not for mouse clicks. Verify it on every interactive component, including custom widgets, links inside cards, and elements with tabindex.

The logo is the most-visited image on a website and one of the most consistently broken. It typically lives in a link that wraps it back to the homepage, but the image is shipped with no alt, no aria-label on the link, and no surrounding text. The screen reader announces only “link”, with no information about where it goes. Multiply by every page on the site.

The wider category — images without alt text — covers banner art, product photos, hero illustrations, social-icon glyphs, and the vast catalog of marketing imagery a typical commerce site ships. Complaints in this category often cite specific image filenames, indicating that the plaintiff’s expert ran an automated check that listed every image whose alt attribute was missing or empty when it should have been descriptive.

Logos should carry alt text describing the company name and, if the logo links somewhere, the destination — alt="Acme Co. — homepage". Decorative images get an empty alt attribute (alt=""), which deliberately hides them from assistive tech. Informative images get descriptive alt text. Avoid auto-generating alt text from filenames or AI captioning without human review; complaint records repeatedly cite cases where overlay tools captioned a company logo as “a blue and yellow sign.”

Screen readers expose a “list of links” view, used heavily by experienced users to scan a page in seconds. That view shows only the link text, divorced from its surrounding paragraph. A page where every blog teaser ends in “Read more” renders to that view as fifteen identical entries. A page with five empty links — <a href="..."></a>, common when icons are inside link wrappers without any text fallback — renders five blanks.

The fix is well-known and the failure is well-known, which is why this pattern keeps appearing in complaints — its persistence indicates a development process with no automated linter for link text and no manual screen-reader pass.

Every link must have an accessible name describing its destination or action. Replace generic phrases with descriptive ones — “Read more” becomes “Read more about Q3 earnings”. For icon-only links, add visually-hidden text or an aria-label. Run an automated check (axe, Lighthouse, etc.) for empty <a> elements during CI.

Video appears in complaints in two patterns. The first is the obvious one: a marketing video, product demo, or explainer ships without captions, transcript, or any text alternative — and a Deaf or hard-of-hearing visitor cannot access the content. The second is more subtle: a hero video that autoplays on page load, which interferes with screen-reader output and violates pause/stop controls expected at WCAG 2.2 AA level (per SC 2.2.2 Pause, Stop, Hide for moving content and SC 1.4.2 for any audio).

Some complaints in this dataset assert that “Lack of closed captions on website videos are a violation of the ADA,” framed as a legal conclusion. Whether that framing holds varies by jurisdiction and circumstance; what is more durable is that these videos consistently fail WCAG 2.2 AA, the standard most courts and settlement agreements treat as the operative compliance benchmark.

Provide synchronized captions for all pre-recorded video with audio. Provide a text transcript as well; transcripts are useful for users on muted devices, in low-bandwidth environments, and for indexing. Avoid autoplay; if autoplay is required for design reasons, provide a pause/stop control immediately reachable by keyboard. For video-only content (no audio), provide an audio description or text alternative.

Sign-in is the gatekeeper for the entire authenticated experience. When the form fails, every page behind it becomes unreachable, and complaints frequently treat that cascade as a single barrier. The pattern is the same form-labeling failure as E·01, often combined with three specific sub-failures: a “Show password” toggle implemented as an icon-only button with no name and no announcement of state change, a CAPTCHA that defeats screen-reader use entirely, and inline errors (“invalid credentials”) that are painted on screen but not announced.

The “remember me” checkbox is an additional recurring sub-failure: rendered as a styled <div>, with the actual <input> hidden offscreen, the checkbox is operable by mouse but not by keyboard or screen reader. The user has no way to opt into a persistent session.

Use real <input>, <label>, and <button> elements. Make the show/hide-password toggle a real button with an accessible name that updates with state ("Show password" / "Hide password") and announce the change with aria-pressed. Provide an accessible alternative to image-based CAPTCHAs (audio CAPTCHA, or — preferably — replace CAPTCHA with risk-based authentication or hCaptcha’s accessible variants).

Screen readers expose the page through three navigation modes: by heading, by landmark, and by link. A page that ships without an <h1>, without <main>, <nav>, and <footer> landmarks, and without a lang="en" attribute on the <html> element, has stripped out all three of those navigation modes simultaneously. Users have no way to scan, no way to jump to content, and no way for the screen reader to load the right pronunciation engine.

This is an unusually generative failure: a single missing landmark causes a downstream cascade of complaints because every screen-reader navigation strategy that depends on it now fails. Complaints in this category typically list four or five specific structural problems together, presented as evidence that the site has no semantic baseline.

Every page gets one and only one <h1>, with subheadings (<h2>, <h3>) nested logically. Wrap regions in HTML5 landmark elements: <header>, <nav>, <main>, <aside>, <footer>. Set lang on the root <html> element. Validate with an outline checker or run document.querySelectorAll('h1').length === 1 as a smoke test in CI.

Most accessibility QA is done on desktop browsers with NVDA or JAWS. Mobile assistive tech — VoiceOver on iOS, TalkBack on Android — exposes a different rendering of the same DOM, frequently with different bugs. Complaints repeatedly use the abbreviation “mobile SRU” (mobile screen-reader user) to flag failures that are unique to the mobile view: a hamburger menu that works with NVDA on desktop but is silent under VoiceOver, an Apple Pay button that is reachable on a laptop but not on the iPhone equivalent of the page, error messages that announce on desktop but not on mobile.

The dataset suggests that defendants whose desktop accessibility is otherwise solid are still being sued on mobile-specific issues. Mobile parity is its own audit pass.

Test with VoiceOver on iOS Safari and TalkBack on Android Chrome at minimum, on the same flows that desktop QA covers. Pay particular attention to gesture-based interactions, native payment buttons, and form-field announcement on focus. If a native app exists, run it through the same audit — complaints frequently cover both web and app under the same case.

The accessibility overlay is the only exhibit in this catalog where the failure is not in the underlying site at all — it is in the supposed remediation layer that was added to fix it. Complaints in this category describe two distinct harms. The first is that overlays do not actually fix underlying barriers, so the user encounters the same broken modals, mislabeled forms, and unannounced errors regardless of whether the widget is present. The second is more pointed: overlays sometimes introduce new failures by injecting incorrect labels, mis-applying ARIA roles, or interfering with the user’s own assistive tech configuration.

One detail worth noting: complaints in 2024 and 2025 increasingly cite the overlay vendor by name. Two specific complaint passages identify UserWay and AccessiBe in unambiguous language, and recent FTC actions have created an explicit risk that adding an overlay is itself evidence of a failure to do real remediation work — rather than a defense against litigation.

Treat overlays as a flag, not a fix. If one is currently deployed, plan a real-remediation roadmap that addresses underlying code rather than masking it. The well-tested path is some combination of: an automated scanner integrated in CI, a human audit pass against WCAG 2.2 AA, manual testing with at least one screen reader and keyboard-only navigation, and ongoing accessibility QA in the design and engineering process.