Every year, an organization called WebAIM scans the home pages of the top one million websites and checks them for accessibility problems a machine can detect. The 2026 results are not good, and they are also weirdly encouraging. Almost every site fails, but the failures are the same handful of things over and over.
The short version
- 95.9% of home pages had detectable accessibility failures. The average page had 56 of them.
- Just six issues account for 96% of all the errors found.
- Pages are getting more complex, not less. The average home page had 22% more elements than a year earlier, and more code tends to mean more mistakes.
- The fixes are well understood. Most are small changes, not redesigns.
The six issues
1. Low-contrast text (83.9% of pages)
Light gray text on a white background looks clean in a design tool and disappears in real life, especially on a phone outdoors or for anyone with aging eyes. WCAG asks for a contrast ratio of at least 4.5 to 1 for normal text. Free tools like the WebAIM Contrast Checker let you test a color pair in seconds. The fix is usually darkening a text color by a few shades. It is the most common issue on the web and one of the easiest to clear.
2. Missing alt text on images (53.1% of pages)
Alt text is a short written description of an image. A screen reader reads it aloud so a blind user knows what the image shows. When it is missing, the reader often falls back to reading the file name, which might be “IMG_4821.jpg.” When a linked image has no alt text, the user has no idea where the link goes. Every meaningful image needs a short, specific description. Purely decorative images should be marked as decorative, with empty alt text, so the reader skips them.
3. Missing form labels (51% of pages)
A form field needs a label in the code that ties the visible text (“Email address”) to the input box. Placeholder text inside the box does not count. It disappears when someone starts typing, and screen readers handle it inconsistently. Without a proper label, a screen reader user reaches a box and does not know what to put in it. This one directly keeps people from contacting you or checking out.
4. Empty links (46.3% of pages)
An empty link is a link with no text a screen reader can announce. It is often an icon link, like a bare social media icon or a magnifying glass for search, with no hidden label. The user hears “link” with no clue what it does. The fix is adding accessible text, either visible or visually hidden, that says where the link goes.
5. Empty buttons (30.6% of pages)
Same problem as empty links, but for buttons: a hamburger menu icon, a play button, a close “X” with no text behind it. The user hears “button” and nothing else. Give every button a clear accessible name like “Open menu” or “Close.”
6. Missing document language (13.5% of pages)
One line of code in the page header tells assistive technology what language the page is in, for example English. Without it, a screen reader may read your English page with the rules of another language, which sounds like nonsense. This is a one-line fix and it is often already handled by your site’s theme.
What these actually do to a person
Picture someone using a screen reader to book an appointment with you. They land on your page. The hero image has no alt text, so they hear “image, I M G underscore 4 8 2 1.” They tab to the menu; the button is empty, so they hear “button” and guess. They find the contact form. The fields have no labels, so they hear “edit, edit, edit” and cannot tell which box is the phone number. They give up and call your competitor, whose site was built with none of these problems. Every one of those failures was small. Together they cost you the job.
Why automated tools are not enough
The WebAIM scan only counts problems a machine can catch, and even then finds them on 96% of pages. By common estimates in the accessibility field, automated tools catch only 30 to 40% of all issues. A tool can see that an image has no alt text. It cannot tell whether the alt text that is there actually describes the image, or whether the page still makes sense when you navigate it with a keyboard. Those need a person. So a clean automated report is a good sign, not a finish line.
Why pages keep failing
The WebAIM data shows home pages getting heavier every year. The average page in the 2026 scan had 1,437 separate elements, up 22% in a single year. It also found over 130 ARIA attributes per page on average. ARIA is code meant to help accessibility, but pages that used it had more errors, not fewer, because ARIA used wrong makes things worse. More parts, more places to slip.
On a WordPress site, the usual causes are a bloated page builder, a theme that was never tested for accessibility, and a stack of plugins each adding their own markup. The takeaway is not “add more accessibility code.” It is “build simpler pages and get the basics right.”
A five-minute self-check
- Put your mouse away and try to use your site with the Tab key and Enter key only. Can you reach and use every link, button, and form field? Can you always see where you are?
- Look at your lightest text. Can you read it easily at arm’s length, on a phone, in daylight?
- Run your home page through a free checker like WAVE. It will flag most of these six in a few seconds.
- Turn on your phone’s screen reader (VoiceOver on iPhone, TalkBack on Android) and try to get from your home page to your contact form.
How I can help
A free website health check tests your site for all six of these and the rest of the WCAG checklist, by hand as well as with tools. You get a plain list: what fails, where, and how much it matters.
For most sites, fixing the big items is a short, well-defined job. If your site is fighting you at every step, that usually points to a heavier problem in how it was built, and a redesign is the cleaner path. Every site I build is made to meet WCAG 2.2 Level AA from the start.
Sources
- WebAIM, “The WebAIM Million: annual accessibility analysis of the top 1,000,000 home pages” (2026 report)
- WebAIM, “Contrast Checker”
- WebAIM, “WAVE Web Accessibility Evaluation Tool”
- W3C, “How to Meet WCAG (Quick Reference)”