Top 10 ADA Accessibility Mistakes Developers Make

Why These Mistakes Keep Appearing

Accessibility failures are rarely the result of malice — they are the result of a development culture that treats accessibility as an afterthought. Most developers are never taught WCAG in school. Accessibility is absent from the default output of many popular component libraries. And quick visual reviews miss issues that only surface when you tab through the page or use a screen reader.

These ten mistakes appear in the vast majority of web accessibility audits. Learning them is the fastest way to improve a codebase's baseline compliance.

1. Missing or Incorrect Alt Text on Images

Failing WCAG criterion 1.1.1. The most common: no alt attribute at all (which causes screen readers to read the filename), or an empty alt="" on an image that actually conveys meaning. The fix: every <img> needs an alt. Decorative images get alt="". Informative images need a concise, meaningful description.

2. Using Placeholder Text as a Form Label

Placeholder text disappears when a user starts typing, is not read by all screen readers, and typically fails contrast requirements. It is never a substitute for a <label> element. The fix: always pair each input with a visible <label for="inputId">, or use aria-label as a fallback when a visible label is not feasible.

3. Interactive Elements Not Reachable by Keyboard

Custom dropdowns, date pickers, modal dialogs, and carousels built without keyboard support exclude a significant portion of users. Common failure patterns: onclick on a <div> without a corresponding keydown handler, or elements with tabindex="-1" that should be in the focus order. The fix: use native HTML elements (<button>, <a>) whenever possible.

4. No Focus Indicator (outline: none)

This is the most pervasive keyboard accessibility failure. Designers remove the browser's default focus ring because it looks unstyled, and developers comply without replacing it. The result is that keyboard-only users cannot see where they are on the page. The fix: never use outline: none without providing a custom focus style that meets 3:1 contrast against adjacent colors.

5. Insufficient Color Contrast

Light gray text on white backgrounds, white text on light blue buttons, and medium gray placeholder text all commonly fail WCAG 1.4.3's 4.5:1 ratio for normal text. This is measurable — not a matter of opinion. Use a contrast checker to verify every text element in your design system before shipping.

6. Heading Hierarchy Violations

Developers often use heading tags (<h1>–<h6>) for visual styling rather than document structure. This breaks the document outline that screen reader users rely on to navigate. The fix: headings should reflect document outline, not visual weight. Use CSS for size; use heading tags for structure.

7. Generic Link Text

"Click here," "read more," and "learn more" repeat across pages pointing to different destinations. Screen reader users navigating by links hear these phrases stripped of context. The fix: make link text descriptive of the destination or purpose.

8. Images of Text

Screenshots of code, banner images with text embedded in them, and infographics with no text alternative all fail WCAG 1.4.5. The text in these images cannot be resized by the user, cannot be read by a screen reader, and fails in high-contrast mode. The fix: use real HTML text whenever possible.

9. Broken ARIA Attributes

ARIA is meant to supplement HTML semantics, not replace them. Common failures: aria-labelledby pointing to an ID that does not exist, aria-hidden="true" on a container that contains focusable elements, and custom widgets using role="button" without the required keyboard behavior.

10. Inaccessible Error Messages

Form validation errors placed visually near a field but not programmatically associated with it are invisible to screen reader users. The fix: use aria-describedby to link the error message to the field, ensure the error is announced with role="alert", and never rely on color alone to indicate an error state.

Quick Self-Audit Checklist

• Tab through your entire site — can you reach and activate every interactive element?
• Are focus states visible at every step?
• Do all images have appropriate alt attributes?
• Does your site work with a screen reader at a basic level?
• Does text meet 4.5:1 contrast throughout?

Running the ADA Compliance Checker Chrome extension will surface many of these issues automatically within seconds of opening any page.