Website Accessibility Statistics 2026: Data From 219 Sites

87.7% of website homepages fail at least one automatically detectable WCAG 2.2 Level A or AA check. That's the headline from our October 2026 study of 219 randomly sampled homepages, tested with axe-core in a real browser. The median homepage had 10 failing elements. Color contrast failed on 64.4% of sites, and more than half (51.6%) had at least one critical-impact violation.

The 12.3% that passed every automated rule weren't in the clear either: in a second pass, 25 of 27 zero-violation homepages still had elements that axe-core flagged for human review. And on 34.6% of the homepages we tested with a keyboard, a focused link or button ended up completely hidden behind a sticky header, cookie banner or pop-up.

Below are the full statistics: the method, the distribution, the rules that fail most, how results differ by site popularity, what automation leaves unresolved, and a script to benchmark your own sites the same way.

Methodology

We skipped the top 1,000 because those ranks are dominated by CDNs, ad and API domains with no human-facing homepage. Only homepages were tested. Inner pages, forms and checkouts usually have more problems, so treat these figures as a floor.

The Headline Numbers

The mean is more than three times the median because failures are concentrated: the 10% worst homepages account for 55% of all failing elements. Most sites have a moderate number of issues, and a minority have a very large number.

Distribution of failing elements

Nearly two-thirds of homepages (64.4%) have 20 or fewer failing elements. For most sites, reaching zero automated violations is a few days of work, not a rebuild.

The tail matters too. The 18 homepages with more than 100 failing elements weren't uniformly bad: on those sites, just two rules accounted for a median 88% of all failures. That pattern points to a repeating component, such as a product grid with unnamed links, a footer full of low-contrast links or an icon row with undersized targets. Fixing that one component clears most of the count, so the number of fixes needed is far smaller than the number of failures.

The WCAG Failures That Appear Most Often

Four rules (contrast, link names, target size and image alt text) account for 81.4% of all failing elements. A team that fixes just those four categories removes four-fifths of its automated backlog.

Contrast deserves special mention. More than half of the failing text elements measured between 3.5:1 and 4.49:1, close to the 4.5:1 threshold. Our guide to fixing color contrast errors shows how to fix most of them with a small change to a shared color token.

Critical-impact failures

axe-core rates each violation by impact. 6,256 failing elements were serious and 1,127 were critical. The critical ones block access outright, and they came from a short list of rules:

Does Site Popularity Make a Difference?

The most popular band does somewhat better, with a lower median and more fully clean homepages. But even among sites ranked 1,001–10,000, five in six had at least one detectable failure. Popularity buys polish, not accessibility.

Government and university sites were a small group in our sample (13 homepages), with a median of 4 failing elements. That's lower than average, which fits their legal obligations, though the sample is too small to generalise from.

What Automated Testing Left Unresolved

A violation count only covers what a rule engine can decide. Two more measurements show how much it can't.

Needs review. axe-core puts elements it can't judge into a separate "incomplete" list, for example text on a background image, where no single background color can be measured. In a second pass over the same homepages (209 completed), 90.0% had at least one needs-review element, with a median of 14 per homepage. In total there were more needs-review elements (8,016) than definite violations (6,349), and 92% of them were contrast checks on text over images, gradients or layered backgrounds. Our guide to what automated accessibility testing can't catch breaks these down.

Focus hidden by sticky elements. WCAG 2.2 added SC 2.4.11 Focus Not Obscured: when a control has keyboard focus, it must not be completely hidden by content the site added. We tabbed forward and backward through each homepage, without dismissing any banner, as a first-time keyboard user would.

We only counted cases where the covering element was itself position: fixed or sticky. Elements covered by something we couldn't identify were left out, so these numbers are conservative. The fixes are mostly one-line CSS, covered in our WCAG 2.2 checklist.

Images, Zoom and Overlays

Overlays deserve a footnote. In a separate test of 62 overlay sites, measured with the overlay running and with it blocked, the overlay made no measurable difference to axe-core results on 90% of them. The details are in our article on whether accessibility overlays work. For alt-text patterns, see our guide on how to write alt text.

How This Compares to Other Research

The best-known long-running benchmark is the WebAIM Million, which tests the homepages of the top million sites each year with a different engine (WAVE). Its methodology, rule set and sample differ from ours, so the numbers shouldn't be compared one to one. The direction is the same, though. In every large study, the overwhelming majority of homepages fail automated checks, and low-contrast text is the most common failure.

Benchmark Your Own Sites

This script reproduces our per-site measurement for any list of URLs (your own properties, competitors or client sites) and writes a CSV with violations, needs-review counts and the top rules.

#!/usr/bin/env python3
"""Benchmark accessibility across many sites with axe-core and write a CSV.

Reproduces the per-site measurement used in our 2026 accessibility statistics study:
Chromium at 1366x900, load + 3 s settle, axe-core 4.10.2 with WCAG 2.0/2.1/2.2 A+AA tags.
One row per URL: violations, needs-review items, and failing elements per rule.

Usage:  pip install playwright && playwright install chromium
        python3 a11y_benchmark.py urls.txt > results.csv      # one URL per line
"""
import asyncio, csv, sys
from playwright.async_api import async_playwright

