Skip to main content
Accessibility.com, LLC
Category: WCAG Principles and Conformance

Accessible Authentication

Also known as: Accessible Authentication (Minimum), Accessible Authentication (Enhanced), WCAG SC 3.3.8, WCAG SC 3.3.9
Simply put

Accessible authentication refers to designing login and sign-in processes so that people with disabilities can complete them, including those who use assistive technologies, alternative input methods, or constrained devices. The goal is to provide a way to log in that is easy to use and secure without requiring tasks that some users may struggle with, such as memorizing and transcribing complex information or solving puzzles. This helps ensure that verifying your identity does not become a barrier to accessing content or completing tasks.

Formal definition

Accessible Authentication is addressed in WCAG 2.2 through two success criteria published by the W3C Web Accessibility Initiative: SC 3.3.8 Accessible Authentication (Minimum), a Level AA criterion, and SC 3.3.9 Accessible Authentication (Enhanced), a Level AAA criterion. Both were added in WCAG 2.2 and are intended to ensure there is an accessible, easy-to-use, and secure method for users to authenticate when logging in and undertaking tasks. In general terms, these criteria seek to avoid requiring a cognitive function test (such as recalling a password or solving a puzzle) as part of authentication unless an accepted alternative is provided, with the Enhanced (AAA) criterion imposing stricter conditions than the Minimum (AA) criterion. Meeting these success criteria supports conformance to a stated WCAG level but does not by itself guarantee an accessible experience for all users; manual and assistive technology testing remains necessary, and this entry is not legal advice.

Why it matters

Authentication is a gateway task: if a person cannot complete a login or identity-verification step, everything behind that step becomes inaccessible to them, regardless of how well the underlying content is designed. Common authentication patterns place substantial demands on memory and cognitive processing, such as requiring users to recall and accurately transcribe complex passwords or to solve puzzles like CAPTCHAs. These tasks can present significant barriers for people with cognitive or learning disabilities, and can also be difficult for people using assistive technologies, alternative input methods, or constrained devices.

Recognizing this, the W3C added two success criteria in WCAG 2.2 that directly address authentication: SC 3.3.8 Accessible Authentication (Minimum) at Level AA and SC 3.3.9 Accessible Authentication (Enhanced) at Level AAA. Their shared purpose is to ensure there is an accessible, easy-to-use, and secure method for users to authenticate when logging in, accessing content, and undertaking tasks. Because Level AA is the conformance level most commonly cited as a target in policy and settlement contexts, the Minimum criterion in particular is likely to factor into how organizations evaluate their login flows.

Meeting these success criteria supports conformance to a stated WCAG level, but it does not by itself guarantee an accessible experience for every user or immunity from legal claims. Automated tools detect only a portion of potential issues, so manual and assistive technology testing remains necessary. This entry is informational and not legal advice; organizations with questions about their specific obligations should consult qualified legal counsel and monitor current agency rulemaking, as requirements continue to evolve through regulation and case law.

Who it's relevant to

Accessibility engineers and developers
Those implementing login and identity-verification flows need to understand that SC 3.3.8 (AA) and SC 3.3.9 (AAA) were added in WCAG 2.2 and generally discourage cognitive function tests unless an accepted alternative is provided. They are responsible for building authentication that works with assistive technologies, alternative input methods, and constrained devices, and for confirming this through manual and assistive technology testing rather than automated checks alone.
UX and product designers
Designers shape whether authentication requires users to memorize, transcribe, or solve puzzles. Applying these criteria means designing sign-in experiences that are easy to use and secure without imposing unnecessary cognitive demands, so that identity verification does not become a barrier to accessing content or completing tasks.
Compliance officers and accessibility program managers
Because Level AA is the conformance level most commonly cited as a target, teams evaluating their programs against WCAG 2.2 should account for SC 3.3.8 as part of an AA assessment and consider SC 3.3.9 where a stricter AAA target applies. Meeting these criteria supports conformance to a stated WCAG level but does not guarantee an accessible experience for all users or immunity from legal claims.
Legal counsel and business leaders
Counsel advising on accessibility should note that these are technical success criteria published by the W3C, not statutory text, and that requirements evolve through regulation and case law. Whether and how WCAG 2.2 criteria apply to a specific organization depends on the applicable legal authority and jurisdiction; this entry is not legal advice, and qualified legal counsel should be consulted for specific obligations.
Users with disabilities
The intended beneficiaries include people who use assistive technologies, alternative input methods, or constrained devices, as well as those for whom memorizing and transcribing complex information or solving puzzles presents a barrier. Accessible authentication aims to give these users an easy-to-use and secure way to log in and complete tasks.

Inside Accessible Authentication

Accessible Authentication (WCAG Success Criterion)
A concept addressed by WCAG success criteria introduced in WCAG 2.2, specifically Success Criterion 3.3.8 Accessible Authentication (Minimum) at Level AA and Success Criterion 3.3.9 Accessible Authentication (Enhanced) at Level AAA. These criteria aim to reduce the cognitive burden of logging in and verifying identity.
Cognitive Function Test
A task that requires a user to remember, transcribe, manipulate, or recognize information from memory, such as recalling a password, solving a puzzle, or transcribing characters. The Accessible Authentication criteria generally seek to avoid making such tests a required step unless an accessible alternative is provided.
Permitted Alternatives and Exceptions
Mechanisms that satisfy the criteria without imposing a cognitive function test, which may include allowing password managers to fill fields, supporting copy-and-paste, or offering alternative authentication methods. The criteria also recognize certain exceptions, such as object recognition or identifying non-text content the user provided.
Distinction Between Minimum (AA) and Enhanced (AAA)
The Level AA version (3.3.8) permits some object-recognition and personal-content mechanisms as exceptions, while the Level AAA version (3.3.9) is more restrictive. AA is the conformance level most commonly cited as a target in policies and settlements.
Relationship to Broader Accessibility and Security
Accessible authentication intersects with security practices such as multi-factor authentication and CAPTCHA use, requiring designers to balance security requirements against the goal of not forcing users to perform memory-based or transcription tasks.

