Most Common WCAG Violations: Data From 50 Site Scans (2026)

We scanned 50 home pages with a11yFlow on 15 October 2026. These are the rules that failed most.

The sites come from the top of the Tranco top-sites list; the selection rule, and the sites we had to skip, are in the method box below. Each home page got one automated scan against WCAG 2.2 Level AA with our production scanner, which runs axe-core 4.11.1 in headless Chromium. We report totals only and do not name any site.

Key findings: 33 of the 50 home pages (66%) failed at least one automated WCAG 2.2 AA check. Low-contrast text was the most common failure, on 15 sites (30%), and it accounted for 199 of the 576 element-level failures we recorded. Undersized tap targets, a requirement added in WCAG 2.2, came second at 14 sites (28%). The median a11yFlow score was 92 out of 100.

The first half of this post is the data. The second half takes the ten most common failures in turn and gives the failing HTML, the corrected HTML and a way to confirm the fix worked. If you want the wider testing workflow first, start with our guide for developers.

Which WCAG Rules Failed Most Often?

Twelve rules failed on at least 4 of the 50 home pages. Across the whole sample, 26 different axe-core rules failed at least once.

"Median failing elements" only counts the sites where that rule failed. Impact is axe-core's own rating, and the criterion comes from the WCAG tags axe-core attaches to each rule (axe-core rule descriptions).

A few patterns stood out once the numbers were in:

• Most pages failed a little, a few failed a lot. Across all 50 sites the median page failed 1 rule, with 2 element-level failures (an element that fails two rules counts twice). Among the 33 that failed, the medians rose to 2 rules and 6 element-level failures. Eight sites failed five or more rules each, which pulls the mean up to 11.5 element-level failures per page.
• Contrast dominates by volume as well as by reach. Of the 576 element-level failures, 199 (34.5%) were contrast. Missing alt text came next at 91 (15.8%), even though it turned up on only 8 sites.
• Two rules explain most of the failing sites. 24 of the 33 failing home pages had a color-contrast or target-size failure, or both.
• More than one site in five had something with no name. 11 sites (22%) had at least one image, link or button with no accessible name (image-alt, link-name or button-name).
• ARIA misuse is spread thin but wide. 13 sites (26%) failed at least one rule whose ID starts with aria-, and nine different aria- rules fired across the sample.

The a11yFlow score for the 50 pages had a median of 92 and a mean of 86.1, ranging from 46 to 100. Nine sites scored below 70. If you want to know what goes into that number, we explain the weights in how accessibility scores are calculated.

How We Ran the Scans

Method

Sample. Tranco list N26XW, generated on 14 October 2026 from 30 days of rankings by CrUX, Farsight, Majestic, Radar and Umbrella (Tranco). We walked the list in rank order and skipped domains with no home page meant for people (CDNs, DNS, cloud APIs, ad and analytics hosts, device clouds), link shorteners, user-content hosting domains, domains that redirect to a site already in the sample, and domains that did not resolve. No adult or gambling sites came up in that range.

Scanner. a11yFlow's production scan function, run from a UK connection: axe-core 4.11.1 in headless Chromium at 1280 by 720 pixels, Level A and AA rules from every WCAG 2 version up to 2.2, target-size switched on, best-practice rules off. That means rules such as heading-order are not counted here. The scanner tries to dismiss cookie banners before it runs, and it identifies itself as a11yFlow in its user agent rather than posing as a regular browser.

Attempts. 61 scans, one or two at a time. Eight were blocked (seven HTTP 403 responses and one HTTP 429), two redirected to a site we had already counted, and one finished after we had reached 50. We kept the first 50 valid scans in list order.

Limits. Home pages only, not sign-up, checkout or logged-in pages. Automated checks only, and automated checks find a portion of WCAG issues, not all of them. One point in time. Fifty large, well-funded sites, so read these numbers as a snapshot of the top of the web, not the web as a whole. Because the scanner announces itself, some sites may have served it a different page than a visitor would get; one sent it a mobile version.

How Does This Compare With the WebAIM Million?

WebAIM's 2026 study of the top 1,000,000 home pages found detectable WCAG 2 failures on 95.9% of them, and those pages averaged 56.1 errors each (WebAIM Million, 2026). We found failures on 66% of our 50.

Several differences explain at least part of that gap. WebAIM runs the WAVE engine and we run axe-core, and the two engines check and count differently, so their per-page error counts and our element-level counts are not the same measure. Our sample is the 50 highest-ranked sites that passed our filter, mostly run by large teams, where WebAIM covers a million sites of every size. Our WCAG 2.2 scan also checks target size, which is not one of the six failure types WebAIM lists as most common.

The ranking at the top is where the two agree. Both studies put low-contrast text first, and WebAIM's figure for it is 83.9%.

