Add a11y guidance for user agents

[MasterKale]

This PR adds informative guidance to user agents encouraging them to mediate presentation and issuance requests in a way that supports a wide range of accessible inputs and outputs.

The intent is to submit this content in the horizontal review request to the a11y-request repo.

Related to #229

The following tasks have been completed:

• Modified Web platform tests - not testable by WPT.

Implementation commitment:

• WebKit - Safari correctly labels QR codes, allows aborting with keyboard.
• Chromium - correctly labels QR codes, allows aborting with keyboard.
• Gecko (link to issue)

Documentation and checks

• Affects privacy
• Affects security
• Pinged MDN
• Updated Explainer
• Updated digitalcredentials.dev

---

Preview | Diff

[marcoscaceres]

This is good, though quite broad and generally applicable to any UI. As we depend on the Credential Management API for credential selection, we need to push this down to the CM API level instead (if not already covered):
https://w3c.github.io/webappsec-credential-management/#user-mediated-selection

Then in our spec we would just say, "See the Credential Management API for the Accessibility Considerations when selecting a credential."

[wseltzer]

Discussed 11 June minutes

[marcoscaceres]

The the holder serves as a "credential chooser", which needs to:

• be keyboard accessible particularly allowing the user to abort an request or issuance operation (e.g., you should be able to hit "esc" to abort the operation)
• present what is being requested should accessible to screen readers.
• Make sure the QR code is labelled

[mohamedamir]

The the holder serves as a "credential chooser", which needs to:

@marcoscaceres
I think we shouldn't mix those concepts.
"credential chooser" aggregates the credentials from multiple "holders".

Matt: also what is the plan with this PR? @MasterKale

[marcoscaceres]

I think we should provide the guidance I proposed in #238 (comment) ... those were things that could have been better in Safari's implementation, so this was helpful (even if it applies specifically to holders).

[TallTed]

@mohamedamir --

"credential chooser" aggregates the credentials from multiple "holders".

I think, rather --

"credential chooser" aggregates one or more credentials from one or more "holders", from which the user can choose which credential to use for a given purpose.

[MasterKale]

Matt: also what is the plan with this PR?

My plan has been to incorporate Marcos' suggestions into the next iteration. I'll update this PR by our next B-series meeting on Wednesday.

[MasterKale]

"credential chooser" aggregates the credentials from multiple "holders".

Can this spec propose guidance for holders? It's been my assumption that Verifiers and now "Credential Choosers" are fair game, but since Holders work with Credential Choosers that's probably the protocol that influences Holder behavior around a11y, no?

[MasterKale]

Alright, I've finally taken a stab at incorporating the feedback provided thus far. @mohamedamir @marcoscaceres can you please take a look when you have a chance?

[marcoscaceres]

@MasterKale, are you going to keep working on this or would like me to take it over?

[MasterKale]

@marcoscaceres @mohamedamir @timcappalli The accessibility section has been marked class="informative", so Respec says the section is non-normative:

Does the inclusion of SHOULD and MUST in the current version of the text mean this class should be dropped accordingly?

[mohamedamir]

"credential choosers" are out of scope for this API, this it is the responsibility of the underlying platform to display them.
Not sure if this actually fits here.

[MasterKale]

Okay, good point. This should really be about user agents, that might put some UI before invoking the credential chooser, making that UI accessible. Could a simple replacement here work?

[marcoscaceres]

I'm ok with keeping [=credential choosers=] here... the API still needs to present a credential chooser because Cred Man explicitly requires it as part of the get a credential steps.

[MasterKale]

I dug into the CredMan definition that [=credential choosers=] ends up getting linked to, and it's to a section on User Mediated Selection that talks about credential choosers as something that User Agents implement:

https://www.w3.org/TR/credential-management-1/#user-mediated-selection

When responding to a call to get() on an origin which requires user mediation, user agents MUST ask the user for permission to share credential information. This SHOULD take the form of a credential chooser which presents the user with a list of credentials that are available for use on a site, allowing them to select one which should be provided to the website, or to abort the request entirely.

This must be what @marcoscaceres is referring to above (I'm making this connection more for my benefit.) So perhaps it's okay to keep the mention of credential choosers here. @mohamedamir might this change your mind about this particular section of accessibility guidance?

[mohamedamir]

@marcoscaceres @mohamedamir @timcappalli The accessibility section has been marked class="informative", so Respec says the section is non-normative:
Does the inclusion of SHOULD and MUST in the current version of the text mean this class should be dropped accordingly?

You are right, if we are going to stick with SHOULD and MUST we should drop this class IMHO.

[wseltzer]

Discussed 3 September minutes.

[marcoscaceres]

I think this is nearly there... just tightened up the text a little bit.

[MasterKale]

Thanks for the review @marcoscaceres, I've incorporated those changes. There's only one remaining conversation above, otherwise this PR is ready for @mohamedamir and @timcappalli's review.