Common questions

Answers to the questions practitioners most commonly ask about Accessible Authentication.

Does Accessible Authentication mean I have to remove passwords entirely from my login process?
No. Accessible Authentication does not require eliminating passwords. The relevant WCAG success criteria address cognitive function tests, such as memorizing or transcribing a password, by requiring that an alternative authentication method be available, or that a mechanism assist the user (for example, allowing password managers to fill fields or permitting copy and paste). You may continue offering passwords as long as users are not forced to rely solely on recalling or manually transcribing information as a cognitive function test. Consult the current WCAG text for the precise wording of the applicable criteria.
Is completing a CAPTCHA always a violation of accessible authentication requirements?
Not automatically. The concern is with authentication steps that require a cognitive function test without an accessible alternative or supporting mechanism. Object-recognition and content-recognition tests are commonly treated differently from tests that depend on recalling or transcribing information. Whether a particular CAPTCHA meets the criteria depends on its specific design and whether accessible alternatives are provided. This is a technical conformance question, not a guarantee of legal compliance; consult qualified counsel for legal exposure and the current WCAG text for criterion details.
Which WCAG success criteria relate to Accessible Authentication?
Accessible Authentication is addressed by success criteria introduced in WCAG 2.2, which include a base-level requirement and a more stringent related criterion. These criteria generally require that steps in an authentication process do not rely on a cognitive function test unless an alternative method exists, a mechanism assists the user, or the test involves recognizing objects or user-provided non-text content. Because these criteria were added in WCAG 2.2, they do not appear in WCAG 2.0 or 2.1. Refer to the published WCAG 2.2 specification for the exact criterion numbers, conformance levels, and normative wording.
How can I let users authenticate without forcing them to memorize or transcribe information?
Common approaches include allowing password managers and browser autofill to populate credential fields, permitting copy and paste into authentication fields, supporting email or link-based sign-in, and offering methods such as biometrics or hardware security keys where appropriate. The goal is to avoid making recall or manual transcription the only path. The suitability of any specific method depends on your security requirements and user base, so evaluate options against both accessibility criteria and your organization's security policies.
Do we need to test authentication flows manually, or is automated testing sufficient?
Automated testing detects only a portion of accessibility issues and is generally not sufficient to confirm that an authentication flow meets the relevant criteria. Cognitive-function considerations, the presence of a working alternative method, and the real behavior of assistive technologies typically require manual review and testing with assistive technology such as screen readers. Combine automated checks with manual and assistive-technology testing, ideally including people with disabilities, to evaluate the full flow.
Does meeting the Accessible Authentication criteria protect us from legal claims?
Conformance with WCAG success criteria supports accessibility but does not by itself guarantee an accessible experience for every user or immunity from legal claims. In the US, obligations may arise under the ADA, Section 508, or other authorities depending on the entity and context, and requirements continue to evolve through regulation and case law. This guidance is not legal advice; consult qualified legal counsel and monitor current agency rulemaking to assess your specific obligations.

Common misconceptions

Accessible Authentication has always been part of WCAG, so any WCAG-conformant site already meets it.
The Accessible Authentication success criteria were added in WCAG 2.2 and do not appear in WCAG 2.0 or 2.1. A site conforming to an earlier version would not necessarily address these criteria, so the WCAG version being targeted matters.
Meeting the Accessible Authentication criteria means the login process is fully accessible and legally compliant.
Conformance with these success criteria does not guarantee an accessible experience for all users or immunity from legal claims. Automated testing detects only a portion of issues, and manual and assistive technology testing are generally required. These criteria address specific cognitive-load concerns and do not cover every barrier a user may encounter.
Any use of CAPTCHA or multi-factor authentication automatically violates the criteria.
The criteria focus on avoiding cognitive function tests without an accessible alternative rather than banning security measures outright. Security mechanisms can often be implemented in ways that provide alternatives, and the criteria recognize certain exceptions. The determining factor is generally whether an accessible path exists, not the presence of the security feature itself.

Best practices

Support password managers and allow copy-and-paste into authentication fields so users are not required to memorize or manually transcribe credentials.
Offer at least one authentication method that does not depend on a cognitive function test, and provide accessible alternatives where a memory- or transcription-based step is otherwise used.
When targeting WCAG 2.2, confirm which conformance level applies, since Level AA (3.3.8) permits certain exceptions that the more restrictive Level AAA (3.3.9) does not.
Evaluate CAPTCHA and multi-factor authentication flows for accessible alternatives, balancing security requirements against the goal of reducing cognitive load.
Validate login and identity-verification flows with manual and assistive technology testing rather than relying on automated checks alone, since automated tools detect only a portion of issues.
Consult qualified legal counsel and current agency rulemaking when tying authentication requirements to compliance obligations, as requirements evolve through regulation and case law and this guidance is not legal advice.