Accessible Security: MFA, CAPTCHA and Timeouts That Everyone Can Use

Sign-in pages, MFA prompts, CAPTCHAs and session timeouts are among the most common points where disabled people are locked out of services, and the workarounds they are pushed into, such as shared passwords, help desk overrides and a family member signing in for them, weaken security for everyone. Accessible security means designing authentication and other security controls so that people who are blind, deaf, have motor, cognitive or learning disabilities, or use assistive technology can complete them unaided and safely. This guide covers the requirements that apply (WCAG 2.2, NIST SP 800-63B-4, the ADA Title II web rule and the European Accessibility Act), how to choose and configure accessible authenticators, CAPTCHA and timeout design, help desk fallbacks, testing and metrics. It is for IAM architects, product and UX teams, accessibility leads and security policy owners. The broader principles of designing controls around people are in the Usable Security and Human Factors Guide; this page goes deeper on disability.

Source note: legal and standards requirements below are summarised from the W3C, NIST, ADA.gov and EUR-Lex texts listed in the references, as checked in November 2026. Confirm against the official text before relying on it.

Key takeaways

• Every authentication path needs a route with no cognitive function test. WCAG 2.2 success criterion 3.3.8 (Level AA) treats remembering, transcribing and solving puzzles as cognitive tests and requires an alternative or a mechanism, such as a password manager, for each step, including account recovery.
• Never block paste or autofill. Both WCAG and NIST SP 800-63B-4 expect password managers and autofill to work; blocking paste or asking for "the 3rd and 5th characters" fails users and weakens passwords.
• Passkeys and approve-on-device prompts are the accessible default. Hardware keys, platform authenticators and device approval are not cognitive tests, and they are also phishing-resistant.
• Offer choice, not one mandated method. NIST SP 800-63B-4 requires a non-biometric alternative wherever biometrics are used, alternatives to SMS and voice codes, and recommends letting users pick the authenticator that suits them.
• Accessible fallbacks must still be secure. When disabled users are routed to the help desk, that route becomes a social engineering target: verify identity with methods public information cannot satisfy.

Where security controls exclude people

Most exclusion comes from a small number of controls. Each failure below has both an accessibility cost and a security cost, because a user who cannot complete the control is pushed towards something weaker.

The requirements that apply

WCAG 2.2

• 3.3.8 Accessible Authentication (Minimum), Level AA: no step in an authentication process may require a cognitive function test unless the step offers an alternative method without one, a mechanism to help (such as paste or a password manager), the test is to recognise objects, or the test is to identify non-text content the user provided. The W3C Understanding document says every step must comply, there must be a path through authentication that avoids cognitive tests, and account recovery needs such a path too.
• 3.3.9 Accessible Authentication (Enhanced), Level AAA: removes the object recognition and personal content exceptions.
• 3.3.7 Redundant Entry, Level A: information already entered in a process must be auto-populated or selectable, with exceptions for essential re-entry, security and data that is no longer valid. Confirming a newly created hidden password falls under the security exception.
• 2.2.1 Timing Adjustable, Level A: users must be able to turn off, adjust (to at least ten times the default) or extend a time limit, with at least 20 seconds' warning and a simple action, repeatable at least ten times. A security-related limit may count as essential and be exempt, and the W3C notes time-based two-factor tokens can be treated as essential, but 3.3.7, 3.3.8 and 3.3.9 may still apply.

NIST SP 800-63B-4

• Passwords (section 3.1.1.2): verifiers SHALL allow password managers and autofill, SHOULD permit paste, and SHOULD offer an option to show the password until it is submitted.
• SMS and voice (section 3.1.3.3): verifiers using the telephone network SHALL make alternative authenticator types available to all subscribers.
• Biometrics (section 3.2.3): an alternative non-biometric authentication option SHALL always be provided, and voice comparison SHALL NOT be used.
• Customer experience (section 8, informative): identity service providers are expected to comply with Section 508; providers should support alternative authenticator types and let users choose; warn before an inactivity timeout (the example given is about two minutes); allow at least 10 entry attempts for authenticators whose output the user types; give time-based one-time passwords a grace period; and provide mechanisms for subscribers to report difficulties.

Law

