Request for an Accessibility Considerations section to API for Accessing Public key credentials CR

[becka11y]

An accessibility review was requested of the APA as part of our role in performing a horizontal review of W3C documents for accessibility concerns.

We reviewed Web Authentication: An API for accessing Public Key Credentials Level 2 W3C Candidate Recommendation Snapshot: https://www.w3.org/TR/webauthn-2/

The following comment (https://lists.w3.org/Archives/Public/public-apa/2020Dec/0021.html) was reviewed and approved via a CfC by the APA working group (https://lists.w3.org/Archives/Public/public-apa/2021Feb/0029.html):

We have concerns that could be best summarized in a new section "Accessibility Considerations" which could follow "Security Considerations" or "Privacy Considerations" in document order. References to timing considerations should be updated to reference this new subheading. See editor's draft https:/w3c.github.io/webauthn/. Additionally, based on the accessibility topics below, notes could be added to the appropriate sections (e.g., registration).

Proposed topics for "Accessibility Considerations":

1. Public key credentials should avoid using a single biometric factor. We would also like to call your attention to the W3C Note, Inaccessibility of CAPTCHA, Alternatives to Visual Turing Tests on the Web (https://www.w3.org/TR/turingtest/).
2. Registration should provide affordances for users to complete authorization gestures correctly. This could involve naming the authenticator, choosing a picture to associate with the device, or entering freeform text instructions.
3. Ceremonies that rely on timing must follow WCAG Guideline 2.2 Enough Time (https://www.w3.org/WAI/WCAG21/Understanding/enough-time).

Thank you for your consideration.

[equalsJeffH]

Regarding point (1) in #1557 (comment): the user verification modalities that may be employed during registration or authentication ceremonies are a product of (a) the capabilities of the authenticator, and whether the Relying Party "prefers" or "requires" user verification during the operation. The relying party (i.e., web site) can require user verification to occur during registration or authentication ceremonies, but cannot directly select the user verification method employed. E.g., if the authenticator supports both fingerprint or PIN, either may be used, and all that is typically reported to the relying party is that user verification occurred (in the successful case).

Thus your expressed requirement perhaps (?) can be re-expressed as:

Users ought to have available to them on their device+authenticator(s), more than one user verification means (e.g., a PIN as well some form of biometric sensor(s)) in those cases where their device+authenticator(s) support user verification.

Also note that WebAuthn can be used as a "second factor", i.e., typically in combination with username+password, and in those cases the user is not "verified", though a "user presence test" is employed (often asking the user to tap something (on screen, a physical button on their device or authenticator, etc). Depending on the device+authenticator(s) in play and the manifestation of the "user presence test", and the particular user's situation, there may or may not be accessibility concerns.

However, we are unsure whether such guidance is appropriate for the WebAuthn spec itself to provide. Are there examples of other Web Platform API specs that tread into such hardware/platform-specific territory?

Regarding point (2), I am finding the intent/purpose of "entering freeform text instructions" unclear?

Also: see PR #1558

[AutoSponge]

@equalsJeffH Thanks. I wrote most of the comment. The intent in # 2 is to allow users some control over the device configuration. Ideally, this would happen during registration. This makes the auth process more accessible but will also benefit people with multiple devices or who have long gaps between challenges and want to use the text input as a sort of "note to self: it's the blue one".

For # 1: as you indicated, it may not be possible to add normative specifications for this. But it can be added to "Accessibility Considerations" or in a note (non-normative). Think of it as a "note to implementors" where the advice to consider is who could be excluded by requiring a single, specific biometric input. Thus, the strong suggestion that implementors allow for choice and alternative inputs.

I hope this helps. I'm still new to this process so let me know if I can do anything else.

[brewerj]

Judy notes that this issue should be labeled "accessibility - needs resolution"
However, my labeling access is currently blocked. Asking PLH to add label. @becka11y can also add this at her discretion, as part of the horizontal review team. Also FYI @michael-n-cooper

[equalsJeffH]

I've updated PR #1558. AFAIK it now addresses all 3 points made in this issue's original post.

[michael-n-cooper]

APA is satisfied with this disposition.

[equalsJeffH]

@michael-n-cooper -- thanks!