Here are four that show up often, the WCAG criterion each one fails, and how to catch them before they merge.

1. A clickable div with no keyboard support (WCAG 2.1.1, 4.1.2)

Ask for "a clickable card" or "a custom button" and you'll often get this:

// Works with a mouse. A keyboard user can't reach it or activate it.
<div className="btn" onClick={save}>Save</div>

Adding role="button" alone doesn't fix it: the element still isn't in the tab order and doesn't respond to Enter or Space.

// Fix: use the element that already does all of this.
<button type="button" className="btn" onClick={save}>Save</button>

A <button> is focusable, activates on Enter and Space, and is announced as a button. Reach for role and tabIndex only when no native element fits.

2. An aria-label that doesn't match the visible text (WCAG 2.5.3)

Assistants like adding aria-label "for accessibility", often with a more descriptive phrase than the button shows:

<!-- Visible text "Buy now"; accessible name "Add product to basket" -->
<button aria-label="Add product to basket">Buy now</button>

The aria-label replaces the visible text as the accessible name. A voice-control user who says "click Buy now" gets nothing, because no control is called "Buy now". WCAG 2.5.3 (Label in Name) requires the accessible name to contain the visible label.

<!-- Fix: let the visible text be the name -->
<button>Buy now</button>

If you need more context for screen reader users, keep the visible words at the start of the name: aria-label="Buy now: Linen shirt".

3. A placeholder used as the label (WCAG 3.3.2, 1.3.1)

<input type="email" placeholder="Email address">

The placeholder disappears as soon as someone starts typing, it's usually low contrast, and it isn't a reliable label. Give every input a visible, associated label:

<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email">

4. Focus outlines removed (WCAG 2.4.7)

Generated CSS often includes a reset like this:

*:focus { outline: none; }

It removes the only sign of where a keyboard user is on the page. If the default ring doesn't fit the design, replace it rather than removing it, and keep it to keyboard focus:

:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 2px;
}

Catching these in review

Each check below catches a different subset, so use more than one:

• A linter in the editor. eslint-plugin-jsx-a11y flags click handlers on non-interactive elements and inputs without labels while you type.
• Prefer native elements in prompts and review. Asking the assistant for "a <button>" or "a native <dialog>" gets better output than "a clickable element".
• A keyboard pass. Tab through the new component. If you can't reach or operate it, it fails.
• A check of the rendered page. Mistakes 1, 2 and 4 depend on the rendered page — computed names, focus styles, what's focusable. ADAGuard loads the page in a real browser and checks those, including label-in-name. Scan a page free.

Avoid "fix it at runtime" scripts as the safety net. A script that edits the page in each visitor's browser leaves the source unchanged, so every mistake is still in the code the assistant learned from your repo. See why overlays don't fix accessibility.

AI assistants are useful here too: once a failure is found, they're good at applying a known fix across many files. The part they can't do is notice that a component they just wrote doesn't work with a keyboard. That takes a test.

It doesn't mean a keyboard or screen reader user can get through the page. Automated rules run against one snapshot — one theme, one viewport, before anyone clicks anything — and many WCAG failures only exist after an interaction. Here are four that a perfect score routinely misses, with the criterion each one fails and the fix.

1. Focus that goes nowhere when a dialog closes (WCAG 2.4.3)

A dialog that opens and closes correctly for a mouse user can strand a keyboard user. When the dialog unmounts, the element that had focus is gone, and the browser drops focus back to the top of the document. A screen reader user who pressed "Add to cart" now hears the page from the beginning.

A rule engine looking at the page as loaded never opens the dialog, so it never sees this.

// Remember what opened the dialog, and return focus there when it closes.
function useReturnFocus(open) {
  const opener = useRef(null);
  useEffect(() => {
    if (open) {
      opener.current = document.activeElement;
    } else if (opener.current) {
      opener.current.focus();
      opener.current = null;
    }
  }, [open]);
}

