The 10 Accessibility Errors Found on Almost Every Website (And How to Fix Them)

The same errors, on almost every site

Accessibility audits involve hundreds of potential issues, but the errors that show up most reliably across sites follow a predictable pattern. They're not the obscure ones a specialist might catch — they're structural, systemic, and the result of design and development patterns that have been standard practice without enough attention to their impact.

The WebAIM Million, an annual accessibility analysis of the top one million homepages, consistently finds that the overwhelming majority of pages have detectable WCAG failures. The most common errors cluster around the same issues every year.

This article covers the ten most frequently encountered errors, what they mean for users who depend on assistive technology, and exactly what to do to fix them. All referenced tools are free to use.

1. Low contrast text

What it is: Text that doesn't have enough contrast against its background to be readable by users with low vision or colour deficiency.

WCAG criterion: 1.4.3 Contrast (Minimum) — Level AA. Normal text requires a 4.5:1 contrast ratio, large text requires 3:1.

How to find it: Run your page through the free WAVE tool (wave.webaim.org) or use the Colour Contrast Analyser (free desktop app from TPGi). Browser DevTools also include contrast readings in the colour picker.

How to fix it: Increase contrast between text and background colours. Typical failures include grey text on white, light text on medium-background images, and low-opacity placeholder text. Most design systems can be adjusted at the token or variable level so one change propagates throughout.

2. Missing alt text on images

What it is: Images without an alt attribute, or with alt="" used on informational images that fail to convey meaning to screen reader users.

WCAG criterion: 1.1.1 Non-text Content — Level A.

How to find it: WAVE flags missing alt attributes directly. Screaming Frog crawl reports also export alt text by image URL so you can audit at scale.

How to fix it: Every image needs an appropriate alt attribute:

Informational images: write a description of what the image shows and why it's there ("Photo of the Accessible Entry at City Hall with the ramp visible at street level")

Decorative images: use alt="" (empty, not absent) so screen readers skip it

Images of text: include the full text content in the alt attribute

Functional images (icons, buttons with image backgrounds): describe the function ("Open primary navigation menu")

3. Missing or incorrect form labels

What it is: Form fields (text inputs, selects, checkboxes, radio buttons) that aren't programmatically associated with their visible label. Screen readers announce form fields by their label — if there's no label, or the association is broken, the user hears "edit text" or nothing useful.

WCAG criterion: 1.3.1 Info and Relationships — Level A; 4.1.2 Name, Role, Value — Level A.

How to find it: Tab through your forms with a keyboard and watch what a screen reader announces. WAVE highlights unlabeled form controls. In browser DevTools, select a form field and inspect whether it has an associated <label> element (via for/id pairing) or aria-label / aria-labelledby.

How to fix it: Add a <label> element with a matching for attribute pointing to the field's id. Avoid placeholder-only labeling — placeholder text disappears when the user starts typing and is not a reliable label substitute. Visible labels are better for all users.

4. Empty or uninformative link text

What it is: Links whose visible text gives no indication of destination or purpose: "Click here," "Read more," "Learn more." Screen reader users often navigate by tabbing through links, hearing only the link text. "Read more" repeated twelve times tells them nothing.

WCAG criterion: 2.4.4 Link Purpose (In Context) — Level A; 2.4.9 Link Purpose (Link Only) — Level AAA.

How to find it: WAVE lists all links. Filter for links with non-descriptive text. Screaming Frog's crawl report includes anchor text.

How to fix it: Rewrite link text to describe its destination: "Read our 2024 accessibility audit findings" instead of "Read more." For icon-only links (social media icons, PDF download buttons), add an aria-label attribute with descriptive text.

5. Missing document language

What it is: The <html> element not having a lang attribute specifying the language of the page's content. Screen readers use this to select the correct pronunciation engine. Without it, the reader may mispronounce content or switch incorrectly.

WCAG criterion: 3.1.1 Language of Page — Level A.

How to find it: View page source and check the opening <html> tag. It should include lang="en" (or another appropriate language code). WAVE flags this as a structural error.

How to fix it: Add lang="en" to the <html> element in your site's base template. In most CMS platforms, this is set once in a global template file or site settings. If sections of the page use a different language, add lang="fr" (or appropriate code) to those specific elements.

6. Missing skip navigation link

What it is: No mechanism for keyboard users to skip past repeated navigation blocks at the top of the page to reach the main content directly. Without a skip link, keyboard and screen reader users must tab through every navigation item on every page load before they can reach any content.

