The six most common accessibility errors, and how to fix each one
WebAIM runs an automated accessibility analysis of the top one million home pages every February and publishes the results. The 2026 report is the eighth consecutive year, which makes it the closest thing the field has to a longitudinal measure of where the web actually stands.
The 2026 finding: 95.9% of home pages had detected WCAG 2 failures, up from 94.8% in 2025, with an average of 56.1 errors per page — a 10.1% increase on the 51 errors per page found the year before. That is the reverse of the small annual improvements recorded in each of the previous six years.
The useful part is the distribution. Six error types account for the overwhelming majority of what was found, they are the same six year after year, and every one of them has a known fix.
1. Low contrast text — found on 83.9% of home pages
Text that does not have enough contrast against its background. This is the single most common accessibility failure on the web and it is not close: it appears on more than four in five home pages.
WCAG 1.4.3 Contrast (Minimum), Level AA, asks for a ratio of at least 4.5:1 for normal text and 3:1 for large text — 18pt, or 14pt bold and above. The usual sources are brand grey on white for body copy and secondary labels, light grey placeholder text, white text on a mid-tone brand colour in buttons, and text laid over a photograph.
The fix is a design decision, not a code change, which is why it persists: somebody has to accept a darker grey. Fix it in the design tokens rather than page by page, and check the states as well as the default — disabled, hover, and visited link colours are routinely missed.
2. Missing alternative text for images — 53.1%
Just over half of home pages had at least one image with no text alternative, which means a screen-reader user gets a filename or nothing at all. WCAG 1.1.1 Non-text Content, Level A.
Two rules cover almost every case. If the image carries information, describe the information, not the picture: for a product photo, the product; for a chart, the finding. If the image is decorative — a background texture, a spacer, an icon sitting next to a label that already says the same word — give it an empty alt attribute so assistive technology skips it. An empty alt is a correct answer, not a missing one.
The one to avoid is generic filler. 'Image', 'photo', or a repeated product name across forty gallery shots is technically present and practically useless.
3. Missing form input labels — 51%
Half of home pages had a form control with no programmatic label. Newsletter signups and search boxes are the usual culprits, because a designer wanted a clean input with placeholder text and no visible label.
A placeholder is not a label. It disappears the moment the user types, it is often too low-contrast to read, and support for announcing it varies. The fix is a real label element associated with the input, visually hidden if the design demands it — hidden from sight is fine, hidden from the accessibility tree is not.
This touches WCAG 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions, and 4.1.2 Name, Role, Value, which is part of why it shows up so consistently in audits.
4. Empty links — 46.3%
A link with no discernible text. Almost always an icon-only link — a social icon, a cart icon, a logo wrapping an image with no alt text — where the accessible name resolves to nothing. A screen reader announces 'link' and the user has no way to know where it goes.
Fix it by giving the link an accessible name: alt text on the image inside it, visually hidden text, or an aria-label. Relevant criteria are 2.4.4 Link Purpose (In Context) and 4.1.2 Name, Role, Value.
5. Empty buttons — 30.6%
The same failure on buttons rather than links, on nearly a third of home pages. Hamburger menus, modal close buttons, carousel arrows, quantity steppers and search submit buttons are where it lives.
The fix is identical — give the control an accessible name — and the naming matters. A close button called 'X' is worse than one called 'Close dialog'. Name the action and its object.
6. Missing document language — 13.5%
No lang attribute on the html element, on roughly one page in seven. WCAG 3.1.1 Language of Page, Level A.
Without it, a screen reader uses whatever voice it defaulted to, so English content can be read with Spanish or German pronunciation rules and become incomprehensible. This is a one-line fix in a template and there is no reason for any site to carry it.
Who owns each fix
One reason these six persist is that they are routinely assigned to the wrong person. They split cleanly across three owners, and the fastest way to clear them is to route them that way rather than filing all six as engineering tickets.
- Design owns contrast. It is a decision about the palette, and no developer can resolve it without one. Fix it in the tokens and the whole site moves at once.
- Content owns alt text and link text. These require knowing what the image shows and where the link goes, which is editorial knowledge, not technical knowledge. Automating them produces text that passes the rule and fails the reader.
- Engineering owns form labels, accessible names on icon controls, and the document language attribute. These are template edits with unambiguous correct answers.
What the numbers do and do not tell you
Two caveats worth holding. First, these are automatically detectable errors — the count is what a machine can be certain about, so it is a floor rather than a total. WebAIM is direct about this in the report itself: not all conformance failures can be detected automatically, and the absence of detected errors does not indicate that a page is accessible or conformant. The real rate of full WCAG 2 A and AA conformance is lower than the detected-failure rate implies.
Second, WebAIM tests home pages only, and a home page is typically the most carefully built page on a site — the one that gets the design review and the pre-launch check. Product pages, checkout, account areas, and anything generated from user content or a page builder usually fare worse. If your home page carries 56 errors, that is not your ceiling.
The useful conclusion is not that the web is failing. It is that the failures are concentrated, mechanical, and mostly cheap. These six categories account for the large majority of everything detected, and they have headed the list in every edition of the report we have looked at. A site that fixes contrast, alt text, form labels, and accessible names on icon controls has removed most of the machine-detectable barriers it carries — and has done it in template edits and a palette change, not a rebuild.
It also means the list is stable enough to build a process around. These are not moving targets; they are the same six every year. A design system with a checked palette, an editorial rule that images get alt text at upload, and a component library whose icon buttons ship with accessible names will keep a site out of most of this permanently.
Finding yours
All six of these are exactly what automated scanning is good at: unambiguous, rule-checkable, and countable across a whole site at once. The AdaChecked Site Scanner returns them mapped to the criterion each one fails, with what to change and where, and exports to PDF and Excel for whoever writes your code. The free plan will tell you your score and your top issues without a card.
Source for all figures in this post: the WebAIM Million, the 2026 report on the accessibility of the top 1,000,000 home pages, analysed February 2026, published by WebAIM at webaim.org/projects/million.