DEV Community: a11ySolutions

Focus indicators that fail WCAG 1.4.11: real cases and exact fixes

a11ySolutions — Wed, 13 May 2026 08:52:26 +0000

What is a focus indicator — and why does WCAG regulate it?

When a user navigates a website using a keyboard, they need to know where they are on the page at all times. The focus indicator is the visual signal that answers that question: the outline, highlight, or state change that appears on the element currently receiving keyboard focus.

WCAG Success Criterion 1.4.11 (Non-text Contrast) requires that the visual presentation of UI components, including focus and hover indicators, has a contrast ratio of at least 3:1 against adjacent colors.

Without a sufficient focus indicator:

Keyboard-only users lose their place on the page.
Users with low vision cannot perceive the current focus state.
The product fails a Level AA audit, the standard required by the EAA, ADA, and EN 301 549.

Below are three real cases from accessibility audits, extracted from a structured issue bank. No simulated data. No approximations.

Case 1 — Login page: Dropdown focused/hovered option
Component: "Tipo de documento" dropdown — focused and hovered option state
Audit type: Color Contrast · Priority: High

What was found:
When the dropdown expanded and the user hovered or focused an option, the selected state was communicated only through a light grey background. There was no outline or other indicator with sufficient contrast.

The CSS driving the problem:

.css-1kwd9xn-option {
background-color: rgb(241, 244, 244); /* #F1F4F4 */
color: rgb(0, 43, 69);
font-size: 14px;
font-weight: normal;
}

A ratio of 1.1:1 means the focused state is virtually indistinguishable from the default state. For a user with low vision navigating with a keyboard, the dropdown is effectively unusable.

The fix:
Replace the near-white background with a grey that achieves the required 3:1 threshold against the white page background.
css/* Before /
.css-1kwd9xn-option {
background-color: rgb(241, 244, 244); / ratio 1.1:1 — FAIL */
}

/* After /
.css-1kwd9xn-option:hover,
.css-1kwd9xn-option:focus {
background-color: #939393; / ratio 3.0:1 against #FFFFFF — PASS */
}

Case 2 — Login page: Password digit field borders
Component: Input field boundaries — digit fields for password entry
Audit type: Color Contrast · Priority: Medium

What was found:

The password entry screen used a series of individual digit input fields. Each field had only a bottom border as its visible boundary — the indicator that communicates "this is an input". That border failed the 3:1 contrast requirement against the white background.

WCAG 1.4.11 applies not only to focus rings but to any visual indicator that communicates the presence or boundary of an interactive component. A field border that a user cannot see means they cannot locate the input.

The fix:
Use a darker grey for the border that maintains the visual style while meeting the threshold.

css/* Before /
.password-digit-field {
border-bottom: 1px solid #CCD5DA; / ratio 1.48:1 — FAIL */
}

/* After /
.password-digit-field {
border-bottom: 1px solid #8094A3; / ratio 3.14:1 — PASS */
}

Case 3 — Account page: Radio button borders
Component: Radio button visual boundaries — payment method selection
Audit type: Color Contrast · Priority: Low

What was found:
A payment method selection screen presented a group of radio buttons for choosing between credit cards. The unchecked radio buttons used a light grey border to indicate their boundary. That border failed 3:1 against the white background.

When radio button borders are invisible, users with low vision cannot detect that a selectable option is present. This is a form usability failure, not just an aesthetic one: invisible controls block task completion.

The fix:
css/* Before /
.sc-radio-field-label:before {
border: 0.0625rem solid #C2CFD6; / ratio 1.59:1 — FAIL */
}

/* After /
.sc-radio-field-label:before {
border: 0.0625rem solid #949494; / ratio 3.03:1 — PASS */
}

What these three cases have in common
All three failures share the same root cause: grey UI elements on white backgrounds, where the grey is not dark enough to reach 3:1.

This pattern is extremely common in design systems that prioritize subtle, minimal aesthetics. The visual result feels clean. The accessibility result is that a significant portion of users cannot perceive the interface.

None of these fixes required redesigning the component. Each required changing one CSS color value.

