Why authentication is a common barrier
Authentication sits in front of critical services—banking, healthcare, benefits, deliveries. If a login step requires vision, precise pointer control, or fast reading of small text, people are locked out. The most frequent problems include image-only CAPTCHAs without an effective alternative, 2FA delivered through inaccessible channels, timeouts that wipe data, and password rules that fight assistive technology. The goal is strong security with equal access.
Login fundamentals that prevent friction
- Labels and hints: Persistent, programmatic labels (not placeholders). Attach hints with
aria-describedby. - Password managers: Use standard field names (
name,email,username,current-password,new-password) and do not block autofill. - Keyboard-first: Logical tab order; visible focus; submit on Enter in password fields; avoid hover-only reveals.
- Error messaging: Specific, adjacent, and announced via a polite live region; never “Invalid” without guidance.
<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email">
<label for="pwd">Password</label>
<input id="pwd" name="current-password" type="password" autocomplete="current-password"
aria-describedby="pwd-hint pwd-err">
<div id="pwd-hint" class="hint">Minimum 8 characters.</div>
<div id="pwd-err" class="error" role="alert" hidden>Password must be at least 8 characters.</div>CAPTCHA and “bot checks” without exclusion
Visual puzzles (“select all squares with traffic lights”) are a dead end for many users, including blind users, people with low vision, cognitive differences, or motor limitations. Even “audio CAPTCHAs” can be unintelligible. Prefer invisible or behavior-based checks; when human verification is required, provide equally effective alternatives that work non-visually and by keyboard.
Preferred approaches (ranked)
- Server-side risk checks and device attestation—no user challenge at all for normal risk.
- One-time codes via email/SMS/voice as a fallback to behavior checks.
- Challenge questions that are readable, keyboardable, and not image dependent.
Fallback if a CAPTCHA must remain
- Provide a text-based or logic challenge that is keyboard operable and screen-reader clear.
- Expose bypass link to a different verification route (email/voice code) with equal priority.
- Ensure the challenge control has an accessible name and focus order; announce errors specifically.
<div role="group" aria-labelledby="human-check">
<h2 id="human-check">Verify you’re a person</h2>
<p id="human-hint">Answer the question or choose another method.</p>
<label for="challenge">What is two plus five?</label>
<input id="challenge" name="challenge" inputmode="numeric" aria-describedby="human-hint human-err">
<p>Or <button type="button" id="send-code">Send a code by voice call</button></p>
<div id="human-err" class="error" role="alert" hidden>Answer was not correct. Try again or request a voice code.</div>
</div>Accessible multi-factor authentication (2FA/MFA)
Multi-factor should increase security, not exclude users. Provide at least two accessible factors and allow users to switch if one channel fails. Common accessible options:
- Authenticator apps/TOTP: Code entry fields should accept paste, group input boxes logically, and announce position (“Digit 1 of 6”).
- SMS or voice code: Present a readable option for voice call delivery; keep code fields visible while listening on the same device.
- Push approvals: Buttons must have accessible names (“Approve sign-in”); provide a fallback if push is unavailable.
- Passkeys/WebAuthn: Support platform authenticators with keyboard/screen-reader prompts; offer an alternate factor for unmanaged devices.
- Backup codes: Present as selectable text with a copy button; allow storing or downloading in accessible formats.
Code-entry patterns that work
<fieldset aria-describedby="code-hint">
<legend>Enter 6-digit code</legend>
<div class="code-group" role="group" aria-label="One-time code">
<input inputmode="numeric" pattern="[0-9]*" aria-label="Digit 1 of 6">
<input inputmode="numeric" pattern="[0-9]*" aria-label="Digit 2 of 6">
<input inputmode="numeric" pattern="[0-9]*" aria-label="Digit 3 of 6">
<input inputmode="numeric" pattern="[0-9]*" aria-label="Digit 4 of 6">
<input inputmode="numeric" pattern="[0-9]*" aria-label="Digit 5 of 6">
<input inputmode="numeric" pattern="[0-9]*" aria-label="Digit 6 of 6">
</div>
<p id="code-hint">You can paste the full code.</p>
</fieldset>Support pasting the entire code into the first box and distributing digits automatically. On error, announce specifically (“Code expired; we sent a new one”) and return focus to the first box.
Session timeouts and lockouts
Timeouts protect accounts—but sudden expiration can wipe form data and force users back through authentication. Many users need additional time due to magnification, screen reader navigation, or cognitive load.
- Advance warning: Provide a clearly labeled modal 2–5 minutes before expiry with Extend session and Sign out options; trap focus inside until a choice is made.
- Preserve data: Save entered values so users aren’t punished for taking longer.
- Grace on re-auth: Return users to their place with content intact; do not discard carts or forms after a brief lock.
<div role="dialog" aria-labelledby="timeout-title" aria-modal="true" hidden>
<h2 id="timeout-title">Session will expire soon</h2>
<p>For your security, your session expires in 2 minutes. Would you like to extend?</p>
<button type="button">Extend session</button>
<button type="button">Sign out</button>
</div>Account recovery and device changes
Lost devices and changed phone numbers are common. Recovery flows must not assume visual CAPTCHAs or inaccessible email layouts.
- Recovery choices: Offer multiple routes: email link, voice code, backup codes, support verification with identity docs.
- Readable emails: Semantic HTML with clear buttons/links that are keyboardable; link text should state the action and device/region.
- Device prompts: When prompting on a second device, ensure announcements are concise and actionable (“Approve sign-in for account@example.com”).
Testing authentication for accessibility (10-minute sweep)
- Keyboard-only: Login → 2FA → success. Is focus always visible? Do dialogs trap focus? Can you submit with Enter?
- Screen reader: NVDA/VoiceOver: Are inputs labeled? Does the 2FA field announce position? Are errors announced?
- CAPTCHA alternative: Is there a non-visual route that’s truly equivalent (voice/email code)? Does it work end-to-end?
- Timeout: Trigger the warning; can you extend? Is data preserved after re-auth?
- Mobile zoom: At 200% zoom, do labels persist and controls remain reachable without horizontal scrolling?
- Password manager: Can you autofill and submit without being blocked by custom scripts?
Common pitfalls that cause lockouts
- Image-only CAPTCHAs with broken or unusable audio alternatives.
- 2FA input that rejects paste or traps focus after each digit.
- Push-only MFA with no fallback for users without that device.
- Timeouts that expire without warning and discard carts or forms.
- Emails with image-only buttons or vague link text (“Click here”) that screen readers can’t interpret.
- Custom password input that prevents password manager autofill or hides the label as a placeholder.
Evidence to capture when security blocks access
If you couldn’t log in or complete 2FA due to inaccessible controls, document:
- Screenshot or short recording of the step (e.g., CAPTCHA with no alternative; code field rejecting paste).
- Date/time, URL/app version, device/browser, and any assistive tech in use.
- Exact steps and messages (“Requested audio CAPTCHA; audio unintelligible; no other option offered”).
- Consequence: inability to access healthcare, banking, benefits, or complete a time-sensitive task.
Why accessible authentication is good security
Frustration leads to risky workarounds (shared accounts, reused passwords, disabled MFA). Clear labels, flexible MFA, and predictable flows reduce help-desk load and strengthen overall security posture. Accessibility and security are aligned: both reduce errors and increase successful, legitimate sign-ins.
How The Brensilber Law Firm helps (briefly)
When authentication or bot checks deny equal access to services, we help turn your experience into action—focused on precise documentation, measurable impact, and outcomes that drive durable fixes in design and code. If you hit barriers like those described here, contact us to discuss options, or explore more guides at our Resource Hub.