• United States, ADA Title II: the Department of Justice web rule requires state and local government web content and mobile apps to meet WCAG 2.1 Level AA. As shown on ADA.gov (checked November 2026), an interim final rule published on 20 April 2026 extended compliance to 26 April 2027 for governments serving 50,000 or more people and 26 April 2028 for smaller governments and special districts. Federal agencies are covered by Section 508.
• European Union, European Accessibility Act (Directive (EU) 2019/882): applies to listed services provided to consumers after 28 June 2025, including consumer banking and e-commerce. Its recitals state that the requirements should extend to identification methods, electronic signature and payment services, and microenterprises providing services are outside its scope.

Even where no law applies, an inaccessible sign-in means customers and staff who cannot use the service, and workarounds that weaken security.

Choosing accessible authenticators

No single method suits everyone, which is why choice is the core design principle. The table compares common methods against the main accessibility needs.

For most services the strongest combination is passkeys as the default, a second authenticator or recovery passkey, and a paste-friendly password or code path as fallback. See the Passkeys for Everyone Guide and the Phishing-Resistant MFA Guide.

Designing the details

• Form markup: use correct input types and autocomplete values (username, current-password, new-password, one-time-code) and visible labels, so browsers, password managers and screen readers can fill and announce fields (W3C technique H100 covers email and password inputs).
• Show password: offer a toggle to reveal the password, as both W3C and NIST recommend.
• Error messages: say what went wrong and how to fix it, in text announced to screen readers, without revealing whether the account exists.
• Push and number matching: label the approve and deny buttons, include the service name and context, and keep any number short and readable by screen readers.
• Lockout thresholds: NIST suggests allowing at least 10 attempts for authenticators whose output the user types. Pair this with rate limiting rather than hard lockout. See the Account Lockout and Brute-Force Protection Guide.
• Password rules: length rather than composition rules, no forced periodic change and clear rejection feedback, per NIST section 8. See the Password Policy Guide (NIST-aligned).
• Plain language: short instructions and few steps at sign-in help people with cognitive and learning disabilities. The W3C Working Group Note on making content usable for people with cognitive and learning disabilities asks for a login that does not rely on memory, puzzles or calculations.

CAPTCHA and bot defences

A CAPTCHA that is the only way through sign-in or registration fails WCAG 3.3.8 unless it is object recognition, and even then it excludes blind users. An audio CAPTCHA that must be transcribed is not an accessible alternative under the W3C Understanding document, and maths or logic puzzles are not excepted. Practical options:

1. Move bot detection behind the scenes: rate limits, risk scoring and device signals, challenging only suspicious traffic.
2. Where a challenge is needed, offer a non-cognitive alternative path, such as a passkey, an emailed link for low-assurance flows or a support route.
3. Never challenge users who are already strongly authenticated.

The CAPTCHA and bot challenges guide covers challenge types, privacy-preserving tokens and layered bot defence in depth.

Timeouts and sessions

Security timeouts protect unattended sessions, but short, silent ones hit people who need more time. Design them to meet both needs:

• Warn before expiry: NIST gives about two minutes as an example for inactivity warnings; WCAG 2.2.1 sets at least 20 seconds to respond with a simple action. The warning must be announced to screen readers and keyboard-focusable.
• Save work: before a fixed reauthentication, prompt users to save, and preserve form data where safe so re-authentication does not mean starting again.
• Separate risk levels: keep strict timeouts for privileged and high-risk sessions; give longer, extendable limits to low-risk reading and form filling.
• Accessible log off: a clearly labelled sign-out control, as NIST section 8 recommends.
• Re-authenticate with a passkey: a device prompt is quicker and needs no memory, so frequent re-authentication costs less.

Where identity fits: accessible and secure fallbacks

When the main sign-in fails a user, the fallback is usually a help desk call, an account recovery form or a trusted person. Each is an identity control.

• Help desk: offer text relay, chat and video options as well as voice, but verify identity with methods public information cannot satisfy. The MGM Resorts breach began, by the attackers' own account, with a help desk call impersonating an employee found on LinkedIn. See the Account Recovery and Help Desk Security Guide.
• Delegated access: where a carer or family member needs to help, give them their own credential with defined permissions rather than sharing the user's password. NIST SP 800-63B-4 also says credential service providers should not prevent a device from being registered as an authenticator by more than one subscriber, although public-facing services may limit this to prevent fraud.
• Recovery: recovery must also have a path without a cognitive test under WCAG 3.3.8; a second registered passkey or hardware key is both accessible and strong. See the Passkey account recovery guide.
• Shared and frontline devices: see the Passwordless for Frontline and Shared Devices Guide.

