Every year WebAIM runs automated checks across the home pages of the top one million websites. The 2026 report, based on an analysis in February, is the first in six years to show the web getting worse rather than slowly better. The numbers are worth knowing because the six errors behind most of them are also the easiest to find and fix.
The headline figures
- 95.9 per cent of home pages had detectable WCAG 2 failures, up from 94.8 per cent in 2025.
- 56.1 errors per page on average, a total of 56,114,377, up 10.1 per cent from 51 per page the year before.
- Home pages averaged 1,437 elements, up from 1,257 a year earlier. A user who relies on assistive technology meets an error roughly every 26 elements.
Remember what this measures. Automated tools detect only a portion of WCAG failures, so the true rate of non-conformance is higher, not lower.
The six errors
As in every previous year, six error types account for the overwhelming majority of what was found:
- Low-contrast text: 83.9 per cent of pages.
- Missing alternative text for images: 53.1 per cent.
- Missing form input labels: 51 per cent.
- Empty links: 46.3 per cent.
- Empty buttons: 30.6 per cent.
- Missing document language: 13.5 per cent.
Missing alt text and missing language declined slightly. The other four rose. None of these requires a specialist to detect, and each maps to a WCAG success criterion that has been stable since WCAG 2.0 in 2008 (contrast at Level AA, the rest at Level A).
ARIA is still making things worse
82.7 per cent of home pages now use ARIA, up from 79.4 per cent, and the volume keeps climbing: more than 133 ARIA attributes per page, up 27 per cent in a year. Pages with ARIA averaged 59.1 errors against 42 on pages without it. Pages averaged 23.3 instances of aria-hidden="true" and 4.8 of role="button". Of the 5.7 per cent of pages with an ARIA menu, 22 per cent of those menus introduced barriers.
The lesson has not changed since the first report: ARIA used to patch over non-semantic markup correlates with more errors, not fewer. Native HTML elements first, ARIA for what HTML cannot express.
Frameworks, platforms and sectors
The report found that the presence of nearly every popular JavaScript library was associated with more detected errors. Among the frameworks WebAIM lists, Astro pages had the fewest errors at 9.0 per page and Firebase-hosted pages the most at 82.9. Next.js (40.9) and React (43.5) sat below the overall average. Among content management systems, WordPress, which appeared on 252,302 of the pages, averaged 52.8 errors, a little under the mean, while Adobe Experience Manager (29.9), Squarespace (33.0) and Wix (33.3) did noticeably better. Government sites were the best sector at 42.4 errors per page, and sports (71.4) and shopping (71.0) the worst, which is uncomfortable reading for anyone in e-commerce facing the European Accessibility Act.
Skip links are one small bright spot: 17.1 per cent of pages had one, up from 15.3 per cent, though about one in ten of them was broken.
The full report is at webaim.org/projects/million.
Finding the six in your own work
All six errors are detectable by automated checks, which is exactly what the Audit tool in Accessibility Checker runs, using the same axe-core engine most teams use in their pipelines. Contrast is the one that needs a designer’s eye as well as a tool: the Color Contrast tool checks any screenshot, website or live camera view against the WCAG ratios and suggests accessible alternatives.
For native apps the same six have equivalents: unlabelled buttons and images, missing labels on form fields, low-contrast text that does not adapt to Increase Contrast, and controls built from plain views without traits. Xcode’s Accessibility Inspector finds most of them.
Try it this week
Audit your own home page and count how many of the six appear. Then read WCAG: Perceivable, which covers contrast and text alternatives, the two most common failures in the report.