Skip to main content
All articles
Accessibility

The Most Common WCAG Failures (And How to Fix Them)

9 min readBy RedQA Engineering Team

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:

  1. Check your text colours against their backgrounds using a contrast checker (browser DevTools, or the RedQA Scanner)
  2. Darken your text colour, or lighten/darken the background, until the ratio meets 4.5:1
  3. Note: placeholder text in form inputs must also meet contrast requirements
  4. 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 matching id on the input
  • Placeholder text disappears on focus — never use it as the only label
  • If a visible label isn't feasible, use aria-label or aria-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-visible to 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-label to supplement: <a href="..." aria-label="Read more about Playwright automation">Read more</a>
  • For icon-only links — the most common failure — add aria-label to 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.

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