How to Fix the 10 Most Common Failures

The sections follow the table above. Where two rules share a cause (list and listitem, or the two ARIA attribute rules), they share a section, which makes ten fixes for the top twelve rules. We ran every snippet below through axe-core 4.11.1 with the scanner's settings: each "fails" example trips its rule, and each "passes" example clears it.

The HTML is deliberately plain. The fixes are the same in any framework; for the framework-specific side, see our React testing walkthrough and our Next.js guide.

1. Low-Contrast Text (color-contrast, 30% of Sites)

Fifteen sites failed this, with a median of 3 elements each. WCAG 1.4.3 asks for a contrast ratio of at least 4.5:1, dropping to 3:1 when text is large; W3C counts 18 point, or 14 point bold, as large (W3C). One way to miss it is a brand-colored button with white text.

/* Fails: white on #2f80ed is 3.87:1 at 16px */
.cta { background: #2f80ed; color: #ffffff; }

/* Passes: white on #1565c0 is 5.75:1 */
.cta { background: #1565c0; color: #ffffff; }

How to confirm: rescan and check that color-contrast is gone. Then check hover and focus styles by hand, because a scan only sees the page in the state it loaded in. Text on a background image needs a manual look too: axe-core's rule notes say it "will not report on text elements that have a background-image" (Deque). Our color contrast guide covers ratios, large text and non-text contrast in depth.

2. Small Tap Targets (target-size, 28% of Sites)

Fourteen sites failed this, with a median of 4.5 elements each. Success criterion 2.5.8, Target Size (Minimum), arrived in WCAG 2.2, which became a W3C Recommendation on 5 October 2023 (W3C). It is Level AA. A pointer target must measure 24 by 24 CSS pixels or more, with some exceptions. The one you will use most is spacing: a smaller target passes if a 24-pixel circle centered on it does not overlap another target or another small target's circle. Links inside a sentence are exempt (W3C).

A row of small icon links is an easy way to fail it:

<div class="social">
  <a href="/feed.xml"><svg width="16" height="16" aria-hidden="true" focusable="false"></svg><span class="visually-hidden">RSS feed</span></a>
  <a href="/newsletter"><svg width="16" height="16" aria-hidden="true" focusable="false"></svg><span class="visually-hidden">Newsletter</span></a>
  <a href="/contact"><svg width="16" height="16" aria-hidden="true" focusable="false"></svg><span class="visually-hidden">Contact us</span></a>
</div>

/* Fails: 16 by 16 pixel links, 4px apart */
.social { display: flex; gap: 4px; }
.social a { display: inline-flex; width: 16px; height: 16px; }

/* Passes: the icon stays 16px, the link grows to 24 by 24 */
.social { display: flex; gap: 8px; }
.social a {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 24px;
  min-height: 24px;
}

One thing to check in your own setup: axe-core ships with target-size turned off by default (axe-core rule descriptions). In our tests, an axe run with no options skipped it, while a run filtered to the wcag22aa tag included it. If your CI calls axe with its defaults, this rule is not running.

How to confirm: rescan, then inspect each target in DevTools and read its rendered size. Repeat at a phone-sized viewport, because our scans used a 1280-pixel desktop window.

3. Images Without Alt Text (image-alt, 16% of Sites)

Only 8 sites failed this, but they had 91 failing images between them, the second-highest element count after contrast. The median was 4 per site. WCAG 1.1.1 is Level A, and axe-core rates the rule critical.

<!-- Fails: no alt attribute -->
<img src="/img/autumn-sale.jpg" width="600" height="200">

<!-- Passes: the alt carries what the banner says -->
<img src="/img/autumn-sale.jpg" width="600" height="200"
     alt="Autumn sale: 30% off all boots until 31 October">

<!-- Passes: decorative only, so an empty alt -->
<img src="/img/divider.svg" width="600" height="20" alt="">

How to confirm: rescan, then read each alt without looking at the image. If someone who cannot see it would miss information, rewrite it. The rule only checks that an alt is present, so alt="image" passes it while helping nobody.

4. Links With No Name (link-name, 16% of Sites)

Eight sites failed this, with a median of 4.5 links each. It maps to WCAG 2.4.4 and 4.1.2, both Level A. A link that contains only an icon is the simplest way to fail it.

<!-- Fails: an icon and nothing else -->
<a href="/account">
  <svg width="20" height="20" viewBox="0 0 20 20"><circle cx="10" cy="7" r="4"/></svg>
</a>

<!-- Passes: the link is named, the icon is hidden from assistive tech -->
<a href="/account" aria-label="Your account">
  <svg width="20" height="20" viewBox="0 0 20 20" aria-hidden="true" focusable="false"><circle cx="10" cy="7" r="4"/></svg>
</a>

How to confirm: open the accessibility inspector (Chrome and Firefox DevTools both have one), select the link and check that its computed name reads "Your account". A link with a vague name, such as "Read more", passes this rule; our post on ambiguous link text covers that case.

5. Buttons With No Name (button-name, 12% of Sites)

Six sites failed this, with a median of 1.5 buttons each. It is WCAG 4.1.2 (Level A), and axe-core rates it critical. A menu toggle drawn as three lines is an easy one to miss.

<!-- Fails: screen readers announce only "button" -->
<button class="menu-toggle">
  <svg width="20" height="20" viewBox="0 0 20 20"><path d="M2 5h16M2 10h16M2 15h16"/></svg>
</button>

<!-- Passes: hidden text names it, aria-expanded reports its state -->
<button class="menu-toggle" aria-expanded="false">
  <svg width="20" height="20" viewBox="0 0 20 20" aria-hidden="true" focusable="false"><path d="M2 5h16M2 10h16M2 15h16"/></svg>
  <span class="visually-hidden">Menu</span>
</button>

The visually-hidden class is the usual clipping utility that keeps text in the accessibility tree while hiding it on screen. Update aria-expanded to "true" in your script when the menu opens.

How to confirm: rescan, then tab to the button with a screen reader running. You should hear its name, its role and that it is collapsed.

6. ARIA Attributes in the Wrong Place (aria-allowed-attr, 10%; aria-prohibited-attr, 8%)

These two rules failed on 5 and 4 sites. Both map to WCAG 4.1.2 (Level A). aria-allowed-attr fires when an attribute is used on a role that does not support it, such as aria-selected on a plain link. In navigation, the attribute that means "this is the current page" is aria-current.

<!-- Fails: links do not support aria-selected -->
<nav aria-label="Sections">
  <a href="/news" aria-selected="true">News</a>
  <a href="/sport">Sport</a>
</nav>

<!-- Passes -->
<nav aria-label="Sections">
  <a href="/news" aria-current="page">News</a>
  <a href="/sport">Sport</a>
</nav>

aria-prohibited-attr fires when the ARIA spec forbids an attribute on that element's role. The case you are most likely to hit is a name on an element whose role cannot be named, such as an aria-label on a bare <span> or <div>. Give the element a role that can carry a name, or put the words in the content.

<!-- Fails: a span with no role cannot take aria-label -->
<span class="unread-dot" aria-label="Unread messages"></span>

<!-- Passes: role="img" can be named -->
<span class="unread-dot" role="img" aria-label="Unread messages"></span>

How to confirm: rescan, then check the elements in the accessibility inspector: the News link should show as the current page and the dot should show as an image named "Unread messages". We list more of these errors in ARIA mistakes developers make.

7. Broken List Markup (list, 10%; listitem, 8%)

These failed on 5 and 4 sites and map to WCAG 1.3.1 (Level A). One layout mistake trips both: a wrapper between a list and its items.

<!-- Fails both rules: a div sits between the ul and its li elements -->
<ul class="footer-links">
  <div class="row">
    <li><a href="/about">About</a></li>
    <li><a href="/careers">Careers</a></li>
  </div>
</ul>

<!-- Passes: style the list itself -->
<ul class="footer-links row">
  <li><a href="/about">About</a></li>
  <li><a href="/careers">Careers</a></li>
</ul>

How to confirm: rescan, then check the accessibility inspector shows a list with two items. A screen reader should announce the list and how many items it has before reading them. One side note from our tests: at default line height, two stacked links like these sit too close together for target-size, so give footer links some padding too.

8. Controls Inside Controls (nested-interactive, 8% of Sites)

Four sites failed this, with a median of 4 elements each. It maps to WCAG 4.1.2 (Level A). axe-core's description gives the reason: nested controls "are not always announced by screen readers or can cause focus problems for assistive technologies" (axe-core rule descriptions). A clickable card with its own buttons inside is one way to get there.

<!-- Fails: a button inside an element that acts as a button -->
<div class="card" role="button" tabindex="0">
  <h2>Stovetop kettle</h2>
  <button type="button">Save</button>
</div>

<!-- Passes: one link, one button, side by side -->
<article class="card">
  <h2><a href="/products/stovetop-kettle">Stovetop kettle</a></h2>
  <button type="button">Save <span class="visually-hidden">Stovetop kettle</span></button>
</article>

How to confirm: rescan, then tab through the card. You should land on the product link and then on the Save button, and each should have its own name in the accessibility inspector.

9. No Page Language (html-has-lang, 8% of Sites)

Four sites shipped a home page with no lang on the <html> element. It maps to WCAG 3.1.1 (Level A). Screen readers use it to pick a voice and pronunciation rules.

<!-- Fails -->
<html>

<!-- Passes -->
<html lang="en">

If you serve the same template in several languages, set the tag per version (en-GB, de, ja and so on) rather than hard-coding one.

How to confirm: rescan, or view the source of the page as served and check the opening <html> tag.

10. Zoom Turned Off (meta-viewport, 8% of Sites)

Four sites had a viewport meta tag that blocks zooming. axe-core maps this to WCAG 1.4.4 Resize Text (Level AA), which requires that text can be resized up to 200 percent without loss of content or functionality (W3C). axe-core rates it moderate, the only rule in our top twelve below serious.

<!-- Fails: user-scalable=no and maximum-scale=1 both block zoom -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

<!-- Passes -->
<meta name="viewport" content="width=device-width, initial-scale=1">

In our tests, maximum-scale=1 failed the rule on its own, maximum-scale=2 passed, and user-scalable=no failed on its own.

How to confirm: rescan, then open the page on a phone and pinch to zoom.

How Do You Stop These Coming Back?

Put the same checks in your pipeline so a new failure blocks the merge instead of reaching production. Our GitHub Actions setup walks through it with Playwright and axe-core, and shows how to call the a11yFlow API instead if you would rather not maintain the browser setup. Whichever you use, ask for the WCAG 2.2 AA rules explicitly so target-size runs.

What a Clean Scan Does Not Tell You

17 of the 50 home pages (34%) scored 100, meaning our checks found nothing to fail. That is not the same as accessible. WebAIM makes the same point about its own results: a page with zero detected errors may still fail WCAG (WebAIM Million, 2026). Keyboard traps, focus order, whether alt text actually describes anything, and whether a screen reader user can finish a task all need a person to test. Our automated vs manual testing breakdown has the numbers on how much each approach catches.

Frequently Asked Questions

What is the most common WCAG violation?

In our scan of 50 top home pages on 15 October 2026, it was low-contrast text. It failed on 15 sites (30%) and made up 199 of the 576 element-level failures (34.5%). WebAIM's 2026 study of a million home pages also ranks low contrast first, at 83.9% of pages (WebAIM Million, 2026).

Why did only 66% of these sites fail, when WebAIM reports 95.9%?

The engine, the rules and the sample all differ. WebAIM uses WAVE across the top million home pages; we used axe-core across 50 of the highest-ranked sites on the Tranco list, which tend to have dedicated teams. Treat our figures as a view of the top of the web rather than a replacement for WebAIM's.

Does a score of 100 mean a site is accessible?

No. It means no automated check failed. In our sample, 17 sites scored 100, and each of them still needs manual testing for keyboard use, focus order and content quality before anyone can call it accessible.

Which WCAG level do these failures fall under?

Counting each rule once per site, there were 106 rule failures: 72 under Level A rules and 34 under Level AA. The two most common, color-contrast (1.4.3) and target-size (2.5.8), are both AA. Our compliance guide explains which level the main laws refer to.

How do I check my own site for these rules?

Any axe-core based tool reports the same rule IDs, as long as it runs the WCAG 2.2 AA rules. a11yFlow's API returns each failure with its WCAG mapping and remediation guidance, and the rule IDs match the headings above, so you can jump from a result straight to its fix.

The Bottom Line

Two rules, color-contrast and target-size, covered 24 of the 33 home pages that failed. Fix those first, then work down the table: missing names on images, links and buttons, then ARIA attributes in the wrong place, then list markup, nested controls, a missing lang and blocked zoom. Each fix above is small, and each one can be checked with a rescan.

Sources

• a11yFlow, scans of 50 home pages from Tranco list N26XW, 15 October 2026 (axe-core 4.11.1, WCAG 2.2 A and AA rules)
• Tranco, list N26XW, generated 14 October 2026, retrieved 2026-10-15, https://tranco-list.eu/list/N26XW/1000000
• The WebAIM Million 2026 report (WebAIM), retrieved 2026-10-15, https://webaim.org/projects/million/
• Deque, axe-core 4.11.1 rule descriptions, retrieved 2026-10-15, https://github.com/dequelabs/axe-core/blob/v4.11.1/doc/rule-descriptions.md
• Deque University, color-contrast rule (axe-core 4.11), retrieved 2026-10-15, https://dequeuniversity.com/rules/axe/4.11/color-contrast
• Understanding Success Criterion 1.4.3 (W3C), retrieved 2026-10-15, https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
• Understanding Success Criterion 2.5.8 (W3C), retrieved 2026-10-15, https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
• W3C, What's New in WCAG 2.2, retrieved 2026-10-15, https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
• Understanding Success Criterion 1.4.4 (W3C), retrieved 2026-10-15, https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html