Start with contrast, alt text, form labels, link and button names, and the page language. WebAIM’s analysis of a million home pages found that six issue types account for 96% of every error its tooling detects. None of the six is hard. None of them needs a rebuild. Fixing them will put your site ahead of most of the web, and the rest of accessibility work gets much easier once they are out of the way.
This is not a compliance lecture. Accessibility work pays for itself in plainer markup, better keyboard support, cleaner forms and pages that behave sensibly when a connection drops. It also happens to be a legal requirement in a growing number of markets, which is why it moved up most roadmaps in 2025.
The six problems that cause almost everything
WebAIM has run the same study for eight consecutive years, using the WAVE engine against the rendered DOM of the top million home pages. The same six failure types have led the list for seven years running.
Read that list again as a to-do list rather than a statistic. Pick a colour pair that passes. Write alt text. Attach a label to every input. Give every link and button a name. Set lang on the <html> element. That is a day of work on a small site, and it addresses the majority of what automated testing can find.
What the numbers say about the web right now
The direction of travel is the uncomfortable part. Across the million pages, WebAIM detected 56,114,377 distinct errors in February 2026, an average of 56.1 per page and 10.1% more than the 51 per page it found in 2025. Pages with detectable WCAG 2 failures rose to 95.9% from 94.8%, which broke a run of six years of gradual improvement.
WebAIM’s own explanation is worth taking seriously: pages got more complex. The average home page carried 1,437 elements in February 2026, a 14.3% rise in a single year, and ARIA attributes rose 27% to more than 133 per page. More markup means more places to get it wrong. The report links the trend to heavier reliance on third-party frameworks and automated or AI-assisted coding.
| Failure type | 2024 | 2025 | 2026 | Direction |
|---|---|---|---|---|
| Low contrast text | 81% | 79.1% | 83.9% | Worse |
| Missing image alt text | 54.5% | 55.5% | 53.1% | Better |
| Missing form input labels | 48.6% | 48.2% | 51% | Worse |
| Empty links | 44.6% | 45.4% | 46.3% | Worse |
| Empty buttons | 28.2% | 29.6% | 30.6% | Worse |
| Missing document language | 17.1% | 15.8% | 13.5% | Better |
Low contrast is the easiest thing to fix and the most often broken
Low contrast text was on 83.9% of home pages, with 34 distinct instances per page on average, up 15% on 2025. It is the most common detected barrier and the cheapest to remove, because it is a decision in a stylesheet rather than a change to markup.
WCAG 2.2 success criterion 1.4.3 Contrast (Minimum), at Level AA, asks for a contrast ratio of at least 4.5:1 between text and its background, dropping to 3:1 for large text — defined as 18pt, or 14pt bold. Interface components and meaningful graphics are covered separately by 1.4.11 Non-text Contrast at 3:1.
| Content | WCAG 2.2 Level AA minimum | Level AAA |
|---|---|---|
| Body text under 18pt | 4.5:1 | 7:1 |
| Large text, 18pt or 14pt bold | 3:1 | 4.5:1 |
| Icons, borders, focus indicators | 3:1 (SC 1.4.11) | Not specified separately |
| Logotypes and incidental text | Exempt | Exempt |
- Placeholder text in form fields, which designers love and often set at 40% grey.
- Light grey captions and metadata under headings and images.
- White text over a photograph, where the ratio changes across the image.
Images, alt text and the quiet damage of a filename
The million home pages carried 66.6 million images, an average of 66.6 per page and 13.6% more than a year earlier. Of those, 16.2% were missing alt text entirely — about 10.8 images per page — although that proportion did improve from 18.5% in 2025. A further 10.8% of images that did have alt text had questionable text: the word “image”, a filename, or a repeat of the caption next to it.
The detail that matters commercially: 45% of the images missing alt text were linked images, so one in four linked images gave a screen reader user no idea where the link goes. That is not a tidiness issue, it is a navigation failure on a page element people are meant to click.
- Describe the function for a linked image: “View the pricing page”, not “blue arrow icon”.
- Describe the content for an informative image, in a sentence a person would actually say out loud.
- Use
alt=""deliberately for decoration, so assistive technology skips it. - Never leave the filename.
alt="IMG_4471.jpg"is worse than nothing because it gets read aloud.
Forms, labels and the keyboard
Home pages averaged 6.9 form inputs in 2026, a 36% rise over three years, and a third of them — 33.1% — had no proper label by way of <label>, aria-label, aria-labelledby or title. An unlabelled field is a field a screen reader announces as “edit text”, with no clue what belongs in it.
Keyboard support is the other half of this. Try it now: load your own site and press Tab repeatedly. You should always be able to see where focus is, reach every control, and operate everything without touching a mouse. WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum) at Level AA precisely because sticky headers and cookie banners so often cover the element that just received focus.
While you are in there, check the skip link. WebAIM found a skip link on 17.1% of home pages, up from 15.3%, but one in ten of those was broken — either hidden in a way that made it unreachable, or pointing at a target that no longer existed.
What WCAG 2.2 actually asks for
WCAG 2.2 became a W3C Recommendation on 5 October 2023. It keeps the 2.0 and 2.1 success criteria almost unchanged, adds nine new ones, and removes 4.1.1 Parsing, which modern browsers made redundant. Level AA is the conformance target almost every policy and procurement document references.
| New in WCAG 2.2 | Level | What it asks in plain terms |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | The focused element must be at least partly visible |
| 2.5.7 Dragging Movements | AA | Anything draggable also works with a single pointer action |
| 2.5.8 Target Size (Minimum) | AA | Interactive targets at least 24×24 CSS pixels, with exceptions |
| 3.2.6 Consistent Help | A | Help and contact options appear in a consistent place |
| 3.3.7 Redundant Entry | A | Do not make people re-enter information they already gave you |
| 3.3.8 Accessible Authentication (Minimum) | AA | No cognitive function test with no alternative — allow paste into password fields |
3.3.8 is the one that surprises people. If your login blocks pasting, or depends on transcribing a code from one screen to another with no alternative, that is now a Level AA failure. Allowing a password manager to work is the fix.
Why this became a commercial question in 2025
The European Accessibility Act entered into application on 28 June 2025. The European Commission’s announcement the day before put it plainly: from that date, key products and services including phones, computers, e-books, banking services and electronic communications must be accessible to people with disabilities. The Commission notes that around 100 million people in the EU live with a disability, which is the commercial size of the audience, not just the regulatory one.
The technical baseline sits in the harmonised European standard EN 301 549 — version 3.2.1 at the time the Commission’s current web accessibility guidance was written — which in turn points at WCAG for web and mobile interfaces. What catches businesses out is the scope: these are market rules, so they follow the customer rather than your registered address. If you sell to consumers in the EU, assume it applies to you and get a baseline audit before someone else tells you it does.
What changed in 2025The question stopped being whether accessibility is required and became which market requires it first.
The ARIA trap
This is the finding most teams need to hear. In the 2026 WebAIM data, 82.7% of home pages used ARIA, up from 79.4%. Pages with ARIA present averaged 59.1 detected errors against 42 on pages without it — about 17 extra potential barriers. WebAIM is careful to say that ARIA did not necessarily cause those errors, since ARIA-heavy pages were also more complex. But the correlation held across the sample, and 22% of the ARIA menus it found introduced barriers through missing markup or interaction handling.
The practical lesson is the first rule of ARIA: do not use ARIA. Use a <button> rather than a <div role="button"> with a keydown handler. Use a <label> rather than aria-labelledby. Native elements come with keyboard behaviour, focus handling and screen reader semantics already correct, for free, and they do not drift when someone refactors the component.
Your platform affects your starting point
WebAIM also reported average errors by platform, which is a useful sanity check when you are choosing where to build. The spread is wide, and most mainstream platforms start you below the overall average of 56.1 errors per page.
| Platform | Home pages in sample | Average detected errors | Vs. the 56.1 average |
|---|---|---|---|
| Adobe Experience Manager | 6,572 | 29.9 | −46.7% |
| Squarespace | 2,669 | 33.0 | −41.2% |
| Wix | 3,183 | 33.3 | −40.6% |
| Drupal | 18,222 | 41.2 | −26.5% |
| Joomla | 3,981 | 45.7 | −18.6% |
| WordPress | 252,302 | 52.8 | −5.8% |
Do not over-read this. The platform sets your starting point, not your ceiling: WordPress sites average slightly better than the web as a whole, and a careless build on any platform will fail. The library choices inside the page matter at least as much — WebAIM found pages using jQuery UI averaged 79.9 errors and those using Swiper 74.0, against 9.0 for pages built with Astro.
A testing routine that fits a real week
- Run an automated scan on your five most important templates. Axe, WAVE or Lighthouse will all find the contrast, label and alt text problems in minutes.
- Tab through each template. Focus always visible, every control reachable, nothing trapped, skip link works.
- Turn on a screen reader for ten minutes. VoiceOver on macOS and iOS, Narrator on Windows, TalkBack on Android. You do not need to be fluent; you need to hear your own navigation read aloud.
- Zoom to 200% and to 400% and check nothing is clipped or overlapping.
- Check one real form end to end with the keyboard only, including the error messages.
- Write down what you found and fix the template, not the page. One template fix usually closes hundreds of instances.
Automated tools only detect a subset of WCAG failures — WebAIM says so plainly in its own methodology, and the absence of detected errors does not mean a page is accessible. Keyboard testing and a short screen reader pass close most of the remaining gap for a small site. Full conformance claims need manual testing with assistive technology and expert review, and anyone selling you a one-click overlay that promises compliance is selling you a liability.
Our web development and hosting service includes accessibility audits and remediation, delivered remotely wherever your team sits. The work overlaps heavily with two other pieces: mobile-first web design, because touch target size and contrast are the same decisions, and why a fast, modern website matters, because the markup simplification that helps assistive technology also makes pages lighter. If a rebuild is on the cards, doing it without losing rankings is the time to fix all of this at once.
Frequently asked questions
Which standard should we actually aim for?
WCAG 2.2 Level AA. It is the version published as a W3C Recommendation in October 2023, it is what EN 301 549 and most public-sector policies reference, and Level AA is the conformance level procurement documents ask for. Level AAA is worth borrowing from selectively — higher contrast ratios, for instance — but it is not a realistic target for a whole site.
Does an accessibility overlay or widget make us compliant?
No. The European Commission’s own web accessibility guidance says overlays and similar tools that do not make the site itself meet EN 301 549 are not an appropriate solution, and that issues are best fixed at source. Overlays cannot repair missing alt text, a broken heading structure or an unlabelled form. Spend the money on the templates instead.
How long does it take to fix an existing site?
For a small brochure site, the six common failure types are usually one to three days of work because they live in templates and a stylesheet. A large application with custom components takes longer, and the honest answer is that it becomes an ongoing practice rather than a project. Start with the templates that carry the most traffic.
Does accessibility work help search rankings?
Indirectly, and not as a bonus for compliance itself. Proper headings, descriptive link text, real alt text and labelled forms all give search engines clearer structure, and the simplification tends to make pages faster. Treat better search performance as a side effect rather than the reason.
Do we need to care if we only sell outside the EU and the US?
Check your own markets, because accessibility requirements now exist in many jurisdictions and procurement rules often impose them regardless of local law. Even where nothing applies, the commercial argument holds: the European Commission counts around 100 million people with a disability in the EU alone, and an inaccessible checkout loses those sales without ever telling you why.
Want an accessibility audit that gives you a fix list rather than a score? Get in touch with Eudora Technology to talk about your project.
