Passkey Accessibility

The World Health Organization (WHO) estimates 15% of the world’s population, or over one billion people, live with some form of disability. In many countries, laws prohibit discrimination against people with disabilities (PwD) to help ensure PwD fully and equally participate in every aspect of society. For example, 52 constitutions of the 193 United Nations member states explicitly guarantee equality or nondiscrimination on the basis of disability. Digital access has become increasingly important to many aspects of society, including, but not limited to, education, employment, and entertainment. Authentication, allowing private and secure access to these services, has become equally important.

Security codes delivered via text message or email are technically accessible, but they often require an advanced level of skill and knowledge for PwD using assistive technology to transfer the codes. FIDO technology is best positioned to simplify this process and provide accessible authentication, as it supports a wide range of options that can accommodate vastly diverse needs of PwD.

This section provides guidance on planning FIDO deployments accessible to users with a wide range of disabilities and also helps hardware manufacturers identify opportunities to deliver more accessible external authenticators.

Web Content Accessibility Guidelines (WCAG)

WCAG is an extensive set of accessibility guidelines developed by W3C, an international community that develops open standards to ensure the long-term growth of the web. Although WCAG was originally designed as web content standards, it has become well-recognized and accepted as an appropriate guide for non-web products as well. While WCAG is normative, many obligatory accessibility standards in various countries directly refer to WCAG or mirror WCAG criteria.

WCAG lists two sections that pertain to authentication:

1. WCAG Conformance of Authentication UI. Authentication UI, as part of the product experience, should be created in conformance with WCAG along with other parts of the product. The goal is to ensure authentication UI meets the baseline of being functional to PwD and compatible with assistive technologies. WCAG Level AA is often the conformance level to be fully met. Companies have various ways of achieving WCAG conformance: internal tooling and processes to support accessible design and development, external accessibility audits to identify non-conformance and provide remedial actions, and usability testing with PwD across a spectrum of abilities.

2. WCAG 3.3.7 Accessible Authentication Conformance. There is a proposed Accessible Authentication guideline in WCAG version 2.2 Success Criterion 3.3.73. The guideline states: “For each step in an authentication process that relies on a cognitive function test, at least one other authentication method is available that does not rely on a cognitive function test, or a mechanism is available to assist the user in completing the cognitive function test. Exception: When the cognitive function test is to recognize objects, or content the user provided to the website.

note

Objects and content for the exception can be represented by images, text, video or audio. Examples of mechanisms include:

• support for password entry by password managers to address the memorization cognitive function test
• copy and paste to help address transcription cognitive function test

The purpose of this guideline is to ensure there is an alternative to remembering a site-specific password (a cognitive function test). WCAG provides a few examples of ways to follow the guideline, which include FIDO offerings.

Ways to follow WCAG guidelines

• Allow for autofill by third-party credential managers. A website uses a properly marked up username (or email) and password fields as the sign-in authentication. The user's browser or integrated third-party credential manager extension can identify the purpose of the inputs and automatically complete the username and password.
• Allow for pasting passwords. A website does not block paste functionality. The user can use a third-party credential manager to store credentials, copy them, and paste them directly into a sign-in form.
• Use WebAuthn. A website uses WebAuthn so the user can authenticate with their device instead of a username/password. The user's device could employ any available modality. Common methods on laptops and phones are facial-scan, fingerprint, and PIN. The website is not enforcing any particular use; it is assumed a user will set up a method that suits them.
• Use OAuth. A website offers the ability to log in with a third-party provider using the OAuth framework.
• Use two-factor authentication. A website requiring two-factor authentication allows multiple options for the second factor, including the following: a USB-based method where the user simply presses a button to enter a time based token; a QR code display, which can be scanned by an app on a user's device to confirm identity; or a notification sent to a user's device and the user operates their device's authentication mechanism (for example, user defined PIN, fingerprint, or facial recognition) to confirm identity.

The W3C Accessibility Task Force has clarified4:

• Providing any current FIDO Authentication methods in addition to the username/password mechanism as an alternative will automatically pass 3.3.7 (assuming FIDO Authentication does not rely on cognitive function testing).
• When passwordless authentication is provided, as long as the passwordless authentication does not rely on a cognitive function test, it also conforms to WCAG.

Global accessibility laws

While WCAG is normative, many laws from various countries incorporate principles similar to those espoused in WCAG. Below is a non-exhaustive list of accessibility laws that might be applicable to a relying party’s products, including the products’ authentication experiences.

