DEV Community: Giriprasad patil

A Perfect Automated Accessibility Score Doesn't Test These 4 Things

Giriprasad patil — Tue, 20 Oct 2026 05:52:07 +0000

A green 100 on an automated accessibility audit is a good sign. It means the page has no failures that a rule engine can find in the page as it first loads: images without alt text, inputs without labels, low-contrast text, invalid ARIA.

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:

Text	Background	Ratio	4.5:1 for body text
`#475569` (slate 600)	`#FFFFFF`	7.58:1	Passes
`#475569`	`#0B0F19`	2.53:1	Fails
`#2563EB` (blue 600)	`#FFFFFF`	5.17:1	Passes
`#2563EB`	`#0F172A`	3.45:1	Fails

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.

Dark Mode Accessibility: Why a Theme Toggle Doesn''t Satisfy WCAG Contrast

Giriprasad patil — Mon, 19 Oct 2026 19:11:31 +0000

Color contrast is the number one accessibility failure on the web. According to WebAIM's Million analysis, 83.6% of all websites fail WCAG contrast requirements on at least one element. Adding a dark mode toggle to your site doesn't fix that statistic — for most teams, it creates an entirely new set of contrast failures that no one checked because the light mode tested fine.

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

UI Element	Light Mode Risk	Dark Mode Risk	WCAG Criterion
Body text	Low (if initially tested)	Medium — inverted palette may drop ratio	1.4.3
Placeholder text	High — often set to gray at 3:1 or less	Higher — same gray looks different on dark bg	1.4.3
Disabled button text	Medium — often intentionally low contrast	High — dark mode inversion makes it worse	1.4.3 (Note 1 exception applies but check)
Form input borders	Medium — light gray borders on white fail 1.4.11	High — dark mode border colors frequently fail	1.4.11
Focus indicator (outline)	High — default browser outline removed by CSS	Very High — dark mode often has no visible focus	2.4.7 / 2.4.11
Error state text	Low if checked	High — red on dark bg often fails	1.4.3
Icon color	Medium — icon-only elements need 3:1	High — icon color may be inverted incorrectly	1.4.11
Link text color	Low if initially blue	Medium — dark mode link color often under-contrasted	1.4.3
CTA button	Low if checked	Medium — brand-color button on dark bg often fails	1.4.3 + 1.4.11

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 to 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.