WCAG criterion: 2.4.1 Bypass Blocks — Level A.

How to find it: Press Tab immediately after loading any page. If the first focus target isn't a skip link ("Skip to main content" or similar), the criterion is likely unmet.

How to fix it: Add a visually hidden skip link as the first element in the <body>:

<a href="#main-content" class="skip-link">Skip to main content</a>

Add CSS to make it visible only on focus:

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
}
.skip-link:focus {
  top: 0;
}

Ensure the main content area has id="main-content" so the skip link lands correctly.

7. Focus indicator removed or invisible

What it is: The visible outline that appears around an interactive element when it receives keyboard focus has been removed or made invisible, often with outline: none or outline: 0 in the site's CSS.

WCAG criterion: 2.4.7 Focus Visible — Level AA; 2.4.11 Focus Appearance — Level AA (new in WCAG 2.2).

How to find it: Tab through your site without using a mouse. If you can't see which element has focus at any point, focus visibility is broken.

How to fix it: Remove outline: none from global CSS unless a visible alternative focus style is provided. A custom focus style can be more on-brand than the browser default:

:focus-visible {
  outline: 3px solid #0057B8;
  outline-offset: 2px;
}

Using :focus-visible (rather than :focus) prevents the outline from appearing during mouse clicks while keeping it visible for keyboard navigation.

8. Keyboard traps

What it is: A component or section of the page where focus enters but cannot leave using only the keyboard (Tab, Shift+Tab, arrow keys, Escape). Modals, date pickers, and custom dropdowns are common trap locations.

WCAG criterion: 2.1.2 No Keyboard Trap — Level A.

How to find it: Tab through any modal, dialog, or overlay on your site. You should be able to exit it with Escape and have focus return to the trigger element.

How to fix it: Properly implemented focus management is required for any modal or dialog:

Pressing Escape must close the dialog and return focus to the element that opened it

Focus should be trapped within the dialog while it's open (Tab cycles through dialog content, not the page behind it)

When the dialog closes, focus must return to the triggering element

Most modern component libraries handle this correctly when used as documented. Custom implementations often don't.

9. Auto-playing audio or video with no controls

What it is: Media that begins playing automatically when a page loads, with no mechanism to pause it, stop it, or reduce its volume within three seconds.

WCAG criterion: 1.4.2 Audio Control — Level A.

How to find it: Load your pages and listen. Check any embeds, background videos, promotional media blocks, or looping animations with audio.

How to fix it: Either don't autoplay audio-present media, or provide visible, keyboard-accessible controls to pause and mute it within three seconds of load. Background videos that loop silently are generally acceptable, but the muted attribute must be set in the HTML and remains set (some implementations remove muted state through JavaScript after load).

10. Inaccessible PDF links without alternatives

What it is: Links pointing to PDFs that haven't been tagged for accessibility. Untagged PDFs give screen readers no reading order, no heading structure, and no way to navigate. Users who depend on screen readers may receive an unordered dump of text or nothing at all.

WCAG criterion: 1.1.1, 1.3.1, 4.1.2 — Level A.

How to find it: Download the PDF and run it through Adobe Acrobat's built-in accessibility checker (File → Accessibility Check) or PAC 3 (free tool from PDF UA Foundation).

How to fix it: The fix depends on the PDF. For PDFs created from Word or InDesign, enable accessibility features at export time (Acrobat tags, reading order, alt text on images). For scanned documents, the original scan needs to be run through OCR and then tagged. For complex forms and tables, manual tagging in Acrobat Pro is often required.

For PDF-heavy organizations (government bodies, financial institutions), a longer-term strategy is to convert structured information to accessible HTML pages rather than relying on PDFs for primary communication.

Running your own quick audit

You don't need an expert to find most of these. Run through this ten-minute check on any page:

Open WAVE (wave.webaim.org) — paste your URL and review errors and alerts

Tab through the page — check for visible focus, skip link presence, and keyboard traps

Load the page in a screen reader — NVDA (Windows, free) or VoiceOver (macOS/iOS, built-in) — listen to how images, links, and forms are announced

Check the HTML source for lang="en" on the <html> element

Download any linked PDFs and run the Acrobat accessibility checker

These five steps won't catch everything, but they'll surface the most common issues.

If your team is ready to go beyond the basics and build accessibility into your publishing workflow, get in touch and we can build a plan that fits your content team's capacity.