• Americans with Disabilities Act (ADA). Title III of ADA requires places of public accommodation within the U.S. to be accessible to PwD. By its terms, the ADA applies only to physical spaces, but courts have increasingly, though inconsistently, applied the ADA to websites, apps, and online storefronts.
• Section 504 and Section 508 of the Rehabilitation Act of 1973. Section 504 prohibits discrimination against PwD in any program or activity receiving financial assistance from the U.S. federal government. Section 508 stipulates any electronic or information technology developed, procured, maintained, or used by the federal government must be accessible. Consequently, federal agencies generally require that companies from which they purchase technology must also comply with Section 508. To this end, companies typically provide government customers with a document called an ACR (Accessibility Conformance Report) stating how each product addresses accessibility. Furthermore, technology covered by Section 508 aligns with WCAG compliance.
• 21st Century Communications and Video Accessibility Act (CVAA). The CVAA is a U.S. law enforced by the Federal Communications Commission (FCC) applying to products providing advanced communications services such as Voice over Internet Protocol (VoIP, for example, online calling or multiplayer voice chat), messaging services, video chat or conferencing services, and similar online communications.
• European Accessibility Act (EAA). The EAA became law in 2019, and it is designed to introduce common rules on accessibility across the EU to reduce costs for businesses, facilitate easier cross-border trading, and provide market opportunities for accessible products and services.
• Accessible Canada Act (ACA). The ACA is Canada’s federal legislation requiring federal entities and regulated industries (for example, telecom and banking) to procure and offer accessible information technology and communications technology, and will subject covered entities to new reporting requirements.
• Japanese Industrial Standards (JIS) X 8341-3. JIS X8341-3 provides guidance for both public and private sector organizations on compliance with WCAG in Japan.

Current models of accessible FIDO Authentication

Current FIDO Authentication deployment of relying parties largely follows unique models for both of FIDO’s authentication protocols, the WebAuthn model, and the UAF (Universal Authentication Framework) model. A key difference between WebAuthn and UAF is the relying party's level of control over authentication modalities. In the context of WebAuthn, relying parties are unlikely to, and should not, discriminate based on modalities, even though it is technically possible. While in UAF, relying parties are able to define which modalities are available to end users. We discuss the two models separately as they require different considerations with regards to accessible deployment.

Responsibility model and deploying accessible WebAuthn

Web Authentication (WebAuthn) is a core component of FIDO2 and a web standard published by W3C. WebAuthn provides a standardized interface for authenticating users to web-based applications and services using public-key cryptography.

WebAuthn Model of Accessible Authentication

There are three parties in the WebAuthn model of accessible authentication responsibility:

• End users with disabilities
• User agents: any software or hardware, including assistive technologies, that help in retrieving, rendering, and interacting with relying party’s applications (for example, mobile phones, browsers, screen readers, and other non-mouse interactions)
• Relying party applications, including the authentication parts of the applications

Each party is partly responsible for an accessible authentication experience.

• End users choose user agents most accessible to themselves. The onus is on end users to choose the user agents supporting authenticators they are able to use.
• End users might buy smart phones that come with face recognition, a fingerprint reader, and similar biometric components. It is assumed end users would choose devices and set up authentication methods suiting their accessibility needs and preferences.
• End users might buy security keys from the market. Similarly, it is assumed end users would choose security keys that suit them.
• User agent developers create UAAG-conforming user agents. By conforming to User Agent Accessibility Guidelines (UAAG), user agent developers make user agents more accessible to PwD and compatible with assistive technologies. WebAuthn rendered on such user agents will be accessible as well.

User agent developers and the W3C WebAuthn Working Group ensure compatibility between user agents and WebAuthn.

• As WebAuthn has become a widely accepted authentication model, it is supported by most popular user agents. If incompatibility is detected, relying parties are advised to file an issue to the W3C WebAuthn Working Group and alert user agent developers.
• Responsibility of relying parties
  • Relying parties ensure their applications are compatible with user agents that support WebAuthn.
  • Relying parties create accessible hardware (ATMs, ticketing kiosks), software (webpages, mobile apps), and training materials (text or multimedia) by practicing widely adopted accessibility guidelines (for example, WCAG, Section 508, EN 301 549). Relying parties might be required to produce a completed ACR identifying how the product complies or does not comply with these standards. End-to-end testing with PwD and people using assistive technologies is strongly encouraged to validate interactions leading up to and through the authentication process, which will help ensure the entire user flow is accessible to the widest audience.