AXE_CDN = "https://cdnjs.cloudflare.com/ajax/libs/axe-core/4.10.2/axe.min.js"
RULES = ["color-contrast", "link-name", "target-size", "image-alt", "button-name",
         "meta-viewport", "label", "html-has-lang", "list", "aria-hidden-focus"]


async def audit(browser, url, sem):
    async with sem:
        ctx = await browser.new_context(viewport={"width": 1366, "height": 900}, bypass_csp=True)
        page = await ctx.new_page()   # bypass_csp: a strict CSP would block the axe <script> tag
        try:
            resp = await page.goto(url, wait_until="load", timeout=35000)
            await page.wait_for_timeout(3000)
            if resp and resp.status >= 400:
                return {"url": url, "error": f"HTTP {resp.status}"}
            await page.add_script_tag(url=AXE_CDN)
            r = await page.evaluate("""async () => {
                const r = await axe.run(document, {runOnly: {type: 'tag',
                    values: ['wcag2a','wcag2aa','wcag21a','wcag21aa','wcag22aa']}});
                const m = l => Object.fromEntries(l.map(v => [v.id, v.nodes.length]));
                return {v: m(r.violations), i: m(r.incomplete)};
            }""")
            row = {"url": url, "error": "",
                   "violating_elements": sum(r["v"].values()), "rules_failed": len(r["v"]),
                   "needs_review_elements": sum(r["i"].values())}
            row.update({rule: r["v"].get(rule, 0) for rule in RULES})
            return row
        except Exception as exc:
            return {"url": url, "error": type(exc).__name__}
        finally:
            await ctx.close()


async def main(path):
    urls = [l.strip() for l in open(path) if l.strip() and not l.startswith("#")]
    async with async_playwright() as pw:
        browser = await pw.chromium.launch()
        sem = asyncio.Semaphore(4)
        rows = await asyncio.gather(*(audit(browser, u, sem) for u in urls))
        await browser.close()
    fields = ["url", "error", "violating_elements", "rules_failed", "needs_review_elements"] + RULES
    w = csv.DictWriter(sys.stdout, fieldnames=fields, restval="")
    w.writeheader()
    w.writerows(rows)


if __name__ == "__main__":
    asyncio.run(main(sys.argv[1]))

Sort the CSV by violating_elements to see where you stand, then compare the rule columns with the table above. If your top rules match the population's, the most common WCAG violations guide is the fastest place to start.

How BugViso Measures Accessibility

BugViso uses the same engine and rule tags as this study: a self-hosted axe-core run with the WCAG 2.0, 2.1 and 2.2 A/AA tags, on every audited page, in a fully rendered Chromium session. Each violation is reported with its WCAG criterion, impact level and failing elements, with measured colors and ratios for contrast failures. A mobile device-emulation pass adds tap-target sizing against WCAG 2.5.8 and checks horizontal overflow and viewport settings.

On a multi-page crawl, a rule that fails in a shared header is counted once per site rather than once per page, so the report reflects the real size of the fix list. Results appear in the web report and the PDF report, and scheduled scans show whether the numbers are moving in the right direction. To see where your homepage sits against these statistics, run a free BugViso accessibility scan.

Limitations

• Automated checks only. These numbers count what axe-core can detect. Many WCAG criteria (keyboard operation, focus order, meaningful alt text, captions) need manual testing, so real conformance rates are lower than these figures suggest.
• Homepages only. Inner templates and transactional flows weren't tested.
• One location, one viewport, no login. Geo-targeted content and mobile layouts may differ.
• Excluded sites. Bot-protected sites couldn't be measured, and they skew towards large e-commerce and media brands.
• Random sample of 219. Sub-group figures (rank bands, government and education) carry wide uncertainty.

FAQ

What percentage of websites are accessible?

By automated checks alone, only 12.3% of the homepages we tested had zero detectable WCAG A/AA violations, and even those still had items needing manual review. The share that would pass a full manual WCAG audit is lower still.

What is the most common accessibility error on websites?

Low color contrast (WCAG 1.4.3). It affected 64.4% of homepages and made up 46.9% of all failing elements in our sample.

Are accessibility problems getting better?

A single snapshot can't measure a trend, and this is our first edition. What the data does show is where problems persist. Defects that frameworks and CMSs now guard against were relatively rare: only 4.6% of homepages lacked a page language, and just 6.1% of images had no alt attribute. Contrast, unnamed links and small touch targets remain widespread because they come from design decisions, not markup defaults. We'll repeat the study with the same method so future editions can show the trend.

How many WCAG violations does an average website have?

The median homepage in our sample had 10 failing elements across 3 distinct rules. The mean was 33.7, pulled up by a small group of sites with more than 100.

Can I cite these statistics?

Yes. Please cite "BugViso Website Accessibility Statistics 2026 (219 homepages, axe-core 4.10.2, October 2026)" and link to this page. The method is described above, so others can reproduce it.

Conclusion

Nearly nine in ten homepages fail automated WCAG checks, but four rules account for four-fifths of the failures, and most failing contrast is within a point of passing. That makes accessibility a backlog most teams can clear, starting with the list a BugViso scan produces for their own site.