How to implement

1. Inventory the journeys: list every authentication, registration, recovery, step-up and timeout flow, including vendor-hosted pages such as the identity provider's sign-in and MFA screens.
2. Audit against the requirements: check each step against WCAG 3.3.8, 3.3.7 and 2.2.1 and the NIST SP 800-63B-4 points above. Flag paste blocking, transcription-only codes, CAPTCHA without alternatives and silent timeouts first.
3. Test with assistive technology and with disabled users: screen readers, screen magnification, voice control and switch access on desktop and mobile. Automated checkers miss most authentication issues, so include manual and user testing.
4. Fix the quick wins: allow paste and autofill, add autocomplete attributes, add a show password toggle and timeout warnings. These rarely need a security trade-off.
5. Add an accessible default: pilot passkeys or device approval with a group that includes assistive technology users, then widen the rollout. Keep the old method available until the new one is proven.
6. Rework fallbacks: text and video help desk channels with strong verification, delegated access and secure recovery.
7. Roll back safely: release changes behind feature flags so a regression in an assistive technology combination can be reverted without removing other paths.
8. Write it into policy and procurement: require WCAG 2.2 AA conformance, including 3.3.8, in identity provider and vendor contracts, and in the authentication policy.

Detection and measurement

• Authentication completion rate by method: drop-off at each step, especially CAPTCHA and one-time code entry.
• Lockouts and resets per 100 users: rising numbers often signal an inaccessible step.
• Help desk contacts tagged as accessibility: volume and resolution time, and how many ended in a manual override.
• Share of users on passkeys or device approval: fewer cognitive tests and less phishing exposure.
• Timeout extensions: how often users extend sessions; frequent extensions suggest the limit is too short for that task.
• Open accessibility defects in authentication flows: count and age, from audits and user reports.

Log help desk overrides and delegated access grants and review them, as both are routes an attacker may try.

Framework mapping

Common failure patterns

• Paste blocked "for security": it pushes users to weaker passwords and fails WCAG 3.3.8 and NIST guidance.
• Accessible sign-in, inaccessible recovery: the main flow passes an audit, but recovery relies on security questions or a typed code.
• Audio CAPTCHA as the accessible option: transcription is still a cognitive test and excludes deaf users.
• Voice-only help desk with weak verification: excludes deaf users and gives attackers the easiest route to a reset.
• Biometric-only mobile apps: no alternative for people whose biometrics do not capture reliably, contrary to NIST SP 800-63B-4.
• Testing only the organisation's own pages: the identity provider or MFA vendor screens are never tested with assistive technology.

Practitioner checklist

• Map every authentication, recovery and timeout flow, including vendor-hosted screens.
• Allow paste and autofill in all password and code fields, with correct autocomplete attributes.
• Provide at least one path through sign-in and recovery with no cognitive function test.
• Offer passkeys or hardware keys and let users choose their authenticator.
• Provide a non-biometric alternative wherever biometrics are used.
• Replace CAPTCHA-only gates with background bot detection and a non-cognitive alternative.
• Warn before timeouts, allow extension and preserve work.
• Offer text, chat and video support with verification that public information cannot satisfy.
• Test with assistive technology users before and after each change.
• Write WCAG 2.2 AA, including 3.3.8, into identity vendor contracts.

Standards and references

• W3C: Understanding SC 3.3.8 Accessible Authentication (Minimum)
• W3C: Understanding SC 2.2.1 Timing Adjustable
• W3C: Understanding SC 3.3.7 Redundant Entry
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• W3C: Making Content Usable for People with Cognitive and Learning Disabilities
• US Department of Justice: ADA Title II web and mobile accessibility rule
• EUR-Lex: Directive (EU) 2019/882 European Accessibility Act
• European Commission: European Accessibility Act

Related NHI Mgmt Group resources: Usable Security and Human Factors Guide · CAPTCHA and bot challenges · Passkeys for Everyone Guide · Account Recovery and Help Desk Security Guide