Every year, WebAIM analyzes the one million most visited websites in the world for accessibility compliance. Every year, the results are almost identical.

In 2025, 94.8% of homepages had at least one detectable WCAG failure. That number comes from automated tests, which catch only 30 to 40% of real accessibility problems. The true failure rate is considerably worse.

Six error categories account for 96% of all detected failures. The same six. Every year. Since 2019.

None of them are difficult to fix. All of them are decided before a single line of code is written.

01

Contrast

1.1 The most common failure on the web

Low contrast text appears on 79.1% of homepages analyzed by WebAIM in 2025. It has been the top accessibility failure every single year since the study began.

This is an aesthetic decision, made by a designer who looked at a light gray on white background and thought it looked refined. On a calibrated monitor, in a controlled environment, at high resolution, it probably did. For a user with low vision, reading on a cheap screen under sunlight, the text disappears.

Save changes

2.8:1 · fails AA (needs 4.5:1) 7.0:1 · passes AAA

Same text, same background. Only the gray got darker.

1.2 AA and AAA: what they mean and when each applies

WCAG defines contrast requirements across two compliance levels.

Level AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt regular or 14pt bold). This is the baseline for most digital products. If your interface does not meet AA, it fails the most basic legal and ethical standard in most jurisdictions.

Level AAA requires 7:1 for normal text and 4.5:1 for large text. This is the target for interfaces where the user depends critically on reading, such as medical systems, financial platforms, or legal tools.

Most product teams should be designing to AA across the entire interface. AAA is not optional when the stakes of misreading are high. The full breakdown of what separates the two levels, and why disabled buttons usually fail both, lives in AA vs AAA: what these levels actually mean and why your disabled button is failing both.

1.3 The disabled button problem

There is one specific pattern that design systems repeat constantly and nobody questions: the disabled button with reduced opacity.

The convention exists for a reason. Opacity communicates inactivity. But reducing opacity also reduces contrast, often dropping text well below the 4.5:1 minimum. The user with low vision cannot read what the button says. They cannot understand what they need to do to activate it. The interface fails them at exactly the moment they need guidance.

The fix does not require abandoning the convention. It requires adding a second communication channel: a tooltip explaining why the action is unavailable, a label below the button, an icon signaling what is missing. Opacity can stay. The text must remain readable.

Tools like the Colour Contrast Analyser, the Able plugin for Figma, and the WebAIM Contrast Checker let you verify any color pair before it reaches the developer. This is a design decision. It should be tested at the design stage.

02

Color as the only indicator of state

2.1 A story from the daily standup

Early in my career, I worked alongside a backend developer who had been coding professionally for years. We discovered he was colorblind during a completely ordinary conversation. Not during a design review. Not during a handoff. During a daily standup where someone mentioned the color of a teammate's football shirt.

I started paying attention to how he experienced my handoffs. Error states marked with a red border. Success states in green. Warning states in yellow. Three colors, three states, zero additional context. For him, two of those three states were effectively invisible.

He had been compensating silently for years. Working around the interface instead of through it.

Deuteranopia and deuteranomaly, the most common forms of colorblindness, affect the perception of red and green. They affect approximately 8% of men and 0.5% of women. In any team of twelve people, statistically one person has some degree of color vision deficiency. In any product with thousands of users, the number is not marginal.

Normal vision

Deuteranopia simulation

Three form fields, color only. In the simulation, error and success are nearly the same color.

2.2 The fix is always a second channel

Color should never be the only way an interface communicates state. Error fields need a red border and an error icon and a text message explaining what is wrong. Success states need the green confirmation and a written confirmation. Warning states need the color and an explicit label.

None of this requires redesigning the visual language. It requires adding one more layer that does not depend on color perception.

Before committing to any state design, run it through a colorblindness simulator. When I started my career, this meant taking a screenshot, opening Photoshop, and desaturating the image to check contrast. Today, plugins like Stark or Color Oracle do this directly inside the design tool. The manual process was tedious. The modern process takes ten seconds. Neither is hard. Both require the designer to think about it in the first place.

The full taxonomy of color vision deficiency, why red and green collapse before any other pair, and how to audit an entire design system for color-only failures: covered in Designing for color blindness: why red and green are never enough.

03

Keyboard navigation

3.1 Who actually uses the keyboard

Keyboard navigation is the primary interface for users with motor impairments, blind users navigating with screen readers, and a significant number of power users who find the keyboard faster than the mouse.

According to WebAIM's 2024 screen reader survey, 97.6% of screen reader users rely on keyboard navigation. Motor impairments affect roughly 26 million adults in the United States alone, many of whom use keyboards or keyboard-equivalent devices as their primary input.

78% of pages analyzed by WebAIM in 2024 had detectable focus indicator problems. The focus indicator is the visual outline that shows which element currently has keyboard focus. It is, for keyboard users, the equivalent of the mouse cursor. Without it, the user does not know where they are in the interface.

No focus indicator

Visible focus indicator

Tab to these two buttons and compare what happens.

3.2 How to test it in two minutes

Put the mouse down. Open your product. Press Tab.

