The 10 Most Common WCAG Violations [35M-Issue Data]

Last updated: November 9, 2026

The most common WCAG violation is low-contrast text, found on 83.9% of the top one million home pages in 2026. It leads a list of ten recurring failures documented here: WebAIM's public prevalence data for the six that show up in any home-page scan, and TestParty's remediation experience for four more that dominate ecommerce templates a home-page crawl never reaches.

Key numbers: 95.9% of the top one million home pages carried at least one detectable WCAG failure in 2026, averaging 56.1 errors per page — both worse than 2025 (WebAIM Million, 2026). Six failure types account for 96% of every error WebAIM's scanners detect (WebAIM Million, 2026). As of 2026, TestParty has remediated 35 million-plus accessibility issues across 100+ brands; that scale informs the ecommerce-specific violations below, contributed as qualitative pattern, not as a rival percentage.

How were these 10 violations ranked?

Two sources rank this list, and they are kept deliberately separate: WebAIM's public prevalence data ranks violations 1–6, and TestParty's remediation experience across ecommerce templates surfaces violations 7–10.

WebAIM's Million is an automated scan of one million home pages, run against criteria a script can evaluate from the rendered DOM alone — contrast ratios, an `alt` attribute's presence, whether an input has a label. That method is precise and structurally blind to anything requiring doing something: tabbing a menu, closing a modal, waiting for a filter to update. Those failures don't rank low in WebAIM's data — they don't appear at all, since a home-page crawl was never built to trigger them. The bracketed "35M-issue" figure in this article's title is TestParty's own remediated-issue count as of 2026, cited for scale, not as a rival set of percentages; every prevalence number below is WebAIM's, attributed as such. For the full 55-criterion list either source draws from, see our WCAG 2.2 AA breakdown and checklist.

What are WebAIM's six most common WCAG violations?

WebAIM's 2026 crawl of one million home pages found the same six failure types that have topped this list for years, led by low-contrast text at 83.9% — and four of the six got worse compared to 2025.

1. Low-contrast text — 1.4.3 Contrast (Minimum), Level AA. Body text, placeholder text, or text over images below the required 4.5:1 ratio (3:1 for large text). It's the most common violation because colors ship from a design system built for aesthetics, then get reused across every template before anyone runs a checker. For low-vision and older users, and anyone outdoors on a phone, the result is text that can't be read rather than merely annoying. Fix at the [token](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html), not the element — `color: #767676;` (3.5:1, fails) becomes `color: #595959;` (7:1, passes) on white.

2. Missing image alt text — 1.1.1 Non-text Content, Level A. Images with no `alt` attribute at all, or a decorative image without an empty one. It's common because bulk product uploads and CMS imports rarely force the field, and "the image loaded fine" reads as "done" to whoever shipped it. A screen reader user hears the filename, or nothing, where a sighted shopper sees the product. Fix: `<img src="dress.jpg" alt="Navy wrap dress, front view">` for content; `<img src="divider.svg" alt="">` for anything purely decorative.

3. Missing form labels — 3.3.2 Labels or Instructions (A) / 1.3.1 Info and Relationships (A). An input with placeholder text standing in for a label, or no label at all. It's common because placeholder-as-label looks identical to the real thing until the field is focused and the hint vanishes. A screen reader user, or anyone who forgets what a field was for mid-type, loses the instruction entirely. Fix: `<label for="email">Email</label><input id="email" type="email">` — a placeholder is a hint, never a substitute.

4. Empty links — 2.4.4 Link Purpose (In Context), Level A. An `<a>` with no accessible text — usually an icon-only link with no name. It's common on cart, wishlist, and social icons built in a hurry. A screen reader announces "link," with no purpose attached. Fix: `<a href="/cart" aria-label="View cart, 2 items"><svg aria-hidden="true">…</svg></a>`.

5. Empty buttons — 4.1.2 Name, Role, Value, Level A. The same problem as #4, on `<button>` elements — icon-only close, search, and menu-toggle buttons with no name, because the icon looks self-explanatory to whoever built it. Fix: `<button aria-label="Close menu"><svg aria-hidden="true">…</svg></button>`.

6. Missing document language — 3.1.1 Language of Page, Level A. No `lang` attribute on the `<html>` element. Common because it's invisible — nothing on the rendered page looks wrong without it. Screen readers use it to pick a pronunciation engine; without it, an English page can get read in a French voice. Fix: one attribute, site-wide — `<html lang="en">`.

Which four violations dominate ecommerce audits beyond the home page?

Beyond what a home-page scan can see, four violations recur constantly across product, cart, and checkout templates in TestParty's remediation work — and each one is capable of stopping a sale outright rather than just slowing it down.

7. Keyboard traps & unreachable controls — 2.1.1 Keyboard (A) / 2.1.2 No Keyboard Trap (A). Custom dropdowns, hover-only mega menus, and chat or review widgets that respond to a pointer but never to Tab, Enter, or Escape. Common because they're built and tested with a mouse, and nobody unplugs it before shipping. A keyboard-only shopper can't open a size selector or escape a popup — the session ends there. Fix: build every control as a real `<button>` or `<a>`, never a bare `<div onclick>`, and guarantee Escape returns focus out of any widget.

