6 Common WCAG Failures and How to Fix Them

This article covers the 6 most common WCAG failures and clear fixes you can apply today. Read the test steps, code examples, and quick checklists for each failure so you can reduce risk fast.

At a glance: the six failures

• Low contrast text and UI elements
• Missing or empty alt text for images
• Missing form labels or inaccessible inputs
• Poor keyboard access and missing focus visibility
• Non-descriptive or empty link and button text
• Missing captions or transcripts for time-based media

Failure 1 — Low contrast text and UI elements

Why it fails

Insufficient contrast makes content unreadable for low vision users and for people in bright environments. WCAG requires minimum contrast between text and its background. Designers sometimes use faint greys or place text over images without checking contrast.

How to test

• Use a contrast checker that supports WCAG 2.1 levels to test text and UI controls.
• Test normal text, large text, and graphic objects such as icons and focus outlines.
• Check against both light and dark themes if your site supports them.

How to fix

• Increase text or background contrast until it meets WCAG minimums. For small text aim for the contrast ratio required for normal text.
• For icons or strokes, ensure non-text contrast is addressed or provide an accessible name for the control.
• Prefer changing colors in CSS rather than shrinking font size. If an image contains text, provide an accessible alternative.

Example CSS for focus outlines

Use the browser-native focus ring or add a clear outline so keyboard users can see focus.

<style> :focus-visible { outline: 3px solid #005a9c; outline-offset: 2px; } </style>

Failure 2 — Missing or empty alt text for images

Why it fails

Images without an alt attribute create gaps for screen reader users. Decorative images need empty alt attributes so assistive tech can skip them. Informative images require concise alt text that conveys the same information as the image.

How to test

• Run an accessibility scan to find images with missing alt attributes.
• Manually review images that appear to carry meaning: charts, diagrams, product photos, buttons with icons.
• Listen with a screen reader to confirm meaningful images are announced correctly and decorative images are skipped.

How to fix

• If the image is informative, add a short, specific alt attribute that describes the image purpose.
• If the image is decorative, include alt=“” so it is ignored by assistive tech.
• For complex images like charts, provide a longer description nearby or use aria-describedby to point to the description.

Examples

<img src=“product.jpg” alt=“Black leather jacket, front view”>

<img src=“ornament.png” alt=“”>

Failure 3 — Missing form labels or inaccessible inputs

Why it fails

Inputs without labels are invisible to screen reader users. Label elements connect text to controls. Some teams hide labels visually but keep them for accessibility. Others remove labels and try to use placeholders, which are not replacements.

How to test

• Use an automated tool to find inputs missing label elements or accessible names.
• Test forms with a screen reader to ensure each field announces a name and purpose.
• Check that error messages are programmatically associated with the correct field.

How to fix

• Prefer the native <label> element for inputs. Use the for attribute that matches the input id.
• If a visual layout requires the label elsewhere, keep the label in the DOM and hide it visually using accessible methods.
• Use aria-label or aria-labelledby only when a visible label cannot be used.

Code examples

<label for=“email”>Email address</label> <input id=“email” name=“email” type=“email” required>

<button aria-label=“Close dialog”><svg>…</svg></button>

Failure 4 — Poor keyboard access and missing focus visibility

Why it fails

Keyboard users need to reach every interactive control. Custom widgets often break native keyboard behavior. Some styles remove visible focus which leaves users guessing where they are on the page.

How to test

• Tab through pages using only a keyboard to find traps or unreachable controls.
• Check modal dialogs, menus, and custom components for proper keyboard handling and focus management.
• Confirm focus order follows the visual order and that focus is visible at all times.

How to fix

• Use native elements when possible: <button> for buttons, <a> for links.
• Do not use positive tabindex values. Use tabindex=“-1” only for programmatic focus targets.
• Implement keyboard handlers that match expected behavior for the component. Ensure focus moves into and out of modal content correctly.

Failure 5 — Non-descriptive or empty link and button text

Why it fails

Links or buttons that read “click here” or contain only an icon do not convey purpose when taken out of context. Screen reader users often get a list of links and need each link to be meaningful on its own.

How to test

• Use a link list view in a screen reader to hear whether links are descriptive.
• Run an audit to find anchors with no text or with redundant phrases like “read more” without context.

How to fix

• Make link text describe the target. Replace “click here” with the destination name or action.
• For icon-only controls, add an accessible name with aria-label or include visually hidden text.

Example

<a href=“/privacy”>Privacy policy</a>

<button aria-label=“Open notifications”><svg>…</svg></button>

Failure 6 — Missing captions or transcripts for time-based media

Why it fails

People who are deaf or hard of hearing need captions for audio content. People with cognitive disabilities or those in noisy environments benefit from transcripts. WCAG requires captions for prerecorded video and calls out other requirements for live audio.

How to test

• Play each video and check whether captions are available and accurate.
• Verify that transcripts are provided for audio-only content or long videos.

How to fix

• Add accurate captions to prerecorded video. Use SRT, VTT, or an embedded track element.
• Provide a full transcript for videos that include important audio information not available in captions.
• For live audio, consider live captioning services or provide alternatives when live captions are not possible.

How to prioritise fixes and track progress

Start with issues that affect many users and are quick to fix. Contrast and missing labels often deliver high impact for low effort. Use a simple priority grid: High impact, low effort first; high impact, high effort next.

Suggested immediate actions

• Fix missing labels and image alt attributes across main entry pages.
• Ensure focus is visible and tabbable controls work on key workflows like sign in and checkout.
• Add captions for any high-traffic video content.

Quick audit checklist

• Run an automated scan, then manually test with a keyboard and a screen reader.
• Check contrast on the primary theme and any alternative themes.
• Confirm every image has either meaningful alt text or alt=“” for decoration.
• Ensure every form control has a label and error messages are associated with fields.
• Verify link and button text makes sense out of context or has an accessible name.
• Provide captions for prerecorded video and transcripts where needed.

Fixing these six areas will remove many common barriers. Use the code examples and checklists above to guide developers and designers. Repeat tests after each change to confirm the issue is resolved and regressions do not reappear.