While the dialog is open, keep focus inside it — the native <dialog> element opened with showModal() does that for you, and closes on Escape. More patterns: managing focus after a modal closes.

2. Status messages nobody hears (WCAG 4.1.3)

"Added to cart", "3 results", "Email already in use" — messages that appear after an action are visible to sighted users instantly. A screen reader announces them only if they're rendered into a live region that was already in the page before the text changed.

<!-- In the page from the start, empty -->
<div role="status" aria-live="polite" id="cart-status"></div>

// Later: change only its text
document.getElementById('cart-status').textContent = 'Added to cart';

A live region created at the same moment as its message is often not announced. Rendering the container on load and updating its text is the reliable pattern. Full walkthrough: announcing dynamic content to screen readers.

3. Menus that only open on hover (WCAG 2.1.1)

A navigation submenu revealed with :hover works for a mouse and does nothing for a keyboard. The links inside exist in the HTML, so a check of the loaded page finds nothing wrong — but a keyboard user can never reach them.

<li>
  <button type="button" aria-expanded="false" aria-controls="menu-products">Products</button>
  <ul id="menu-products" hidden>
    <li><a href="/shirts">Shirts</a></li>
  </ul>
</li>

Toggle aria-expanded and hidden from the button's click handler, close the menu on Escape and return focus to the button. A button gets Enter and Space handling for free. Full pattern: accessible multi-level navigation.

4. Contrast in the theme the scan didn't load (WCAG 1.4.3)

An automated scan sees whichever theme the page renders by default. If that's the light theme, the dark theme is never measured — and colours that pass on white often fail on a dark surface.

Measured with the WCAG contrast formula:

The same tokens, a different background, a different result. Check every theme's pairs on purpose — the color contrast checker takes any two colours — and see dark mode and WCAG contrast for a palette that works.

Testing what a score can't see

None of this makes automated checks less useful: they catch the most common failures on every page, quickly, every time you deploy. Pair them with the checks that need interaction:

• A keyboard pass. Unplug the mouse. Tab through every flow, open and close every dialog and menu, and watch where focus goes.
• A screen reader pass on the flows that matter most — sign-up, checkout, search — with VoiceOver, NVDA or Narrator, all free.
• Each theme and breakpoint you ship, not only the default.

ADAGuard runs some interaction checks in a real browser — it presses Tab to find keyboard traps, and measures whether a focused element is hidden behind a sticky header — but no automated tool covers everything above. Scan a page free to see what it finds, and what it tests automatically is listed criterion by criterion.

Test individual color pairs with the color contrast checker; for code-level fixes in React apps, see the React accessibility checker.

The ada compliance color checker problem in 2026 is this: most teams test contrast for one theme. They pick colors for light mode, run them through a contrast ratio tool, confirm they pass 4.5:1, and ship. Then they add a dark mode using CSS custom properties, invert a few background variables, and assume the same colors will work in reverse. They rarely do.

What WCAG Actually Requires for Contrast

WCAG 2.1 Level AA sets two minimum contrast ratios that apply to every color combination on your site — in every theme:

1.4.3 Contrast (Minimum): At least 4.5:1 for normal text (under 18pt regular or 14pt bold). At least 3:1 for large text (18pt+ regular or 14pt+ bold). This ratio applies to text against its immediate background.

1.4.11 Non-text Contrast: At least 3:1 for user interface components (buttons, form inputs, focus indicators, icons that convey meaning) against adjacent colors.

Both thresholds apply independently to every theme. A color pair that achieves 5.2:1 in light mode and 2.8:1 in dark mode is non-compliant. The dark mode version fails 1.4.3 regardless of the light mode result. If you offer a dark mode, you must run an ada compliance color checker against your dark theme separately.

Why Dark Mode Creates New Contrast Failures

The instinct when building dark mode is to invert: swap your white background for a dark background, keep your brand colors, change your text from dark to light. This works visually for most colors. It fails accessibility for many.