• Relying parties conform to WCAG 3.3.7 by providing at least one method of authentication not relying on cognitive function tests. Supporting WebAuthn automatically meets WCAG 3.3.7 requirements because WebAuthn is a sufficient technique. See WCAG 3.3.7 Accessible Authentication Conformance.
• When providing hardware directly to end users (for example, company providing hardware to employees, or financial institutions providing hardware to end users), relying parties should provide options for end users to choose those with authenticators accessible to them. If no option is accessible to the user, the relying party should provide alternative authentication means.
• If it is impractical for relying parties to solicit user selection, relying parties should conform to Section 508 Provision 403, which states, “Where provided, biometrics shall not be the only means for user identification or control. EXCEPTION: Where at least two biometric options that use different biological characteristics are provided, ICT shall be permitted to use biometrics as the only means for user identification or control.”

Responsibility model and deploying accessible UAF

The FIDO UAF protocol allows online services to offer passwordless and multi-factor security. The user registers their device to the online service by selecting a local authentication mechanism such as swiping a finger, looking at the camera, speaking into the mic, or entering their PIN for example.

The UAF protocol allows the service to select which authenticators are presented to the user for selection, which is a key difference between this model and the WebAuthn model. Once registered, the user simply repeats the local authentication action whenever they need to authenticate to the service. The user no longer needs to enter their password when authenticating from that device. UAF also allows combining multiple authentication mechanisms such as fingerprint + PIN.

UAF Model of Accessible Authentication

For accessible UAF deployment, relying parties should adopt the following recommendations for UAF policy control:

1. Mobile apps should always allow phone-unlocking authentication as an option. a. WebAuthn supports phone-unlocking authentication. UAF is a more flexible model and should support phone-unlocking modalities as a fallback. As stated previously in the WebAuthn discussion, the burden is on end users to choose user agents that support authenticators they are able to use.
2. Mobile apps should allow silent authentication as much as is feasible. Also known as passive or invisible authentication, silent authentication occurs in the background without the user having to actively provide their credentials or perform any action. Instead, the user's identity is verified using previously established authentication factors, such as cookies, device fingerprints, or biometric data. a. Silent Authentication on smart phones and smart watches provides a strong (phishing-resistant) possession factor authentication using the standardized FIDO protocol. With this technology, mobile native applications can authenticate the user by trusting the device. Some information might be available to users without requiring additional actions (for example, showing the account balance on the user’s device). b. We recommend relying parties take advantage of silent authentication because it allows smoother UX for all people, including PwD. However, silent authentication should not be offered to PwD as a more accessible but less secure option. Instead, it should be an option equally accessible and equally secure for all users.
3. Phone-unlocking authentication should be allowed as a fallback/substitute for less secure modalities.
4. When the mobile app requires one biometric authentication, the mobile app must provide two or more biometric options requiring different physiological characteristics. a. Example: If voice authentication is required, the mobile app must allow the user to authenticate through another biometric option not requiring voice, such as face recognition or fingerprint.
5. When the mobile app requires more than one (N) biometric authentication modality, the mobile app must provide at least N+1 biometric options requiring different physiological characteristics.

note

Points four and five can be implemented by providing an option to load custom authenticators.

Mobile App Authentication that uses UAF protocol, allowing the service to select authenticator (example)

Unique aspects of FIDO Authentication related to disabilities

Each FIDO Authentication feature might pose barriers to users with certain types of disabilities. The Unique Aspects of FIDO Authentication for People with Disabilities mapping for relying parties can help you understand potential barriers each authentication modality might cause. Relying parties might use the mapping to identify modality provisionings that are accessible to as many users as is practical. This is a guide and not intended as an exhaustive list of considerations.

Disabilities pertaining to FIDO Authentication

Disabilities are vastly diverse. For simplicity in the discussion of FIDO Authentication, we refer to the following five types of disabilities that appear to be most relevant to authentication.

1. Visual: blindness, low vision, visual field loss, color blindness, or iris loss
2. Hearing: profound deafness, hearing muffled sounds, hearing with one ear, or other sounds interfering with hearing
3. Physical: limb loss, digit loss, limited strength or weakness, limited reach, tremor or palsy loss of fingerprints, or loss of facial features
4. Speech: loss of speech, trouble speaking loud enough, or trouble being understood
5. Cognitive and learning: difficulty reading (dyslexia), difficulty writing, memory loss, low literacy, low digital literacy, or difficulty reasoning

FIDO authentication features

From a user experience perspective, FIDO Authentication can be categorized by user interactions:

• Touch
  • Touch security key for user presence check
• Type
  • Type client PIN or screen-unlocking PIN -Scan
  • Fingerprint scan
  • Vein scan
  • Iris scan (look into camera)
  • Face scan
