Why the same WCAG failures appear everywhere
After running hundreds of accessibility scans and audits, certain failure patterns appear again and again. They're not the result of carelessness — they're the result of accessibility being treated as an afterthought rather than a design and development standard. The good news: the most common failures are also among the most straightforward to fix.
1. Insufficient colour contrast
WCAG criterion: 1.4.3 Contrast (Minimum) — Level AA
Requirement: 4.5:1 contrast ratio for normal text, 3:1 for large text (18pt+, or 14pt bold+)
Why it fails: Designers often choose aesthetically pleasing, low-contrast colour combinations — light grey text on white, or pastel-on-pastel — without checking contrast ratios.
How to fix it:
- Check your text colours against their backgrounds using a contrast checker (browser DevTools, or the RedQA Scanner)
- Darken your text colour, or lighten/darken the background, until the ratio meets 4.5:1
- Note: placeholder text in form inputs must also meet contrast requirements
- Add contrast ratio checking to your design system tokens — enforce it at the component library level
2. Images without alt text
WCAG criterion: 1.1.1 Non-text Content — Level A
Requirement: Every image that conveys information must have descriptive alt text. Decorative images must have alt="".
Why it fails: Developers forget to add it, or CMS systems default to empty or filename-based alt text.
How to fix it:
- Descriptive images: write alt text that conveys the same information a sighted user gets — describe the content and function, not the appearance
- Decorative images: use
alt=""(empty string) — not alt text describing the image, which just creates noise - Logo images: alt text should be the organisation name, not "logo"
- Complex images (charts, graphs): provide a text description or data table alongside the image
3. Form inputs without labels
WCAG criterion: 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions — Level A
Requirement: Every form input must have an accessible label associated with it.
Why it fails: Placeholder text is mistaken for a label. Visual labels aren't programmatically associated with their input.
How to fix it:
- Use
<label for="inputId">pointing to the matchingidon the input - Placeholder text disappears on focus — never use it as the only label
- If a visible label isn't feasible, use
aria-labeloraria-labelledby - Group related inputs (radio buttons, checkboxes) with
<fieldset>and<legend>
4. Keyboard traps
WCAG criterion: 2.1.2 No Keyboard Trap — Level A
Requirement: Users must be able to navigate away from any component using only the keyboard.
Why it fails: Modals, date pickers, and custom dropdown components often trap focus inside them without providing an escape route.
How to fix it:
- Modals: implement a focus trap within the modal (intentional — the modal is the current context), but provide an obvious close mechanism and restore focus to the trigger element when closed
- Ensure Escape key closes modals and dropdowns
- Test every interactive component with keyboard-only navigation before shipping
5. Missing focus indicators
WCAG criterion: 2.4.7 Focus Visible — Level AA
Requirement: The keyboard focus indicator must be visible.
Why it fails: CSS resets (e.g. outline: none or outline: 0) remove browser default focus styles without replacing them.
How to fix it:
- Never use
:focus { outline: none }without replacing it with a custom focus style - Use
:focus-visibleto show focus styles only for keyboard navigation (not mouse click) — but ensure the fallback still shows something for browsers that don't support it - WCAG 2.2 adds requirements on focus indicator size and contrast — aim to meet those standards
6. Non-descriptive link text
WCAG criterion: 2.4.4 Link Purpose (In Context) — Level AA
Requirement: Link text must describe the purpose of the link, either from the text alone or from its surrounding context.
Why it fails: Templates and CMSs generate "Read more", "Click here", or "Learn more" links where multiple links on a page have identical text but different destinations.
How to fix it:
- Replace generic link text with descriptive text: "Read more about Playwright automation" instead of "Read more"
- If the surrounding context makes the purpose clear, use
aria-labelto supplement:<a href="..." aria-label="Read more about Playwright automation">Read more</a> - For icon-only links — the most common failure — add
aria-labelto the anchor element
Run the RedQA Accessibility Scanner to identify which of these failures are present on your site, and visit the How to Fix guide for full remediation details on every issue category.
Related articles
The European Accessibility Act 2025: What Your Business Must Do Now
The European Accessibility Act came into force in June 2025. Here's exactly what it requires, who it applies to, and the steps UK and EU businesses must take immediately.
What is WCAG 2.2? A Complete Guide for 2026
WCAG 2.2 became a W3C Recommendation in October 2023. This guide covers all nine new success criteria, what changed from WCAG 2.1, and what your team needs to do.
How to Run a Free Website Accessibility Audit in 5 Minutes
You can get a detailed WCAG 2.1 accessibility report on any website in under 5 minutes using free tools. Here's exactly how.
Ready to Ship with Confidence?
Let's discuss how RedQA can help you deliver better software, faster. Get a free consultation and quote tailored to your project.
Get a Free Quote