8. Missing or illogical focus indicators — 2.4.7 Focus Visible, Level AA. No visible outline when tabbing, or an outline hidden behind a sticky header or announcement bar. `outline: none` ships in nearly every CSS reset and starter theme, with nothing added back to replace it. A sighted keyboard user simply loses track of where they are on the page. Fix: `:focus-visible { outline: 2px solid #2563eb; outline-offset: 2px; }` — never remove the default without a replacement.

9. Unannounced dynamic updates (cart, filters, errors) — [4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html), Level AA. Content that changes without a page reload — a cart count, a filtered grid, a validation error — with no signal sent to assistive technology. Nearly every storefront updates the DOM in place now, and the announcement layer is the part that gets skipped. A screen reader user adds an item, hears nothing, and re-adds it or assumes it failed. Fix: `<div role="status" aria-live="polite">Item added to cart</div>`, updated by the same script that changes the visible count.

10. Inaccessible modals & popups — 2.1.2 No Keyboard Trap (A) / 4.1.2 Name, Role, Value (A). Email-capture popups, quick-view modals, and cart drawers that don't move focus in, hold it while open, or return it on close. Most ship from a third-party app the merchant never audited. A keyboard or screen reader user can neither close the popup nor reach the page underneath it. Fix: native `<dialog>` with `.showModal()` handles focus containment and Escape automatically; our accessible modal dialog guide covers the ARIA fallback for anything that can't use it yet.

Which of these violations actually drive lawsuits?

Complaints describe blockers, not scan totals — filings typically cite keyboard-inaccessible navigation, unlabeled checkout fields, and screen-reader-blocking popups far more often than raw error counts would predict.

Federal website accessibility lawsuit filings reached roughly 3,117 in 2025, up 27% year over year, with ecommerce named in 69–77% of digital accessibility suits (Seyfarth Shaw data, tracked in our lawsuit data hub). A plaintiff describing a shopping trip narrates what stopped them — "I couldn't tab past the size menu," "the popup wouldn't close" — which puts violations #7 and #10 disproportionately in complaints relative to their share of total error volume. Low-contrast text and missing alt text still appear, but usually alongside a blocker, not as the sole claim. Our broader WCAG violations data analysis maps the full DOJ-guidance overlap if you want the source-level detail behind this pattern.

What catches these violations — scanners or humans?

Six of these ten are reliably caught by an automated scan; four require a person with a keyboard and a screen reader — which is exactly why automated detection tops out at roughly 60–70% of issues industry-wide, with manual testing finding the rest.

The top six on this list are exactly the six a script can evaluate from static markup — which is also why they're the six WebAIM's home-page crawl can publish at scale. The bottom four need someone to act on the page, which WAVE, Lighthouse, and axe all do partially but none does completely; run all three and still budget time for a keyboard pass.

How do you fix all 10 at once?

Fix all 10 at the template and component level, not instance by instance — one color token, one form-field partial, one modal wrapper, and one shared live region collectively touch every page built from them.

A contrast fix on a design token cascades to every component referencing it. One accessible label pattern, dropped into the theme's form-field snippet, fixes labels sitewide the moment it replaces the old one. A single native-`<dialog>`-based modal component fixes traps, focus return, and Escape handling everywhere a popup or drawer appears, and one shared `aria-live` region handles every cart, filter, and error announcement. That's the logic behind source-code remediation instead of per-page patching, and why an initial pass typically clears in about 14 days. Verify against fixed thresholds, not a feeling — Lighthouse 90+, five or fewer WAVE errors, three or fewer axe errors — then keep a daily automated scan and monthly manual audit running, since one new app or theme update can reintroduce any of these 10 within a release cycle.

Frequently Asked Questions

What is the single most common WCAG violation? Low-contrast text, found on 83.9% of the top one million home pages in 2026 (WebAIM Million), mapping to success criterion 1.4.3 Contrast (Minimum) at Level AA. It's also usually the cheapest to fix, since most instances trace back to a small number of color tokens rather than to individual elements.

Are keyboard traps really as common as low-contrast text? Not on a home page — but a home page is rarely where they live. In TestParty's remediation work, keyboard traps and unreachable controls cluster in filters, quick-view modals, and checkout, none of which WebAIM's home-page-only crawl tests.

Can a free scanner catch all 10 of these violations? No. A scanner reliably catches the first six — contrast, alt text, labels, empty links and buttons, and document language — because each is computable from the markup alone. The other four need a person testing with a keyboard and a screen reader.

Which of these 10 violations is most likely to trigger a lawsuit? Barriers that stop a transaction outright — keyboard traps, unlabeled checkout fields, and screen-reader-blocking modals — appear in complaints far more often than their raw frequency would predict, because they're the failures a plaintiff can describe as "I could not complete my purchase."

How long does it take to fix all 10 violations across a site? About 14 days for an initial pass, when fixes are made at the template and component level rather than instance by instance. After that, daily automated scans plus monthly manual audits catch the regressions that new products, apps, and pages inevitably reintroduce.

Humans + AI = this article. TestParty uses a cyborg approach to content — combining human accessibility expertise with AI capabilities to produce accurate, comprehensive guides. This content is for educational purposes and reflects our analysis of publicly available information as of the publication date. TestParty competes in the digital accessibility market, and we encourage readers to evaluate all solutions independently based on their specific needs.