Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add Accessibility Considerations section #1558

Merged
merged 8 commits into from Feb 17, 2021
Merged

Add Accessibility Considerations section #1558

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
8219710
Add Accessibility Considerations section
equalsJeffH Feb 4, 2021
b18853c
add authn ceremony & correct WCAG21 ref
equalsJeffH Feb 4, 2021
00a5760
add that platf may fixup RP-supplied timeouts
equalsJeffH Feb 4, 2021
231b96c
incorp lgarron's suggestion, thx!
equalsJeffH Feb 10, 2021
82873d5
add suggestion to offer > 1 UV method
equalsJeffH Feb 11, 2021
ed234cc
polish
equalsJeffH Feb 11, 2021
ca5ed65
Incorp emlun's suggestion,thx!
equalsJeffH Feb 17, 2021
aba7dd6
incorp another @emlun suggestion, thx!
equalsJeffH Feb 17, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
9 changes: 9 additions & 0 deletions index.bs
View file
Open in desktop
Expand Up @@ -7052,6 +7052,15 @@ the [=[RP]=] could mitigate the privacy leak using the same approach of returnin
as discussed in [[#sctn-username-enumeration]].


# Accessibility Considerations # {#sctn-accessiblility-considerations}

[=User verification=]-capable [=authenticators=], whether [=roaming authenticators|roaming=] or [=platform authenticators|platform=], should offer users more than one user verification method. For example, both fingerprint sensing and PIN entry. This allows for fallback to other user verification means if the selected one is not working for some reason. Note that in the case of [=roaming authenticators=], the authenticator and platform might work together to provide a user verification method such as PIN entry [[FIDO-CTAP]].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the "should"s throughout the section be "SHOULD"s? I see there's a normative "MAY" in the last sentence.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think not in the 1st parag since that is with regards to authenticators themselves and this is not an authenticator-oriented spec.

I think yes in 2nd parag, since that is wrt Relying Parties.


[=[RPS]=], at [=registration=] time, SHOULD provide affordances for users to complete future [=authorization gestures=] correctly. This could involve naming the authenticator, choosing a picture to associate with the device, or entering freeform text instructions (e.g., as a reminder-to-self).

[=Ceremonies=] relying on timing, e.g., a [=registration ceremony=] (see {{PublicKeyCredentialCreationOptions/timeout}}) or an [=authentication ceremony=] (see {{PublicKeyCredentialRequestOptions/timeout}}), ought to follow [[!WCAG21]]'s [Guideline 2.2 Enough Time](https://www.w3.org/TR/WCAG21/#enough-time). If a [=client platform=] determines that a [=[RP]=]-supplied timeout does not appropriately adhere to the latter [[!WCAG21]] guidelines, then the [=client platform=] MAY adjust the timeout accordingly.


# Acknowledgements # {#sctn-acknowledgements}
We thank the following people for their reviews of, and contributions to, this specification:
Yuriy Ackermann,
Expand Down