accesspatched

Research

The 6 mistakes behind 96% of accessibility failures (and how to fix each)

Published 16 July 2026

The most common accessibility issues on the web are not a sprawling, hopeless list. Just six error types account for 96% of all detected failures across a million home pages (WebAIM Million, 2025). If you fix these six, you clear the large majority of what any automated scan will ever flag on your site. Here is each one: what it is, what it does to a real person, and how it actually gets fixed.

Two things before the list. First, none of these are exotic. They are ordinary oversights that pile up because nobody tested with the tools disabled customers use. Second, most of the fixes are small: attribute changes and CSS values, not rewrites. That is the encouraging part of an otherwise grim set of 2025 statistics.

1. Low-contrast text

This is the most common failure of all, found on 79.1% of home pages (WebAIM, 2025). It means text that does not stand out enough from the colour behind it: pale grey on white, a brand colour used for body copy, a caption laid over a busy photo. It hurts people with low vision, and frankly anyone reading on a phone in daylight.

How to fix it

Meet the WCAG contrast ratio, which is 4.5 to 1 for normal-size text and 3 to 1 for large text. Run your palette through a contrast checker, then adjust the colour values until they pass. This is usually a small change to a few hex codes rather than a redesign, and it often improves the look for everyone, not just the people who strictly need it.

2. Missing alternative text for images

An image with no text alternative is invisible to a screen reader, which will announce "image" or read out the file name. For a product photo that means the shopper hears nothing useful about the thing they are considering buying. Missing alt text was one of the top frustrations reported in a study of 100 blind screen reader users, and it remains everywhere (Lazar et al., 2007).

How to fix it

Give every meaningful image an alt attribute that describes its purpose, not its file name. For a product, describe the product. For an image that is purely decorative, mark it as such with an empty alt="" so the screen reader skips it cleanly rather than reading noise. The test is simple: if the image vanished, what would the user need to be told in its place?

3. Missing form input labels

A form field with no programmatic label leaves a screen reader user hearing "edit text" and nothing else. On a checkout that is the difference between filling in an address and abandoning the order. Poorly designed and unlabelled forms were another leading source of frustration in the Lazar study, and they sit directly on your path to purchase (Lazar et al., 2007).

How to fix it

Associate a proper <label> element with every input, tied to it by for and id. Do not rely on placeholder text as a label: placeholders disappear the moment someone starts typing, and many screen readers do not treat them as names. Where a visible label does not fit the design, use aria-label, but a real visible label is better for everyone.

4. Empty links

A link with no readable text, often an icon-only link like a cart or a social button, is announced simply as "link" with no hint of where it goes. The user has to guess or give up. Misleading and meaningless links were, again, among the top frustrations blind users reported (Lazar et al., 2007).

How to fix it

Give every link readable text that describes its destination. For an icon-only link, add visually hidden text or an aria-label so the destination is spoken, for example "View basket" rather than an unlabelled cart glyph. Avoid vague "click here" links too: they read as a meaningless list when a screen reader user pulls up all links on a page.

5. Empty buttons

A button with no text is announced as "button", full stop. The classic offender is an icon-only add-to-cart or menu control. If the shopper cannot tell which button buys the product or opens the menu, they are gone. This is the interactive twin of the empty-link problem, and it lands on exactly the controls that make you money.

How to fix it

Give every button an accessible name that says what it does. If it shows only an icon, add visually hidden text or an aria-label, for example "Add to basket". If it is a real <button> wrapping an icon, that label is all it needs. Make sure you are using genuine button elements too, because a clickable <div> brings its own set of keyboard and screen reader problems.

6. Missing document language

If a page does not declare its language, a screen reader may pronounce the content with the wrong accent and rules, reading Dutch as though it were English or vice versa. It can sound like gibberish, which quietly makes the whole page harder to trust and follow.

How to fix it

Set a single attribute on the <html> element declaring the page's language, for example lang="en". It is one of the cheapest fixes in this list and it applies to the entire document at once. If parts of the page are in another language, mark those sections with their own lang attribute.

Why these six dominate the data

Here is the catch worth naming. These six are exactly the kinds of problems an automated tool is good at catching, which is part of why they dominate a study that is itself automated. Fixing them is real, valuable work and it clears the machine-detectable floor. But it is not the whole job.

The harder issues, like whether the reading order makes sense, whether focus is managed properly in a modal, or whether a task can actually be completed end to end, need a human tester, because automated scans catch only about a third of what matters. Think of the six as the floor you clear first, not the finish line. Clearing them well, though, is the single highest-leverage day of accessibility work most shops can do.

Common questions

What are the most common accessibility issues on websites?

Across a scan of a million home pages, the six most common were low-contrast text, missing alternative text, missing form input labels, empty links, empty buttons, and missing document language. Together they account for 96% of all detected failures, with low contrast alone on 79.1% of pages (WebAIM, 2025).

If I fix these six, is my site accessible?

You will have cleared the majority of automatically detectable errors, which is a strong start. But automated tools only find part of the picture, so real accessibility still needs manual testing with a keyboard and screen reader to confirm that key tasks can actually be completed.

That combination is what we do at AccessPatched: we audit your site against WCAG-EM, fix the six common failures and everything a manual screen-reader pass turns up, deliver the corrections as pull requests your team can review and merge, and issue an EN 301 549 conformance statement at the end. It is the practical version of everything on this page, and you can see the rest of what we handle on our services page.

See where your own shop stands. Our free scan runs the same automated checks a regulator's tester starts with, then a human goes through your site with a screen reader and emails you the findings, in plain language. If your shop passes, we say so.

Get a free scan

Sources

Back to all research