Common Accessibility Issues to Avoid

Why the same accessibility issues keep appearing

Most accessibility barriers are not exotic. Year after year, automated and manual audits surface the same short list of mistakes: missing alt text, low contrast, unlabeled form fields, keyboard traps, and broken structure. They recur because they are introduced silently — a developer ships a new component, a marketer uploads an image, a designer picks a brand color — and nothing in the normal workflow flags the problem. The visual result looks fine to someone using a mouse and a sharp pair of eyes, so the barrier ships.

This catalog walks through the most frequent WCAG 2.2 failures we see in real audits. For each one, you will find why it matters, who it affects, the relevant success criterion, and a concrete before/after fix. Together these issues account for the overwhelming majority of the barriers that block users with disabilities — and the overwhelming majority of the legal complaints filed under the European Accessibility Act, the ADA, and Section 508.

One thing to set straight before the list: automated tools cannot find all of these problems. Independent research consistently shows that even the best scanners reliably detect only 30–40% of WCAG issues. They are excellent at catching missing alt attributes, programmatic contrast failures, and absent form labels, but they cannot judge whether alt text is accurate, whether focus order is logical, or whether a custom widget actually works with a screen reader. That is why every credible program pairs scanning with manual review. Our accessibility scanning software handles the automatable layer; manual audits and audits performed by people with disabilities cover the rest.

A quick way to find your own starting point before reading further: view the page with images disabled, read every word as one unstructured paragraph, and try to complete each task using only a keyboard. Wherever the experience collapses, you have found a barrier.

Perceivable: content people cannot see or read

Missing or inaccurate alt text for images

Who it affects: people who are blind or have low vision and use screen readers; anyone on a slow connection where images fail to load.

WCAG criterion: 1.1.1 Non-text Content (Level A).

Images without an alt attribute are invisible to assistive technology — the user may not even know the image exists. Worse than a missing attribute is an inaccurate one: filenames like IMG_4821.jpg, generic words like “image,” or keyword-stuffed strings actively mislead the listener.

The rule is simple but situational. Informative images need a concise description of their meaning, not their appearance. Decorative images that add nothing should carry an empty alt="" so screen readers skip them. Functional images — an icon that acts as a button — must describe the action, not the picture. Complex visuals such as charts need a short alt plus a longer text equivalent nearby.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Automated tools catch the absence of alt text instantly. They cannot tell you whether the text is correct — that requires a human reading the page in context.

Insufficient color contrast

Who it affects: people with low vision, color blindness, or age-related sight loss; everyone using a screen in bright sunlight.

WCAG criterion: 1.4.3 Contrast (Minimum), Level AA; plus 1.4.11 Non-text Contrast for UI components.

WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (roughly 18pt, or 14pt bold). Interface components and meaningful graphics — input borders, focus indicators, icons that convey state — must meet 3:1 against their surroundings. Contrast failures are among the most common issues found in every large-scale audit, and they are almost always introduced at the design stage.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Test the full palette, not just body copy: placeholder text, disabled states that still need to be read, error messages, and text laid over photographs are frequent offenders. Never rely on color alone to convey meaning (1.4.1) — a red border on an invalid field must be paired with text or an icon.

Auto-playing media and motion

Who it affects: people with vestibular disorders, attention or cognitive disabilities, screen reader users whose audio output is drowned out, and anyone in a quiet shared space.

WCAG criteria: 1.4.2 Audio Control (Level A), 2.2.2 Pause, Stop, Hide (Level A), 2.3.1 Three Flashes (Level A), and 2.3.3 Animation from Interactions (Level AAA).

Audio or video that plays automatically for more than three seconds must offer an obvious way to pause or mute it. Moving, blinking, or auto-updating content that lasts longer than five seconds — carousels, animated banners, marquees — needs an accessible pause control. Content that flashes more than three times per second can trigger seizures and must be avoided entirely. Respect the user’s prefers-reduced-motion setting to tone down non-essential animation.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Operable: things people cannot use

Keyboard inaccessibility and keyboard traps

Who it affects: people with motor disabilities who cannot use a mouse, screen reader users (who navigate by keyboard), and people using switch devices or voice control.

WCAG criteria: 2.1.1 Keyboard (Level A) and 2.1.2 No Keyboard Trap (Level A).

Every interaction — links, buttons, form fields, menus, modals, date pickers, drag-and-drop — must be fully operable with the keyboard alone. The most damaging variant is the keyboard trap: focus enters a component (often a modal or an embedded widget) and cannot get out, stranding the user on the page. Custom-built widgets are the usual culprits because native elements like <button> and <a> are keyboard-operable by default, while <div>-based imitations are not.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Walk your key journeys using only Tab, Shift+Tab, arrow keys, Enter, Space, and Escape. Confirm that focus can always move forward and back out of every component, that Escape closes overlays, and that nothing requires a pointer. Our screen reader evaluation service tests exactly these flows the way real assistive-technology users experience them.

Missing or invisible focus indicators and illogical focus order

Who it affects: sighted keyboard users, low-vision users, and anyone who has lost track of where they are on the page.

WCAG criteria: 2.4.7 Focus Visible (Level A) and 2.4.3 Focus Order (Level A); 2.4.11 Focus Not Obscured (Level AA) in WCAG 2.2.

