<jasonjgw> trackbot, start meeting

<trackbot> Meeting: Accessible Platform Architectures Working Group Teleconference

<trackbot> Date: 12 February 2020

<scribe> scribenick: Joshue108

Preparation of documents (especially RTC) for review and publication.

JW: This is the usual topic on draft prep.

My understanding is that the XAUR is proceeding thru the publication process at the moment.

Thanks to the team

JW: Also the RTC doc is getting closer to review by APA.

Am I correct in that?

Also what issues can we discuss regarding RTC doc to forward it.

<gives update to Steve>

JS: XAUR transition request went out on Monday.

JB: Unless you have conf from Michael, I would be suprised if it moves, Michael on holidays.

He has things in his q.

But don't expect it - Janina or Jason have you been in touch with him?

JS: Yes on Monday.

JB: I was talking with him, he has a lot on his plate.

JW: Thats fine.

JS: Michael is back by the 25th.

JW: If we said the end of the month, thats approximate.

JS: We may want to push that out a little.
... A question for Josh - update a la review.

<jasonjgw> Josh: hoped to address editorial issues in the RTC document today, but encountered technical Git issues, which are now fixed. He has changes to make to RTC. In addition, there are a few other writing projects underway.

SH: Today I gave presentation at the OZWai gig - the XAUR was really well recieved.

I picked out 5 of the scenarios and there was quite a bit of excitement about this.

The existing user needs mapping got people buzzing!

excellent news Scott!

SH: There were about 60 there.

JB: Thanks!

<discuss the OZWai conf>

JW: I'm happy that some said they will comment on the doc.

JS: Janina, how will next week look for bringing RTC doc to APA. Don't think we will publish before March.

It may be post CSUN at this stage.

JW: That gives us time for editorial, for expectations of review to start next week.
... If that doesnt work we can shift again - but lets try for next week.
... Offers help to Josh on RTC doc..
... Anything else to be said?

Verifiable Credentials - accessibility-related use cases.

JW: The update to this.. use cases we are developing, high quality suggestions.

I commented on this via the list - after making changes that took recent discussions into account.

So what are the additional use cases and prioritisation.

here is the URI https://lists.w3.org/Archives/Public/public-rqtf/2020Feb/0003.html

JS: Can we just walk thru them and review on the call?

We are only after three or 4.

https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Some_use_cases_for_verifiable_credentials

Lets start at the top

Privacy-preserving Identification of Users to Web-Based Applications and Services

JS: This is second tier - not a killer use case
... It's about protecting users privacy but not unique to people with disabilities.