Focus indicators failing WCAG 1.4.11: real cases and exact fixes

a11ySolutions — Tue, 12 May 2026 11:48:12 +0000

Focus indicators failing WCAG 1.4.11: real cases and exact fixes
What is a focus indicator?

A focus indicator is the visual signal that shows keyboard users which interactive element is currently focused.

WCAG 2.1 SC 1.4.11 (Non-text Contrast) regulates focus indicators because users navigating with a keyboard must clearly perceive where focus is located.

The minimum required contrast ratio for visible focus indicators is 3:1 against adjacent colors.

Why static accessibility tools often miss these issues

Most static accessibility scanners cannot reliably detect focus indicator failures because the :focus or :focus-visible state only exists during actual keyboard interaction.

To properly validate focus indicators, manual testing with the keyboard is required.

Usually:

Tab
Shift + Tab
Browser DevTools
Contrast analyzers
Real accessibility audit cases

Case 1 — Tourism company
The primary search button had a focus indicator with a contrast ratio below 3:1.

Problem

Keyboard users could technically navigate to the button, but the visible focus state was too subtle to perceive clearly.

WCAG failure
SC 1.4.11 — Non-text Contrast
Fix

Use a high-contrast outline with :focus-visible.

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

Case 2 — Educational platform

The “Login” button changed from #02959F to #027279 when focused.

Problem

Contrast between both visual states was only 1.57:1.

The component relied exclusively on color to communicate focus.

WCAG failures
SC 1.4.11 — Non-text Contrast
SC 1.4.1 — Use of Color
Fix

Add a visible outline independent of color changes.

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

Case 3 — Same platform