• Speak
  • Voice recognition
• Move
  • Insert a security key in a USB port
  • Scan security keys via NFC with smart phones
  • Draw a pattern on screen to unlock smart phones
  • Activate buttons for actions
  • Touch screen for selecting actions
  • Use mouse or alternative input devices for selecting actions
  • QR code scan for pairing a device
• Read
  • Instructions on screen
• Timer
  • Complete authentication within limited time

Potential access barriers in FIDO Authentication

This section summarizes the difficulties for PwDs for each user interaction. Relying parties who are deploying FIDO Authentication must understand these difficulties. A mapping between FIDO Authentication methods and disabilities can be found in the table Unique Aspects of FIDO Authentication for People with Disabilities: Potential issues or the narrative version of the table.

• Touch
  • People with physical disabilities might have difficulty in reaching or accurately targeting security keys, especially small keys or keys with small, depressed, active touch areas.
• Type
  • Memorizing a username and password (or transcribing either manually) might place a burden on people with certain cognitive disabilities and people using assistive technology.
  • The process of entering passwords, either on a mobile device or on a webpage, can be more accessible by implementing password interfaces meeting WCAG compliance.
• Scan
  • Scan of physiological characteristics might pose barriers to people who do not have these physiological characteristics. For example, people with digit amputations or adermatoglyphia (a genetic disorder preventing the development of fingerprints) might not be able to use fingerprint authentication. People with excessively dry skin are also likely to fail fingerprint scans. Some blind users might not be able to use iris recognition or facial recognition that requires open eyes, or for the users to look at the camera.
  • Users with visual disabilities might also find it difficult to locate a scanner and scan security keys via NFC with smart phones.
• Speak
  • Voice recognition might not work well for people with speech and language disabilities. Some deaf and hard of hearing people who do not use oral communication might not be able to use voice recognition either.
• Move
  • People with physical disabilities might not be able to insert a security key in a USB port, scan a security key on a smart phone or draw a pattern on a smart phone.
  • People with certain cognitive disabilities might find it difficult to memorize a pattern gesture to perform on a touchscreen.
  • QR code scanning can be challenging for users with visual disabilities. Such users might find it difficult to locate a QR code and position a camera to scan the code. QR code can also be difficult for people with physical disabilities because it requires the user not only to hold a camera, but also to hold it steady.
• Read
  • People with certain learning disabilities, people with low literacy or low digital literacy, or people with memory issues might find instructions about authentication difficult to understand. Instructions can be made more accessible by following the WCAG Cognitive Accessibility Guidelines.
• Timer
  • Some PwD might need more time to complete authentication: they might take longer to physically respond, they might take longer to read things, they might have low vision and take longer to find things or to read them, or they might be accessing content through an assistive technology that requires more time. WCAG provides a set of guidelines on providing users enough time to read and use content. Except in cases where the time limit is essential and extending the time limit would invalidate the authentication, relying parties might allow users to turn off, adjust, or extend the time limit. Refer to WCAG Success Criterion 2.2.1 Timing Adjustable for more details.

Unique Aspects of FIDO Authentication for people with disabilities: potential issues

User Gesture Actions	FIDO Feature Examples	Likelihood to encounter barriers with a visual disability	Likelihood to encounter barriers with a hearing disability	Likelihood to encounter barriers with a speech and language disability	Likelihood to encounter barriers with a physical disability	Likelihood to encounter barriers with a cognitive and learning disability
Touch	Touch security key for user presence check	Less	Less	Less	More	Less
	Draw a pattern on screen to unlock smartphones	Less	Less	Less	More	More
Type	Type client PIN	Less	Less	Less	Less	More
	Type screen unlock PIN	Less	Less	Less	Less	More
Scan	Fingerprint on scanner	Less	Less	Less	More	Less
	Vein	Less	Less	Less	More	Less
	Iris (look into camera)	More	Less	Less	Less	Less
	Face (camera)	More	Less	Less	Less	Less
	QR code (caBLE) screen and camera	More	Less	Less	More	More
Speak	Speaker recognition	Less	More	More	Less	Less
Move	Insert a security key in a USB port	Less	Less	Less	More	Less
	Scan security keys via NFC with smartphone	More	Less	Less	More	Less
	Click buttons for actions	Less	Less	Less	More	Less
	Touch screen to select actions	Less	Less	Less	More	Less
	Use mouse to select actions	More	Less	Less	More	Less
Read	Instructions on screen	Less	Less	Less	Less	More
Timer	Time limits for enrollment, registration, or authentication	More	Less	Less	More	More

