W3C

- DRAFT -

Accessible Platform Architectures Working Group Teleconference

08 Jan 2020

Attendees

Present
janina, jasonjgw, Matthew_Atkinson, Becka11y, Irfan, manu, JF, MichaelC, Joshue108
Regrets
Chair
janina
Scribe
Matthew_Atkinson

Contents


<Matthew_Atkinson> scribe: Matthew_Atkinson

Agenda Review & Announcements

Janina: Additional agendum: registering that we have interest in Verifiable Credentials.
... Manu is joining us as part of this.
... Exciting possibilities with emerging tech such as blockchain used to communicate people's needs and requirements without the need for third parties.
... Also setting out priorities for the year.

<Zakim> JF, you wanted to also mention Manu's need for use-cases...

JF: There's a need for more accessible use cases for Verifiable Credentials, so we could help with that.

Janina: the RQTF may have input here.

<manu> Matthew_Atkinson: A very small update on WebXR

<Joshue108> scribenick: Joshue108

MA: Where we left it was that we wanted to make sure we understood the purpose of the spec..

WebXR Gamepad module level 1

We wanted to know the spec purpose, simply to use a famililar API to make queries, or for users to use the game pad?

I'm still not 100% but looks like the former.

<Matthew_Atkinson> Latest update from list: https://lists.w3.org/Archives/Public/public-apa/2019Nov/0022.html

The explainer didn't say much to make this clearer

The question is, is that something that we think would be a good thing for a11y?

To support other input devices, and who else could we look to for these other things?

Looking to Josh..

Josh looking to Matthew *grin..

JS: Don't think this is quick..
... We'll need to discuss the various options..
... You can of course, confirm your understanding and ping the group on behalf of APA for clarification.

MA: I'll do that..

Verifiable Credentials and Accessibility

<Matthew_Atkinson> Janina: Jason from RQTF is joining to discuss about the need for more generalised use cases.

<Matthew_Atkinson> Janina: could be helpful to allow users to communicate their profile and requirements using these technologies for personalization.

<Matthew_Atkinson> Janina: focusing on two things: what do we need to do? and what time frame do we have?

<Matthew_Atkinson> Manu: Aiming to apply this technology to accessibility use cases ASAP (though no specific time crunch other than this).

<Zakim> manu, you wanted to provide some background on Verifiable Credentials and a longer-term vision for use in a11y and goals that might help us get there.

<Matthew_Atkinson> Manu: the first WG wrapped up having produced a W3C rec, which is being used in commercial deployments in payments, supply chain management, access to government services (which is where the accessibility use cases need first arose). Looking for other use cases around accessibility.

<Matthew_Atkinson> Manu: there was/is a re-chartered Verifiable Credentials WG vote. Looks like the group will be created and run for the next two years, with the goal of maintaining the existing recommendation.

<Matthew_Atkinson> Manu: requirement from APA: a set of high-priority use cases that show how accessibility can benefit from this technology. At least one is expected to be personalization.

<Matthew_Atkinson> Manu: examples of others: demonstrating the right to have access to a service, e.g. assertions from organisations that assess accessibility needs that can be used to show that people can access services that they are entitled to access by law.

Verifiable Credentials Use Cases https://www.w3.org/TR/vc-use-cases/

<Matthew_Atkinson> Manu: would like to see the issue of the first accessibility verifiable credential this year.

<Matthew_Atkinson> Manu: concenrs about various aspects such as the UI of the system itself for requesting/transmitting the credentials, as well as what the content of an accessibility verificable credential should be. What proves that a person has accessibility needs?

<Matthew_Atkinson> Manu: looking for someone who the verifiable credentials group can engage with in APA.

<Matthew_Atkinson> Janina: (asks about the relationship between verifiable credentials and decentralizd identifiers)

<Matthew_Atkinson> Manu: the teams are closesly related. Decentralized Identifiers is about not needing to rely on third parties.

<Matthew_Atkinson> Manu: the main question for APA is "what goes in a credential?"