Observe whether you can see which element has focus at every step. Observe whether you can reach every interactive element, complete every action, and exit every modal or dropdown without touching the mouse once. Observe whether pressing Tab follows a logical reading order or jumps unpredictably across the screen.

If you cannot complete a core user flow using only the keyboard, neither can a significant portion of your users.

3.3 The skip link that even Google does not implement

Every site with navigation repeated across pages should have a skip link. It is a link, visually hidden by default, that becomes visible when the user presses Tab for the first time. It reads something like "Skip to main content." When activated, it moves focus directly past the navigation and into the page content.

Without it, a keyboard user arriving at any page must Tab through every single navigation item before reaching the content. On a site with a header containing eight navigation links, four secondary links, a search field, and a language selector, that is fifteen or more Tab presses before the user reaches anything useful.

The implementation is one anchor link and a few lines of CSS. And yet, as of the time of writing, YouTube (a product built by Google, the organization that wrote many of the web standards that make accessibility possible) does not implement it correctly.

If Google does not catch it, your product probably does not have it either. Add it.

Next: a practical guide to implementing keyboard navigation from scratch, including tab order, focus management inside modals, and skip links, in Keyboard navigation: how to test your product without touching the mouse.

04

ARIA: the tool most designers have never heard of

4.1 What it is and why you probably do not know it exists

ARIA stands for Accessible Rich Internet Applications. It is a specification published by the W3C that defines a set of HTML attributes for communicating the role, state, and properties of interface elements to assistive technologies.

aria-label gives a name to an element that does not have visible text. aria-expanded tells a screen reader whether a dropdown or menu is currently open or closed. aria-describedby associates a form field with its error message so the screen reader reads both together.

This is a technical implementation detail. Most designers will never write an ARIA attribute directly. I did not know the acronym existed until several years into my career, and that is not unusual given how specific the contexts that require it tend to be.

But here is the part that does involve the designer.

4.2 What the designer specifies that makes ARIA necessary

When you design a modal, you are making decisions about how it behaves. When it opens, focus should move inside it. When it closes, focus should return to the element that triggered it. While it is open, keyboard focus should be contained within it so the user does not accidentally interact with content behind the overlay.

That behavior is specified in design. If the designer documents it, the developer knows to implement it. If the designer does not document it, the developer often does not know it needs to exist.

ARIA is what makes that behavior readable to assistive technologies. The designer does not write the attribute. The designer decides the behavior that requires the attribute. That distinction matters.

Pages that use ARIA have on average 34% more accessibility errors than pages without it. The reason is not that ARIA is bad. It is that ARIA is frequently implemented incorrectly, often because nobody specified how it should behave in the first place.

A practical note for anyone who is a developer reading this: if your designer did not specify focus behavior in their documentation, that is a gap, but it does not mean you cannot implement it correctly anyway. Knowledge travels in both directions.

Roles, states, properties, the first rule of ARIA, and how to document interactive behavior so a developer implements it correctly the first time: all covered in What is ARIA and why product designers need to understand it.

05

The wrong component

5.1 Component choice is an accessibility decision

A dropdown with two options is an accessibility failure, not just a UX inefficiency.

A keyboard user opening a dropdown must navigate to the trigger, open it, move through the options with arrow keys, select one, and close. A toggle accomplishes the same goal in a single interaction. The wrong component multiplies the work for every user who cannot use a mouse, and it does so invisibly, because nobody tested the flow with a keyboard.

5 keyboard interactions to change

1 keyboard interaction to change

Same choice, same result. One takes five key presses, the other takes one.

The component choice is made in design. So is the accessibility consequence.

Other common cases where the wrong component breaks accessibility before the developer writes a line of code:

  • Using a <div> as a button. A <div> does not receive keyboard focus by default. A <button> does. When a designer specifies a clickable area without specifying that it must be a semantic button element, developers sometimes build it as a <div> with a click event. The result looks identical on screen and is completely inaccessible by keyboard.
  • Using placeholder text as a label. Placeholders disappear when the user starts typing. A user who needs to check what a field is asking for mid-input has no way to recover that information. Labels must be visible and persistent.
  • Using icon-only buttons without alternative text. An icon button with no label is invisible to a screen reader. The user knows a button exists. They do not know what it does. Every icon-only interactive element needs a text alternative, whether visible or not.

Still to come: a component-by-component breakdown of common accessibility failures in design systems, and how to write component documentation that prevents them at the implementation stage, in Component decisions that break accessibility before the developer writes a line of code.

The same six errors. Every year.

WebAIM has run its analysis of the top one million websites every year since 2019. In six years, the overall failure rate has improved by 3.1 percentage points. At that rate, achieving broad accessibility compliance would take decades.

The six error categories that account for 96% of all failures are not complex. They are not obscure edge cases requiring specialist knowledge. They are contrast, missing alt text, missing form labels, empty links, missing document language, and focus visibility. All of them traceable to decisions made before the first line of code existed.

Accessibility is a consequence of what was decided in the design file, the component library, the design system documentation, and the behavior specifications handed to engineering, not a QA task or a developer responsibility to retrofit after design is finished.

The decisions are made at the design stage. The failures appear in production. The gap between the two is where most products live permanently.

Sources