Pure black is too harsh, saturated colors "vibrate." Accessibility specialists consistently recommend against using pure black (#000000) as a dark mode background. The extreme contrast between pure black and white text (21:1) can cause eye fatigue and halation effects for users with certain visual impairments. Industry standard dark backgrounds use very dark grays (#121212, #1e1e1e) rather than true black.

More importantly, fully saturated brand colors — the bright reds, oranges, and yellows that pop on a white background — often fail contrast requirements on dark backgrounds. A bright orange (#FF6B00) achieves 4.8:1 on white (#FFFFFF), passing AA. The same orange achieves only 3.1:1 on dark gray (#121212), failing AA for normal text. Same hex value, opposite compliance outcome depending on theme.

Semantic states lose meaning in dark mode. Error states (red borders, red text), success states (green badges), warning indicators (yellow icons) — these are color-coded signals that may pass contrast in light mode and fail in dark mode. Because they appear infrequently (only on form errors or validation), they're often the last thing tested. They're also the most legally significant: a form that cannot communicate an error state to a low-vision user is a direct barrier to completing a task.

The prefers-color-scheme Problem

Developers who implement dark mode via CSS prefers-color-scheme — the media query that automatically switches the theme based on the user's OS setting — often never see the dark version in their browser during development. Their browser is in light mode. They build, test, and ship in light mode. The dark mode exists in the CSS and is served to users who prefer it, but no one on the team ran an ada compliance color checker against it.

A minimal but meaningful test workflow:

/* In your browser DevTools — Forces dark mode for testing */
@media (prefers-color-scheme: dark) {
  /* Your dark mode tokens go here */
}

In Chrome DevTools → Rendering tab → Emulate CSS media feature prefers-color-scheme → set to dark. This lets you view the dark theme without changing your OS setting, enabling contrast testing in the browser.

What to Test and Where the Failures Hide

Testing Both Themes Systematically

The correct approach is to run your ada compliance contrast checker against both themes separately. For web surfaces, use the same tool you'd use for light mode — but capture the dark mode state.

For automated scanning, ADAGuard at adaguard.io scans your site's live-rendered DOM including JavaScript-applied styles. If your dark mode is applied via a class toggle (e.g., class="dark" on ``), you can share the dark-mode URL or state with a scanner that supports URL parameters. ADAGuard's ada compliance color checker functionality is part of its full 23-category scan, covering contrast ratios across the rendered page alongside form labels, alt text, ARIA, and focus indicators.

For manual review, use the browser DevTools color picker or tools like the Colour Contrast Analyser desktop app to spot-check your most common text/background combinations in both themes.

Building Contrast Compliance Into Your Design System

The highest-leverage fix is upstream: define accessible dark mode color tokens at the design system level, not per-component.

Rather than allowing any designer to use any color on any dark background, pre-define an approved palette for dark mode that has been verified against 4.5:1 for text and 3:1 for UI components. Document which combinations are approved, which are prohibited, and which require special consideration (large-text only, icon-only with text label). Build this into your Figma variable library or design tokens spec so that the contrast requirements are enforced at the design stage, not discovered in a post-launch ada compliance color checker audit.

The EAA has been in enforcement since June 28, 2025, and color contrast is one of the most easily detected violations — regulators and plaintiff attorneys can run automated checks against your dark theme just as easily as your light theme.

The 30-Second Fix

Run an ADAGuard scan right now. Paste your URL at adaguard.io — no signup required — and get a full WCAG 2.2 AA report including color contrast analysis in under 30 seconds. ADAGuard checks both contrast thresholds (1.4.3 and 1.4.11) across your live-rendered page, plus 20 other check categories covering ARIA, form labels, alt text, and focus indicators. See exactly which contrast failures exist on your current theme — then run the same scan on your dark mode state before a regulator or plaintiff attorney does it for you.