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.

Partially closes #229

The following tasks have been completed:

• Modified Web platform tests (link)

Implementation commitment:

• WebKit (link to issue)
• Chromium (link to issue)
• Gecko (link to issue)

Documentation and checks

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

---

Preview | Diff

[timcappalli]

We've traditionally said that the browser only handles permission, not consent.

It seems we have a mismatch on the term definition / section title and meaning. Opened an issue here: #239

[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?