JOC: If there is a connection between this and browser finger printing (and I don't know if there is) then this is important.

JS: But again, not a killer use case - they are trying to find use cases that highlight this tech.

JW: Compares use case with GPII preference management - they do profile management.

This is potentiall use case.

JS: That may have better legs, but there are a lot of ifs..

SH: Conceptually this is easier to get your head around.

JOC: How do you mean?

SH: You can picture these scenarios of this being applied.

JS: This is maybe a 3 or 4..

<Zakim> Joshue, you wanted to ask Jason what GPII do to handle these profiles

JW: I'll explain - the issue Janina referred to in previous discussion is UI preferences may be depended on environment and device.

So is there a persistent set of needs and prefs for a11y purposes that can be stored on a block chain and persist.

GPII handle this by seperating the needs and prefs from the settings that are applied.

There is a mapping infrastructure that abstacts between the two.

GPII - they call it match making for infering software specific setting and the profile.

<scribe> <continues overview of GPII process>

SH: The GPII promo video is good to teach the concept.

JOC: Was wondering about the architecture. Helpful.

JS: We should come back to the ones that seem most interesting.

NOTE: This discussion above relates to Private and Secure Access to Individual Needs and Preferences.

JW: Of the three we have mentioned this bubbles to the top as it is simple, easily described up to them to see if it is appropriate to them.

This is compelling -

Privacy-preserving Identification of Users to Web-Based Applications and Services..

JS: We like this one International Transfer of Service Dogs and Comfort Animals
... The chip can be read and that part must be diployed.

SH: I think this is the best one.

Verification of Disability Status to establish Eligibility for Opportunities or Benefits

JW: This can be government related for access to benefits etc.

There is the question around making this easy and may encourage overuse - solid example

SH: Yes, this would be number 2 in my thinking.
... There is frustration in this area.

Could help streamline.

JS: +1 to Scott - this can also be dated.

So if you are in an accident and need temporary transit services etc but there is a timestamp on them as the condition clears.

JOC: So you access the service as you need it.

SH: There are situations where this happens, the paper work etc takes so long, could remove hardship.

JB: Would this be a binary situation - that it is clear someone has a disability? Doesn't work like that.

JS: There may still be beaurocracy

JB: This isn't binary.

JS: We have stuctured this in those ways - not really dealing with nuance in this chain.

JB: It would be good to capture that.

JW: We don't want the different departments to apply diff standards to claims.

JB: That is difficult - but a common real life situation.

JS: So where is the advantage of this tech over a plastic card in your wallet.
... But we are killing the killer case here.

JW: Don't know about that..

<jasonjgw> Josh notes the difficulties associated with proving what needs to be established for eligibility to government welfare benefits. There are nuances that need to be captured.

JB: Thanks Josh, I'll make a further case for why the nuances are important.

E.G Categorisation, is often done in a binary way, for People with disabilities..

And can be complex - trying to get systems to work, and establish eligability.

The sytem may determine someone is ineligable - you may rely on other services to establish eligibility.

System variability in a approved status may be critical to establish eligibility

We need to careful about accross the board certification of status.

Hope that is useful

JW: Yes, it is. In a Verf claims arrangement may help smooth out inconsistencies.

How?

JS: I don't see how the mechanism supports that.
... How does the system know your status?

JB: It's not always clear or clean cut.

JS: We know how to handle that - a la the plastic card people get 6 month extensions that cover them while the system works that out.

Don't see a fluid system implementation.

JB: Here is a use case - for a user with an addiction, they may be eligable for a program if they are clean.

Then they access services that show they are using - so their status changes.

If they stay clean - then they are clear and their status changes.

So I see many situations where a users status changes quickly? Helpful.

JS: Yes @@

JB: Eligability status may change and go accross different domains.

SN: So we are assuming a central registry?

JS: There will be some beaurocracy. It's not a purely mechanical thing.

JW: We should develop some of the nuances here.

<Zakim> Joshue, you wanted to say what about a use who needs to change country or state and access services

JS: So there are regional issues.

SH: Good use case!

JW: I've experienced this.
... This is interesting and there should be thinking of the format.

JS: This is number 2.

JOC: This brings up issues around International Classificatio of Function etc

JW: That is controvertial

JB: Given the human tendency to classify people in a binary way - this ramps up a la automation.
... The problem is having an indeterminate status - the answer my be don't know, and not a binary option.

This may be handled by different systems - and we need to leave room for this.

JW: They use JSON, complex definitions can be defined - its not limited.

Can be more detailed.

Asserting Conformance to Accessibility Standards

JW: This is claims for hardware and software.
... I can take an action to revise the wiki page.

Will do after the meeting.

Lets shift this last item to next week

JS: Yes - we dont have time today.
... I think this number 3.

I don't think legal people would like this.

JW: Are you thinking of this for VPATs?

JS: Who would make these assertions?
... Consultants.
... ISO has a framework for assertions..

SN: Individual reviewers?

<discuss use case>

SH: I'd put this at 4
... I've the GPII example at 3 and have this at 4.

We are in agreement.

<janina> ~

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)

Default Present: jasonjgw, Joshue, scott_h, janina, SteveNoble
Present: jasonjgw Joshue scott_h janina SteveNoble Joshue108
Found ScribeNick: Joshue108
Inferring Scribes: Joshue108
Found Date: 12 Feb 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.)