A common “tidy” mistake is removing the browser’s default focus ring with outline: none and never replacing it. Keyboard users are left with no idea which element is active. Just as harmful is a focus order that does not follow the visual and logical reading order — typically caused by positive tabindex values or by DOM order that diverges from the rendered layout.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 adds 2.4.11: when an element receives focus, it must not be completely hidden behind sticky headers, cookie banners, or chat widgets. Open a modal, tab through it, and confirm the focused element is never buried.

Non-descriptive links and buttons

Who it affects: screen reader users who pull up a list of all links to scan a page, and people with cognitive disabilities.

WCAG criteria: 2.4.4 Link Purpose (In Context), Level A; 2.5.3 Label in Name, Level A.

Screen reader users often navigate by jumping between links out of context. A page full of “click here,” “read more,” and “learn more” links becomes meaningless when read as a list. Link text should describe its destination on its own. The same applies to icon-only buttons, which need an accessible name.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Overloaded navigation and no way to skip it

Who it affects: screen reader users, keyboard users, and people with cognitive disabilities.

WCAG criterion: 2.4.1 Bypass Blocks (Level A).

A mega-menu with dozens of links forces screen reader and keyboard users to wade through the entire list on every page before reaching content. A “Skip to main content” link as the first focusable element lets them jump straight past repeated blocks. Group related items, keep menus lean, and make sure the skip link becomes visible on focus.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Understandable: content that confuses

Unlabeled or improperly associated form fields

Who it affects: screen reader users, people with cognitive disabilities, and voice-control users who address fields by name.

WCAG criteria: 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions, and 4.1.2 Name, Role, Value (all Level A).

Inputs without a programmatically associated <label> are announced as “edit text, blank” — the user has no idea what to type. Placeholder text is not a substitute: it disappears on input and usually fails contrast. Required fields, formatting rules, and validation errors must also be conveyed in text, not by color or position alone.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Tie error messages to their field with aria-describedby, mark invalid fields with aria-invalid, and make sure submitting an incomplete form moves focus to the first error.

Missing page language

Who it affects: screen reader users — the wrong language causes the synthesizer to mispronounce everything.

WCAG criteria: 3.1.1 Language of Page (Level A) and 3.1.2 Language of Parts (Level AA).

A single missing attribute breaks pronunciation for an entire page. Declare the primary language on the root element, and mark inline passages in another language with their own lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Improper heading hierarchy and missing landmarks

Who it affects: screen reader users who navigate by headings and regions, and anyone relying on document structure.

WCAG criterion: 1.3.1 Info and Relationships (Level A).

Headings are the outline of the page. Screen reader users jump heading to heading to find content fast; when levels are skipped, used purely for font size, or absent, that navigation collapses. Each page should have one <h1> and a logical, unbroken sequence of <h2>, <h3>, and so on. Equally important are landmark regions — <header>, <nav>, <main>, <footer> — which let users jump between major areas. A page built entirely from <div> elements offers no such map.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Robust: code assistive tech cannot interpret

Inaccessible custom widgets and misused ARIA

Who it affects: screen reader users above all, and any assistive technology that relies on a correct accessibility tree.

WCAG criterion: 4.1.2 Name, Role, Value (Level A).

Custom dropdowns, tabs, accordions, comboboxes, modals, and tooltips built from <div> and <span> have no inherent role, state, or keyboard behavior. Developers reach for ARIA to patch this, but ARIA only describes — it adds no behavior, and incorrect ARIA is worse than none. The first rule of ARIA is to prefer a native HTML element whenever one exists. When you must build a custom widget, implement the full keyboard interaction the ARIA authoring patterns specify and keep aria-expanded, aria-selected, and similar states in sync with reality.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

These are precisely the issues that automated scanners miss most often. A scanner sees an aria-expanded attribute and passes it; only a human (or a tester using a screen reader) can confirm the value actually flips when the menu opens. See our screen reader testing guide for how to verify widget behavior end to end.

A note on overlay widgets

It is tempting to install a one-line “accessibility widget” or overlay that promises instant compliance. These tools do not fix the issues above — the alt text is still missing in the source, the contrast still fails, the custom widget still breaks. Overlays cannot remediate the code that causes barriers, they frequently interfere with users’ own assistive technology, and they have featured in a growing number of accessibility lawsuits. Real digital accessibility comes from fixing the underlying HTML, CSS, and behavior, not from masking it.

Stop these issues from coming back

Fixing a list of bugs once is necessary but not sufficient; the same issues reappear with the next release unless you change how things ship. The durable fix is to build accessibility into the workflow:

• Catch the automatable 30–40% early by wiring scans into your pipeline. CI/CD accessibility integration fails the build when a regression is introduced, before it reaches production.
• Cover the rest with people. Schedule manual accessibility audits and audits by people with disabilities, who surface barriers no tool can detect.
• Give teams the right instruments. The QualiBooth accessibility toolkit and Agora help designers and developers test as they work.
• Make it a process, not a project. Ongoing accessibility consulting and accessibility process improvement embed the habits so quality holds over time.

For a step-by-step remediation roadmap, start with our guide on how to make your website WCAG compliant.

Where to begin today

With over 1.3 billion people worldwide living with some form of disability, the business case for accessibility is clear — and since June 2025, the legal case under the European Accessibility Act is too. The issues in this catalog are the ones examined first in any complaint or audit.

The fastest way to see where you stand is to run a free URL scan — no setup, no obligation. When you’re ready to go beyond what automation can reach, request a demo and we’ll show you how a combined automated-plus-manual program closes the remaining gap.