Forem: a11ySolutions

3 accessibility failures we find in every fintech onboarding flow.

a11ySolutions — Tue, 26 May 2026 09:54:50 +0000

We audited several fintech onboarding flows this quarter. Different companies, different stacks, different teams.

Same three issues. Every time.

None of them appeared in automated scans. All of them showed up in the first 30 minutes of expert review. Here's what they are and how to fix them.

Issue #1 — Email field with no visible label

The field looks fine visually. There's placeholder text that says "Enter your email." But there's no <label> element connected to it.

For a screen reader user, the field is either announced without context or skipped entirely.

The fix:

If you can't modify the label structure, use aria-label as a fallback:

How to test with NVDA + Chrome:
Tab into the field. NVDA should announce "Email address, edit text." If it announces only "edit text" or nothing, you have this issue.

Issue #2 — Password validation that disappears
The error message appears when the user types a weak password, then vanishes after a second. Sighted users catch it. Users with low vision or screen readers miss it entirely.

The fix is to use aria-live so assistive technology announces the message when it appears:

Then inject the validation message into that container via JavaScript. The screen reader will announce it automatically.

How to test:
Trigger the validation error. If NVDA doesn't announce the message out loud, you have this issue.

Issue #3 — Continue button unreachable via Tab on mobile
The button exists in the DOM. It looks tappable. But keyboard and switch access users on mobile can't reach it because focus order is broken or the element isn't natively focusable.

The fix:
Use a native <button> element instead of a styled <div> or <span>. Native buttons are focusable and keyboard-operable by default.

If you must use a custom element, add tabindex="0" and handle keyboard events explicitly.

How to test:
On mobile, connect a Bluetooth keyboard. Tab through the form. If you can't reach the Continue button, you have this issue.

Quick checklist before you ship an onboarding flow

Every input has a visible, connected <label>
Error messages use aria-live or role="alert"
All interactive elements are reachable via Tab
No action depends exclusively on placeholder text
The flow is testable with NVDA or VoiceOver in under 10 minutes

These issues don't show up in automated scans.
Automated tools check structure. They don't simulate how a real user navigates with a screen reader, a keyboard, or a switch device. That's what expert audits are for.

If you want to know whether your onboarding has these issues, start here.

Your accessibility fixes are good. But do you know what they're worth?

a11ySolutions — Thu, 21 May 2026 09:04:28 +0000

I put together a visual breakdown of this concept as a LinkedIn carousel -https://www.linkedin.com/feed/update/urn:li:activity:7463121450070212609 before diving into the full article.

The audit is not the full picture

You've run the audit. Fixed the contrast ratios. Added the missing alt text. Resolved the keyboard trap on that modal that's been broken for six months.

WCAG compliance is checked. The report is clean.

And then someone from product or leadership asks:

Great — but what did that actually do for the business

Most developers don't have a good answer to that question. Not because the work isn't valuable, it is, but because no one built the bridge between the technical fix and the business outcome.

This article is that bridge.

The drop-offs your analytics will never show you

Here's something worth understanding about accessibility failures: most of them are invisible to standard tracking.

When a screen reader user hits a form that doesn't announce validation errors, they don't trigger an error event. They just stop. When a keyboard user encounters a focus trap inside a modal they can't escape, there's no rage click, no heatmap signal, no session recording that captures what happened.

They leave. Quietly. Before your funnel even starts.

This is the category of lost revenue that never appears in any dashboard, and it's directly caused by inaccessible components.

A broken aria-live region. A missing role="alert". A date picker built without keyboard support. A checkout button that's visually styled but not semantically a button.

These aren't edge cases. They're patterns that repeat across almost every production codebase.

Accessibility barriers are conversion failures

The framing matters here.

When you fix a focus management issue, you're not just passing a WCAG 2.1 success criterion. You're removing a barrier that was preventing a subset of your users from completing a critical task, booking, purchasing, registering, submitting.