Narrative description Unique Aspects of FIDO Authentication for people with disabilities

Table 1 describes how specific gestures involved with an authentication flow might be likely to pose more or fewer barriers for people by disability type. The following is a narrative depiction of the table.

People with visual disability might be more likely to have challenges with iris scan, face scan, QR code (caBLE) screen and camera scan, scanning security keys via NFC with smartphones, using a mouse to select actions, and enrollment, registration or authentication where time limits are set.

People with visual disability might be less likely to have challenges with touching a security key for user presence check, drawing a pattern on a screen to unlock smartphones, typing a client PIN, fingerprint or vein scan, voice recognition, inserting a security key into a USB port, selecting buttons for actions, touching a screen to select actions, and following on-screen instructions.

People with hearing, speech and language disabilities might be more likely to encounter barriers with voice recognition. They might be less likely to encounter barriers with all previously listed user gesture examples.

People with physical disabilities might be more likely to encounter barriers with touching a security key for user presence check, drawing a pattern on screen to unlock smartphones, fingerprint or vein scan, QR code (caBLE) screen and camera scan, inserting a security key into a USB port, scanning security keys via NFC with smartphones, selecting buttons for actions, touching screens for selecting actions, using a mouse for selecting actions, and enrollment, registration or authentication where time limits are set.

People with physical disabilities might be less likely to encounter barriers with typing a client PIN or screen unlock PIN, iris or face scan, voice recognition, and following on-screen instructions.

People with cognitive and learning disabilities might be more likely to encounter barriers with drawing a pattern on screen to unlock smartphones, typing a client PIN or screen unlock PIN, QR code (caBLE) screen and camera scan, following on-screen instructions, and enrollment, registration or authentication where time limits are set.

People with cognitive and learning disabilities might be less likely to encounter barriers with touching a security key for user presence check; fingerprint, vein, iris or face scan; voice recognition; inserting a security key into a USB port; scanning security keys via NFC with smartphones; and selecting buttons, touching screens or using a mouse for actions.

End table.

Accessibility audit

This section shares findings related to passkey accessibility based on screen reader audits for a limited group of live passkey deployments. This is for informational purposes only. Service providers are ultimately responsible for ensuring the passkey deployment is accessible in accordance with the Web Content Accessibility Guidelines (WCAG), the accepted global standards developed by the World Wide Web Consortium (W3C).

Scope

Screen reader audits of live passkey deployments were performed with the following OS/Browser/Screen reader combinations:

• Windows/Chrome/Jaws
• Windows/Chrome/NVDA
• Windows/Edge/Jaws
• Windows/Edge/NVDA
• Mac/Safari/VoiceOver
• Mac/Chrome/VoiceOver
• iPhone/Chrome/VoiceOver
• iPhone/Safari/VoiceOver

Key findings

1. Passkey registration and sign-in procedures were consistently accessible.

• Using various OS/browser/screen reader combinations with the creation and use of passkeys improved the experience for a blind consumer. The procedure was largely managed by the platform.

2. Accessibility defects were common before and after the passkey procedure.

• Audits across several live passkey deployments found that accessibility defects were common in the service provider's site as a whole. This is consistent with industry findings on the state of digital accessibility as reported by WebAIM’s 2023 Accessibility Report of the Top 1,000,000 Homepages.

3. Auto-complete and QR codes introduce accessibility barriers.

• Auto-complete was inconsistently implemented across the live deployments tested yielding inconsistent experiences for screen reader users. The implementation is required to support screen readers by announcing has popup to alert the screen reader user that content is available to navigate using the down arrow key. Some sites used the basic HTML auto complete attribute on a HTML input field and others used a custom input field with ARIA (Accessible Rich Internet Applications Suite), with specialized attributes added to code to make user interactions accessible for assistive technologies such as screen readers, which often is implemented incorrectly. Many browsers now support the basic HTML auto complete attribute announcing has popup on entry into the input field eliminating the need for additional ARIA. QR codes introduce barriers for individuals with mobility limitations or with vision limitations. Refer to the whitepaper, Guidance for Making FIDO Deployments Accessible for Users with Disabilities for more information. Refer to the video presentation Foundations for Passkey Accessibility for an overview of the accessibility findings including a screen reader demonstration on a live passkey deployment.

You can also refer to the Webinar: Making FIDO Deployments Accessible to Users with Disabilities, which covers accessibility experts from FIDO Alliance board member companies Meta and VMware discussing how to make your FIDO deployment accessible to users with a wide range of disabilities.