The 2026 WebAIM Million report landed this week, and the headline figure is depressing: 95.9% of the top one million homepages have detectable WCAG failures. That's not a typo. Nearly every website audited has at least one accessibility barrier that automated tools can catch.
But here's what caught my attention in the analysis from The Visual Communication Guy: most of these failures aren't development bugs. They're design decisions.
The six most common failures are design problems
WebAIM's data shows the same issues appearing year after year:
- Low contrast text (WCAG 1.4.3) – 81% of homepages
- Missing alternative text for images (WCAG 1.1.1) – 54.5% of homepages
- Empty links (WCAG 2.4.4) – 48.6% of homepages
- Missing form input labels (WCAG 1.3.1, 3.3.2) – 45.9% of homepages
- Empty buttons (WCAG 2.4.4) – 27.5% of homepages
- Missing document language (WCAG 3.1.1) – 17.1% of homepages
Look at that list. Low contrast text is a colour choice made in Figma. Missing alt text happens when designers don't specify image descriptions in their handoff notes. Empty links and buttons often result from icon-only designs with no text equivalent planned.
Developers inherit these problems. They build what's in the design file. If the design specifies #999999 text on a white background, that's what gets coded. If the mockup shows a magnifying glass icon with no label, that's what ships.
Why design education skips accessibility
Most design courses treat accessibility as an afterthought, if they cover it at all. The focus is on visual aesthetics, user flows, and portfolio presentation. WCAG doesn't feature in many curricula.
The result: designers make decisions that look polished but exclude users. A light grey caption might feel elegant. A minimalist icon-only navigation might look clean. But these choices create barriers for people with low vision, cognitive disabilities, or those using screen readers.
This isn't about blame. It's about where to intervene. If you want fewer accessibility bugs in production, you need to catch them earlier in the process.
What to check in your design files
Before any design goes to development, verify these specifics:
Colour contrast
WCAG 1.4.3 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Use a contrast checker plugin in your design tool. Figma, Sketch, and Adobe XD all have them.
Test every text/background combination. Don't forget placeholder text in forms, captions, timestamps, and disabled states. These are often where contrast fails.
Image descriptions
Every meaningful image needs alt text specified in the design handoff. Create a column in your design documentation: Image > Purpose > Alt text.
Decorative images (backgrounds, visual flourishes) should be marked as decorative so developers know to use alt="". Functional images (icons that trigger actions) need text that describes the action, not the icon.
Interactive element labels
If your design shows an icon-only button, specify the accessible name. A search button with just a magnifying glass needs a label like "Search" that screen readers can announce.
Same for links. If a card has a "Read more" link, the accessible name should include context: "Read more about our pricing plans" or use aria-labelledby to connect it to the card heading.
Form field labels
Every input needs a visible label. Placeholder text doesn't count—it disappears when users start typing and isn't reliably announced by all screen readers.
Design the label into the layout. If you're using floating labels, ensure the label remains visible after the field is filled.
Build accessibility into your design review process
Add a checklist to your design sign-off:
- [ ] All text meets WCAG 1.4.3 contrast ratios (checked with plugin)
- [ ] Alt text specified for all meaningful images
- [ ] Accessible names defined for icon-only controls
- [ ] All form fields have visible labels
- [ ] Focus states designed for interactive elements
- [ ] Touch targets are at least 44×44 CSS pixels (WCAG 2.5.5)
This takes ten minutes per design. It saves hours of remediation later.
Developers: push back on inaccessible designs
If you receive a design with #AAAAAA body text, flag it before you build it. Show the designer the contrast ratio. Most will appreciate the catch.
Create a shared understanding with your design team: accessibility requirements aren't optional extras. They're constraints like browser support or responsive breakpoints. Build them into the process, not around it.
The 95.9% failure rate won't change until we stop treating accessibility as a development-only concern. The fix starts upstream, in the design file, before a single line of code gets written.
WCAGCheck scans your website for WCAG compliance issues and tells you exactly what to fix. Try it free at wcagcheck.co.uk