Every year, WebAIM runs automated accessibility tests on the home pages of the top one million websites. In 2025, 94.8% had detectable WCAG failures, with an average of 51 errors per page (WebAIM).
That number sounds hopeless until you read the next line. Just six types of issue account for roughly 96% of all the errors detected. Accessibility is a big subject, but the most common failures are small, repetitive and, in most cases, decided at the design stage.
The six recurring errors
1. Low-contrast text
The single most common problem. Light grey body copy, white text on a pale photo, pastel buttons with white labels. WCAG AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.
Design fix: define accessible colour pairs in your tokens once, and only use those pairs for text. Check captions and placeholder text too; they are frequent offenders.
2. Missing alternative text
Images that convey information need a text alternative. Decorative images should be marked as decorative so screen readers skip them.
Design fix: decide during design which images are meaningful, and write the alt text in the handoff notes, not as an afterthought during upload.
3. Missing form labels
Placeholder text disappears as soon as someone starts typing and is not a reliable label. Every input needs a visible, programmatically connected label.
Design fix: design forms with visible labels above fields, and show error messages as text next to the field, not just a red border.
4. Empty links
Icon-only links, such as social icons or a logo link, with no accessible name. A screen reader announces “link” and nothing else.
Design fix: include the accessible name in the component spec, for example “RoundPatch on LinkedIn”.
5. Empty buttons
The same problem for buttons: a hamburger menu, a close icon, a carousel arrow.
Design fix: every icon button in the design system gets a named label in its documentation.
6. Missing document language
A one-line code fix that helps screen readers pronounce content correctly. Easy to automate; easy to forget.
Why this is a design problem first
Look at the list again. Contrast, alt text, labels and button names are all decided before a developer writes a line of code. Fixing them in the design file costs minutes. Fixing them after launch means tickets, regression testing and, increasingly, legal risk.
That risk is real. The European Accessibility Act began enforcement on 28 June 2025, covering many consumer-facing digital products and services sold in the EU, with standards aligned to WCAG 2.1 AA (DWT). In the US, digital accessibility lawsuits continue to be filed in large numbers.
Widgets are not a shortcut
Accessibility overlays promise instant compliance with a line of JavaScript. They do not change the underlying design or code. UsableNet’s 2024 year-end report found that more than 1,000 businesses were sued despite having an accessibility widget installed, over a quarter of the cases it tracked (UsableNet).
Where AI helps
AI tools are becoming useful accessibility assistants:
- drafting alt text for large image libraries, for a person to review;
- flagging contrast failures across a design file or a whole site;
- checking that every form field and icon button has a label;
- summarising automated audit results into prioritised tickets.
What they cannot do is judge whether an experience is actually usable with a keyboard or a screen reader. Automated checks catch a meaningful share of issues, but not all. Manual testing, ideally including disabled users, is still essential.
A practical checklist
- Accessible colour pairs built into your design tokens
- Visible labels and text error messages on every form
- Alt text decided in design, not at upload
- Every icon link and button has a name in the spec
- Focus states designed, not left to browser defaults
- Automated checks in QA, plus a manual keyboard and screen reader pass before launch
The takeaway
Most accessibility failures are not complex engineering problems. They are small design decisions made the same wrong way, over and over. Fix them in the design system once and every future page benefits.
We build accessibility into our UI/UX and website work from the first wireframe. For the QA side, see our guide to AI-assisted website QA.
