DEV Community

a11ySolutions
a11ySolutions

Posted on

3 accessibility failures we find in every fintech onboarding flow.

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:

HTML code showing a label element connected to an email input field using matching for and id attributes

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

HTML code showing an email input field using aria-label attribute as an accessible name 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:

HTML code showing a div element with aria-live set to polite used to announce password validation messages to screen readers

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.

HTML code comparing an inaccessible div element used as a button versus a native button element that is keyboard focusable 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.

Top comments (0)