The “Remember me” checkbox used a black focus indicator (#212529) over a dark background (#1D191C).

Problem

Contrast ratio:

1.12:1

The focus state became nearly invisible.

Fix

Replace the focus indicator with:

outline: 2px solid #0297A2;
Results
4.92:1 against background
3.79:1 against adjacent colors

WCAG compliant.

How to test focus indicators properly

Recommended setup:

Chrome or Firefox
Keyboard navigation only
Colour Contrast Analyser (CCA)
Optional: NVDA or VoiceOver

Testing steps:

Navigate using only Tab
Verify focus is always visible
Measure contrast of the focus indicator
Validate zoom and dark mode scenarios
Quick production checklist

Before release, ask:

Can focus be identified immediately?
Does the indicator reach at least 3:1 contrast?
Does the state rely only on color changes?
Is focus still visible in dark mode?
Is it visible at 200% zoom?

Focus indicators are one of the most commonly overlooked accessibility failures in production systems, especially because many automated tools cannot fully detect them.

And yet, for keyboard users, they are critical navigation cues.

css #accessibility #wcag #webdev #a11y #focusvisible

Keyboard traps: what they are, how to reproduce them, and how to fix them

a11ySolutions — Mon, 11 May 2026 08:01:00 +0000

Definition of a keyboard trap according to WCAG 2.1 SC 2.1.2:

“If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface.”

Why can’t static accessibility tools detect it?

Because detecting a keyboard trap requires actual keyboard navigation — typically using the Tab key.

Real case (educational platform):

The login form contained a keyboard trap. When users activated the “Login” button with empty required fields, keyboard focus was completely lost. Keyboard only users could no longer identify where to continue.

Problematic HTML:

<input type="submit" name="commit" value="Entrar" class="btn btn-xchool btn-block mt-4" data-disable-with="Enviando...">

Solution:

Programmatically move focus to the error message’s “Close” button using focus().

Tested with Chrome + NVDA.

5 ARIA mistakes that make accessibility worse, not better

a11ySolutions — Wed, 06 May 2026 08:34:27 +0000

There's a rule in accessibility that doesn't get enough attention:

No ARIA is better than bad ARIA.

Adding ARIA attributes without understanding them doesn't help assistive tech, it actively misleads it. Here are the mistakes I find most often in real audits:

1. role="button" on a div — without keyboard support
If you give something a button role, screen readers announce it as a button.
Users expect to activate it with Space or Enter.
If your div only handles onClick, keyboard users get announced a button they can't press. Use <button>. That's what it's there for.

2. aria-label that duplicates visible text — badly
<button aria-label="Click here to submit the form">Submit</button>
Screen readers read the aria-label, ignoring "Submit". Now your button is "Click here to submit the form", verbose, inconsistent, and confusing in a list of controls.
If the visible label is accurate, you don't need aria-label.

3. aria-hidden="true" on focusable elements
Hiding something from the accessibility tree while leaving it focusable creates a ghost, keyboard users can tab to it, but screen readers announce nothing. That's worse than not hiding it at all.

4. aria-live on everything
aria-live="assertive" interrupts whatever the screen reader is doing to announce the update. Useful for critical alerts. Catastrophic for
status messages, loading indicators, or anything non-urgent.
Most of the time, aria-live="polite" is what you want, or nothing at all.

5. Decorative icons without aria-hidden
An icon inside a button with no aria-hidden forces screen readers to
announce the SVG path or file name alongside the button label.
<svg aria-hidden="true"> is two words. Use them.

No ARIA is better than bad ARIA.
Before reaching for it, ask if a native HTML element solves it first.

What ARIA mistakes do you see most in code reviews?

Form accessibility: the checklist nobody actually uses (until users complain)

a11ySolutions — Thu, 30 Apr 2026 07:19:49 +0000

Forms are where accessibility debt becomes user abandonment.

A form can pass every automated scan and still be completely unusable
for a significant chunk of your users.

Here's what I see skipped constantly in real audits:

Placeholder text used as a label
When the field gets focus, the hint disappears. For users with cognitive disabilities or memory issues, that's a dead end.
Use <label> elements. Always.

Error messages that only exist visually
Red border + error text looks complete. But if the error isn't linked to the input via aria-describedby, screen readers announce nothing.
The user submits. Nothing happens. They don't know why.

Required fields with no accessible indicator
An asterisk (*) is a visual convention. Without aria-required="true" or a text equivalent, it means nothing to assistive tech.

Autocomplete missing on personal data fields
WCAG 1.3.5 exists. Most teams don't know it does. Name, email, phone, address, those fields need proper autocomplete
attributes. For users with motor disabilities, it can be the difference between completing the form or not.

Focus order that fights the visual layout
Tab order follows DOM order, not visual order. If your CSS grid or
flexbox rearranges things visually, keyboard users may be jumping around the form in a completely unexpected sequence.

None of these fail an automated scan.
All of them fail real users.

If you're doing form reviews, what's the first thing you check?

Great insights by Vitaly Skadorva! Our benchmarks confirm that moving to dynamic interaction testing is key, increasing finding precision from ~20% to over 80%. A must-read for true A11y!

a11ySolutions — Mon, 27 Apr 2026 16:24:17 +0000

Vitaly Skadorva

Apr 27

Accessibility Testing: Best Practices

#webdev #a11y #qa #testing

Comments 2

12 min read

Accessibility issues that automated tools won't catch (from real audits)

a11ySolutions — Fri, 24 Apr 2026 10:35:10 +0000

I run accessibility audits regularly. One pattern keeps showing up:

The most critical issues are never in the code. They're in the interaction.

Automated tools are genuinely useful, they catch structural and semantic
issues fast. But they don't simulate real user behavior. And that's where
things actually break.

Here are the failure patterns I find most often:

Keyboard traps in modals: focus gets locked inside a dialog with no
way out unless you know to press Escape (and even then, sometimes it doesn't
work).

Unpredictable focus jumps: after a button click or route change, focus
lands somewhere random. A screen reader user loses their place entirely.

Silent error messages: form validation runs, the error renders visually,
but aria-live is missing. Screen readers announce nothing.

Forms that validate but can't be completed: the markup passes the
scanner. Real users hit walls at step 2.

None of these show up in axe, Lighthouse, or WAVE. You only find them
when you actually use the product, keyboard only, screen reader on,
cognitive load simulated.

Accessibility isn't about passing a scan. It's about whether people can
complete critical flows.

How are you testing beyond automated tools in your projects?
Keyboard only passes? Screen reader sessions? Something else?