That subset is larger than most teams assume. It includes users with permanent disabilities, but also users on keyboard-only setups, users with temporary injuries, power users who tab through forms, and older users who rely on larger text and higher contrast.

When that barrier is removed, task completion goes up. And task completion is conversion.

The technical fix and the business outcome are the same event, most teams just never measure them together.

How to calculate what your accessibility work is actually worth

This is where it gets concrete.

The variables that determine the revenue impact of accessibility remediation are the same variables your analytics team already tracks:

Monthly traffic, conversion rate, average order value, and industry sector.

What changes when you improve accessibility is the effective conversion rate, because you're removing friction that was silently blocking a portion of your users from completing the flow.

We built a free ROI calculator that takes exactly those inputs and returns a projected revenue impact based on verified industry data, not generic estimates, but numbers calibrated to your traffic, your conversion rate, and your sector.

👉 Calculate the ROI of your accessibility work -https://www.a11ysolutions.com/roi-calculator/

No sign-up. No pitch. Just your number.

Why this matters beyond the ticket
If you're a developer who cares about accessibility, and if you're reading this, you probably do, you already know the work is worth doing.

But knowing how to communicate its value to a product manager, a CTO, or a leadership team is a different skill. And it's one that determines whether accessibility stays a priority after the first audit, or gets deprioritized when the next quarter's roadmap fills up.

The ROI calculator doesn't replace your expertise. It gives your work a language that the rest of the organization understands.

Run it before your next sprint review. Share the number with your product lead. It's a two-minute exercise that can change how accessibility is resourced on your team.

The takeaway

Accessibility fixes reduce friction. Reduced friction improves conversion. Improved conversion is measurable revenue.

The chain is direct. Most teams just never close the loop.

Now you can.

👉 https://www.a11ysolutions.com/roi-calculator/

Accessible error messages: the patterns that work across JAWS, NVDA and VoiceOver

a11ySolutions — Mon, 18 May 2026 11:36:38 +0000

You added aria-live="assertive". You set aria-invalid="true". You tested in Chrome with a mouse.

The error message works perfectly.

Then a JAWS user fills out your form and hears... nothing useful. Or worse,they hear the error, but by the time they navigate back to the field, the message is gone.

Two real cases from audits that show exactly where this breaks.

Case 1: The toast that disappeared before the user could act
An e-learning platform displayed validation errors as auto-dismissing toasts with data-delay="8000". Eight seconds sounds reasonable until you map what a screen reader user actually needs to do: hear the announcement, understand the error, navigate back to the field, correct it, re-submit. On a complex form, that's not enough time, and the message was gone before they could act.

WCAG failure: SC 2.2.1 — Timing Adjustable. Any time limit must be removable or adjustable. An 8-second toast carrying critical error information fails outright.

Fix: don't use auto-dismissing toasts for errors. Toasts work for redundant, low-stakes notifications. Not for information the user needs to act on. Display errors inline, adjacent to the field, and keep them visible until the user corrects the input.

Case 2: The error that vanished when focus left the field
A form showed the error while the field was focused, but an onblur listener hid the container the moment the user tabbed away. The screen reader announced only "invalid entry." No explanation, no guidance.

Two bugs in one component. First, the message disappeared on blur, so any user who tabbed to the next field and back found it gone. Second, there was no aria-describedby linking the error text to the input,so even when the message was visible, JAWS and NVDA had no reason to read it on focus.

With aria-describedby in place, JAWS, NVDA and VoiceOver all read the error automatically when the field receives focus. Remove the blur handler. Errors should persist until the user successfully corrects the field.

Both bugs come down to the same root cause: errors that aren't persistent and aren't programmatically connected to their field. Fix those two things and you cover the vast majority of screen reader failure modes on form validation.

What patterns are you using for error handling? Curious if anyone's hit edge cases with VoiceOver + Safari on iOS, that combination still has quirks worth discussing.

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?