<Matthew_Atkinson> Manu: (the other matters are lower-level infrastructure issues) [scribe's paraphrasing there]

<Matthew_Atkinson> JF: What is the technical structure of a credential? How is it encoded/made available to third parties?

<Matthew_Atkinson> JF: From work in Personalization TF: looking at a mechanism for encoding content (data-symbol attributes) - can mark-up code with additinoal info that references ID markers for various symbols, the idea being that some users rely on icons/symbols for communication.

<Zakim> JF, you wanted to ask about the credentials technical structure

to ask further clarification on relationship between DID and Verifiable Claims

<Matthew_Atkinson> JF: ...the idea being that when content is being provided in that way, the symbols shouldn't be showing up everywhere, but need to be able to identify that the symbol coding has been provided and that someone who needs symbols as their primary form of language can be recognised so that symbols are provided for them by default.

<Matthew_Atkinson> JF: there's Decentralized Identifiers and Verifiable Credentials and it seems both need to work together.

<Matthew_Atkinson> JF: We don't want to be exposing people as having disabilities (privacy concern).

<Matthew_Atkinson> Manu: We should be disregarding Decentralized Identifiers (analgoy: it's like talking about IP addresses whereas we're talking about the web).

<Matthew_Atkinson> Manu: (understands that there may be a need to represent the content of a page as symbols: question is how to communicate to the website that it needs to use symbols rather than the written word)

<Matthew_Atkinson> Janina: (confirms this understanding)

<Matthew_Atkinson> Manu: the way you would convey this to the website is to include a "needs symbols" property inside the verifiable credentials; the web server would respond accordingly.

<Matthew_Atkinson> Manu: what goes in a verifiable credential? key-value pairs

<Matthew_Atkinson> Manu: could have a "preference" credential, which is sent to the site, which then reacts accordingly.

<Matthew_Atkinson> JF: We'd like to understand technically how we achieve that - where does the information live; where's it contained; who produces it? If a user has a specific need that needs to be captured in a secure file used for personalization, that is less of an author responsibiltiy, more of a self-serve or third-party responsibility.

<Matthew_Atkinson> Janina: this may be more suitable for a deep-dive, but we do need to understand the whole chain/how the stack works.

<JF_> Symbols background & Personalization. P.O.C. here: https://github.com/w3c/personalization-semantics/issues/128, and our first draft here: https://w3c.github.io/personalization-semantics/content/index.html#symbol-example

<Matthew_Atkinson> Janina: would like to cover more aspects of things we can provide.

<Zakim> Joshue, you wanted to ask further clarification on relationship between DID and Verifiable Claims

<Matthew_Atkinson> Janina: we could even use this tech to translate between symbol dialects.

<Matthew_Atkinson> Josh: We're trying to discover broadly where the different responsibilites lie. (delivery, tokenisation, abstraction). For APA: we need to figure out who the actors are, the use cases and where the responsibilities rest.

<Matthew_Atkinson> Manu: For more info, the verifiable credentials ecosystem is described in the frontmatter of the spec.

<Matthew_Atkinson> Manu: Happy to do a deep dive after going over that.

<Matthew_Atkinson> Manu: the group is looking for breadth: all the different ways that this tech may be used. Would also like to see examples of the simplest things that have the most impact.

<Matthew_Atkinson> Manu: that would give the implementors something realisable to implement.

<Matthew_Atkinson> Manu: we need to start work on this as soon as possible; deliver the broad set of use cases over several months.

<Matthew_Atkinson> Manu: (essentially, they're looking for demonstrators, and things that usability testing can be based on)

<Matthew_Atkinson> Josh: (ACK, and we should be able to get info to you soon)

<Matthew_Atkinson> Josh: (asks about timelines)

<Matthew_Atkinson> Manu: that's up to APA

<Matthew_Atkinson> Manu: there's 18 months to add to Decentralised Identifiers. Verifiable Credentials is in maintainance for 2 years. Ideally ASAP.

<Matthew_Atkinson> Manu: the work is happening across several different communities and groups (W3C WGs, Credentials CG). Engaging with the CG may be preferable. There's also the Decentralized Identifiers foundation and other external organisations who're deploying this technology out in the market. Suggest APA directly communicates with the Credentials CG.

<Matthew_Atkinson> Manu: (also open to being contacted if any escalation is needed)

Thanks Manu.

<Matthew_Atkinson> Janina: we can take this to conferences too

<Matthew_Atkinson> JF: Two broad categories mentioned in Manu's email: Machine-to-machine and Machine-to-human. Which should be our priority?

<Matthew_Atkinson> Manu: This may be a question for APA. Machine-to-machine facilitates website personalization. Demonstrating access to services (e.g. transportation) may involve a person going to a site and transmitting something to show they are allowed to access that service, could be considered machine-to-human as a human could make that decision as to whether to send the vehicle.

<Matthew_Atkinson> Manu: it's all machine-to-machine but it may be surfaced to a human, who can see whether the person has the need.

<Matthew_Atkinson> Manu: both is fine, but the main thing is to prioritise the use cases (regardless of what they are)

<Matthew_Atkinson> JF: feels like focusing on machine-to-machine first is the best approach.

MA: This is facinating.

One of the preferences that we have been talking about is reducing motion on webpages.

Wonder if that ties in?

MP: In what way?

MA: Ranging from video images in a background that you can't pause etc..

preference example that may be transmitted..

<JF_> CSS reduced motion: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion

MP: Sounds like a preference.. Could be a credential etc, that removes unwanted movement etc

JS: This sounds like a swiss army knife..

<Matthew_Atkinson> Jason: RQTF is in a position to develop short- and longer-term use cases.

JW: The RQTF are in a position to help with these use cases.

<Matthew_Atkinson> :-)

<Matthew_Atkinson> Jason: the process of demonstrating to a govt agency entitlement to a service is quite different to the process of website personalization. We can look at other types of use cases too.

<Matthew_Atkinson> Manu: a paragraph on each use case could easily be enough.

<Matthew_Atkinson> JF: Can we think of this being like a manifest file?

<Matthew_Atkinson> Manu: think of it as having certain types of plastic cards in your wallet; they're just credentials. E.g. to be served at a bar you'd use a driving licence; to get a library book you'd show a membership card; to pay at a shop you'd use a credit card. They all allow access to different services. So it's like a manifest file, but it's more than that - it enables you to /prove/ things about you, e.g. a certain accessibility need (asserted by g[CUT]

<Matthew_Atkinson> ...or that you're over retirement age.

<Matthew_Atkinson> Manu: the person receiving the assertion can be absolutely sure that e.g. that assertion was made by a govt department.

<Matthew_Atkinson> Manu: it's up to you what you are willing to share. You don't have to share everything.

<Matthew_Atkinson> Manu: (and this can be done on a site-by-site basis)

<Matthew_Atkinson> JF: (ACKs; very helpful) [scribe agrees!]

<Matthew_Atkinson> Janina: thanks to Manu on behalf of APA; helps us understand how and with whom to communicate, too.

<Matthew_Atkinson> Janina: (thinking about implications for CAPTCHA...)

<Matthew_Atkinson> Janina: coudl it be used as proof of payment?

<Matthew_Atkinson> Manu: Yes, it could be used as a digital receipt (adoption will be a challenge, but it is possible).

<Matthew_Atkinson> Janina: thanks again to Manu; looking forward to working together.

<Matthew_Atkinson> Jason: this could be potentially used to make assertions about accessibility conformance.

<JF_> WOW +! to that!!!

Goals for the year -- Discussion

<JF_> sWOW +1/WOW +1

<Matthew_Atkinson> ^ Yeah, this is amazing stuff!

<JF_> s/sWOW +!/WOW +1/

<Matthew_Atkinson> Janina: Michael, Josh and I have been discussing several general goals for APA.

<Matthew_Atkinson> Janina: touched upon one of these with the previous discussion.

<Matthew_Atkinson> Janina: one of APAs mandates is to review specifications for accessibilty concenrs. We are working on a "FAST" (Framework for Accessible Specification of Technology) questionnaire to allow groups to evaluate their specifications and give us information that will help us assess where/how the accessibility concerns may lie.

<Matthew_Atkinson> Josh: it's a broad set of user needs/requirements that can be used by anyone developing a specification to check if their spec may impact on users and if it may meet those needs.

<Matthew_Atkinson> Josh: high-level series of abstractions and requirements.

<Matthew_Atkinson> Janina: We're working on this becuase it's becoming a W3C principle, horizontal review. We are getting some additional tooling to help us track issues and put keywords into specifications that help us track issues.

<Matthew_Atkinson> Janina: Horizontal review is of growing importance within W3C; we review accessibility; internationalisation, security, privacy etc. are other horizontal concerns and are working on developing the review process.

<Matthew_Atkinson> Janina: RQTF has been working on WebRTC use cases, now FPWD.

<Matthew_Atkinson> Janina: the next thing they are working on is a set of use cases for XR.

<Matthew_Atkinson> Janina: i.e. XAUR (XR Accessibilty User Requirements)

<Matthew_Atkinson> Janina: Pronounciation and Personalization specs upcoming very soon.

<Matthew_Atkinson> Janina: we now have a better understanding on how to work with the Verifable Credentials group.

<Matthew_Atkinson> Janina: anything we missed?

<Matthew_Atkinson> Janina: LĂ©onie Watson will be joining us next time; we will look at Pronounciation.

<Matthew_Atkinson> Janina: happy new year; good to be back

<Matthew_Atkinson> Thanks Becky; I will post those when done (will wait here until they are)

<Becka11y> :-)

<janina> Argh Webex just dropped me. But, I think you just need to publish that web link

<Matthew_Atkinson> Yep, thanks Janina, Becky, all :-)

<janina> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/01/08 18:04:11 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/WOW +!/WOW +1/
FAILED: s/sWOW +!/WOW +1/
Default Present: janina, jasonjgw, Matthew_Atkinson, Becka11y, Irfan, manu, JF, MichaelC, Joshue
Present: janina jasonjgw Matthew_Atkinson Becka11y Irfan manu JF MichaelC Joshue108
Found Scribe: Matthew_Atkinson
Inferring ScribeNick: Matthew_Atkinson
WARNING: No scribe lines found matching previous ScribeNick pattern: <Joshue108> ...
Found ScribeNick: Joshue108
ScribeNicks: Joshue108, Matthew_Atkinson
Found Date: 08 Jan 2020
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]