APA & ARIA Joint TPAC Meeting Minutes: Session 2

Minutes from Session 2 of the joint APA & ARIA TPAC meeting are provided below
as text.

Hypertext is available at:

https://www.w3.org/2021/10/27-apa-minutes.html

With thanks to Michael and James for scribing, and to all for two great
sessions today!


   W3C

                                                                                                            – DRAFT –
                                                                                                         (MEETING TITLE)

27 October 2021

Attendees

   Present
          aaronlev, jamesn, janina, jasonjgw, jcraig, MichaelC, PaulG

   Regrets
          -

   Chair
          -

   Scribe
          jcraig, MichaelC

Contents

Meeting minutes

   <janina> All, please join #aria so we can avoid minutes conflicts from our earlier session!

   <janina> Meanwhile, if anyone has Zoom Meetind ID and password, I would appreciate the data!

   <jcraig> To reply to Janina's comment earlier, we're still minuting here in #apa because it's a new meeting ID due to being past midnight GMT

   <janina> Wow, what a messy password to copy over a KVM by hand!

   <jcraig> Earlier discussion was minuted at https://www.w3.org/2021/10/26-apa-minutes.html

   <janina> Yes, so am suggesting we move to #aria

   <janina> Overview of possible topics: https://lists.w3.org/Archives/Public/public-apa/2021Oct/0031.html

   jgw: exploration of new technologies and how they impact a11y

   need to explore if the current a11y infrastructure meets the requirements

   data visualization example

   from all the directions these kinds of issues are coming up, what overlaps do we have?

   need input from AT developers on how things fit

   <janina> https://www.w3.org/WAI/about/projects/wai-coop/symposium1/

   js: ^ WAI symposium 10 Nov, open for papers

   have been asked for accessibility requirements for self-driving vehicles

   expect will need users to be able to use their own familiar device

   in epub meeting, concern that weÂŽre trying to add lots of new attributes

   getting messy

   <Zakim> jcraig, you wanted to discuss dataviz and custom view accessibility

   <jcraig> WWDC 2021 video covering iOS Chart "audio graphs" and other dataviz: https://developer.apple.com/videos/play/wwdc2021/10122/

   <jcraig> https://developer.apple.com/documentation/accessibility/audio_graphs

   <jcraig> Article with code samples: https://developer.apple.com/documentation/accessibility/audio_graphs/representing_chart_data_as_an_audio_graph

   jc: weÂŽve gone back and forth on AOM

   a recurring issue is that AAPI requests can infer presence of AT

   TAG has introduced a design principle - paraphrase donÂŽt allow detection of AT

   <jamesn> https://w3ctag.github.io/design-principles/#do-not-expose-use-of-assistive-tech

   <jcraig> Several core architectural features of the Web Platform may allow heuristic detectability of assistive technology https://github.com/w3ctag/design-principles/issues/293

   I understand the need, but think itÂŽs inescapable

   discussion should be wider than context of existing design goals

   may need to evolve them

   <Zakim> aaronlev, you wanted to say that games are use case

   al: use cases - games, interactive diagrams, maps (viewed broadly), ...

   @@ accessible interface with good GUI

   separation of tabs into own process means AT requests go through a slower pipeline

   AAPIs are synchronous, it awaits answer from browser

   canÂŽt wait for callback, so have to have a lot pre-cached

   recently, we tried to use aria-annotation to avoid live regions, but had to get it implemented across the board

   took 2 - 3 years, and that wasnÂŽt even adding properties, just clarifying use cases

   so itÂŽs herculean to do anything to AT

   as things stand, I think we have a tech that pretty much works

   but if something new comes along, there would be a massive implementation effort

   if a new tech comes along, support for asynchronicity is critical

   also serializable output

   jn: +1 to al

   we can solve problems in isolation

   but each one is a big lift

   need to find a more scalable method of addressing new use cases

   <jcraig> +1 for exploring an asynchronous API related to Web Accessibility... but FYI that could break the Web Platform Design Principle "Don't expose AT"

   js: if asynchronous AAPI is feasible, is a meta (OS independent) AAPI feasible?

   it may be a fact of life that AT use is exposed

   <becky> ack cyns

   with informed consent, the trade-off in feature delivery may be worth it

   cs: fugu working on filling gaps in capabilities one at a time

   e.g., virtual modes, bounding rectangles

   they donÂŽt have to be in same spec

   I like the one feature at a time approach, gets things in front of users faster

   re meta AAPI, Chrome kinda has that, in code

   there are gaps in the toolchain, which impedes making something accessible

   so we can work with the owners of those for each isseu

   re privacy, +1 to informed consent

   to avoid differential fingerprinting, make features useful to mainstream users as well

   <jcraig> An article covering some of the controversy surrounding Fugu https://css-tricks.com/platform-news-defaulting-to-logical-css-fugu-apis-custom-media-queries-and-wordpress-vs-italics/

   <cyns> https://www.chromium.org/teams/web-capabilities-fugu

   jt: agree with unmet use cases

   <cyns> +1

   scrapping AAPIs could leave a lot more users out in the interim

   should build on top, rather than be a redesign

   a redesign would be nice, but not practical

   <cyns> +1 to additive API features

   <jcraig> I don't think I heard anyone suggesting to scrap support for existing Accessibility APIs

   when we look at a problem, we should first ask if the problem can be addressed with existing AAPI

   many of the emerging technology issues will need to be solved in domain-specific ways

   so our role is a core framework for expressing generic asynchronous domain-specific concepts <scribe: whew!>

   a one-size-fits-all would not work

   clarification: meta api would be a vehicle for communicating more domain-specific stuff

   js: interlinear translations

   jt: not necessarily AAPI there - case in point to above

   re privacy, shouldnÂŽt give it up just because there are techniques to extract info

   <jamesn> +1 to JT on detectability

   if we take to an extreme, a person needing access would have to give consent to access *anything*

   just be careful of that path

   one thing IÂŽve seen is we start a spec, discover it doesnÂŽt meet use cases, start reengineering

   e.g., shadow dom proposal was originally intended to allow AT pointer across shadow DOM boundaries, but we discovered that wouldn't work due to encapsulation which then led to a decision fork

   <Zakim> cyns, you wanted to say ideally one feature = one use case

   cs: ideally one use case should result in one feature

   think there are solutions to problems like element reflection, need to document them so you can critique ;)

   jgw: some common issues - memory and synchronicity

   data visualization could have similar issues to xr

   another issue is on extensibility

   do we need principles, methods, social and technical approaches

   <Zakim> jcraig, you wanted to mention Alice Boxhall's proposal for a TCC dialog that all users (not just AT users) would be forced to acknowledge

   jc: agree, need to be careful of slippery slope of sacrificing privacy

   in location services api, the request for location came up right away, with usually automatic no

   so it was changed to require informed consent from user

   seems to result in less use of unnecessary location requests

   in discussion of TCC dialog, came up with requirement that itÂŽs for all users

   privacy-invading features get weeded out that way

   above, reference article on controversy re fugu

   cs: virtual modes, could we just have always on?

   if performance hit acceptable

   <Zakim> jamesn, you wanted to say the events would never get fired on the virtual nodes

   jn: @@

   jc: ~only AT would cause events to fire on virtual nodes2

   pg: in data viz, guidance is generally to provide summary

   meaning people producing the graph are also interpreting it

   that can take away the userÂŽs lens on it

   <jcraig> s/@@2/and specifically triggered actionable, such as "clicking" a virtual node. most use cases for that would be AT/

   so features that allow users to pull out data, rather than have it provided, would meet this

   (note Pronunciation is an exception)

   <jcraig> s/actionable/actions/

   I do think there are some inevitable privacy compromises

   js: šinformedš is the key part of consent

   need to define that

   +1 to allow people to apply their own expertise to data

   jt: data vis / interpreting from authors is an important issue, and an example of a domain-specific need

   even if there were to be summarization, the industry could discuss how much, how far, etc.

   in pronunciation, there isnÂŽt 2-way communication, so that doesnÂŽt expose at use

   differs between passively receiving, vs actively querying

   <Zakim> cyns, you wanted to say that it's the piece-by-piece process of Fugu that I like, not necessarily any particular feature going through that process

   cs: clarify on fugu I like the 1-step-at-a-time process, neutral on features

   jc: how does it differ from our incubation processes?

   cs: IÂŽm thinking of smaller chunks

   one function

   jc: So you're suggesting we start with smaller features like pronunciation? vs the whole spec of Speech in HTML

   cs: sure; element reflection another that came up

   we should do exploration of issues like active vs passive data retrieval, we may not know where things stand on some of those things

   <becky> ack PaulG

   pg: in earlier session, suggestion came up of referenceable @@

   that is a threat, if itÂŽs opt-in for the browser

   ability for user to dig more deeply into data worth exploring

   <Zakim> jcraig, you wanted to demo interactive chart features

   jc: <demos active and passive cases>

   in a chart example, theirÂŽs (passive) retrieval of the chart data so AT can render

   there can also be active retrieval when user interacts

   js: <mulls improvements to the a11y features that could be more mainstream>

   <janina> https://groups.csail.mit.edu/infolab/publications/Barbu-Deep-video-to-video-transformations.pdf

   js: WCAG success criteria for hazards... MIT proof of concepts

   shown to Judy Brewer

   The basic principle is buffering (presumably to detect photosenstivity seizure risk in real time)

   <Zakim> cyns, you wanted to say that pronunciation is an example of something that could be broadly useful for "look up defintion" and language learners

   cyns: pronunciation is a scenario that doesn't have to leak AT info

   cyns: similar to "Look Up" dictionary features on systems

   potentially could be used for "speak this page" or other "voice assistant" contexts

   jamesn: using the Chart API as an example, designing an API that covered all hundreds of types of charts would be a huge undertaking.

   <Zakim> cyns, you wanted to say that we should create a threat model, add these things to it, and figure out which ones can be mitigated

   jamesn: @@

   cyns: would like to propose an accessibility threat model... which can be mitigated. which are really dangerous, etc.

   <Jamie> https://github.com/w3ctag/design-principles/issues/293

   Several core architectural features of the Web Platform may allow heuristic detectability of assistive technology https://github.com/w3ctag/design-principles/issues/293

   I think cataloging and mitigation is the intent expressed that issue

   cyns: and several risk factors not listed in that issue

   js: could be a research topic for developing a threat model and potential solutions

   <cyns> https://en.wikipedia.org/wiki/Threat_model

   jasonjgw: been reading about this... it's not just taken advantage of specific information... it's the additional points of reduced entropy associated with an ML model can infer disability or Assistive Technology.

   Could discover interesting or discriminatory patterns on it's own.

   <Zakim> cyns, you wanted to say we have our first threat!

   cyns: that's exactly the reason for needing a threat model

   jasonjgw: we don't have live known examples of that ML discrimination, but it's a known possibility

   cyns: a threat model should list every known threat

   jcraig: the PoR from Privacy WG in https://github.com/w3ctag/design-principles/issues/293 is to list all knowns threat (before a solution) as a way to force a solution

   janina: @@ Ottawa example about wheelchair bias. scribe help please

   @@janina2

   <cyns> possibly this https://nyupress.org/9781479837243/algorithms-of-oppression/?

   <janina> Jutta had examples where attempts to repair AI to avoid wheelchairs ended up targeting them more precisely.

   jasonjgw: privacy keeps emerging in these contexts. it seems for the users that's it's good if the requesting/giving consent occurs where there is significant rationale: significant performance, very private
   disclosure

   user could make that informed decision if they trusted the entity requesting permission

   so I agree with the rationale to extend API as needed for new features, performance, etc

   seems like we're making some progress, how to we do this most efficiently?

   janina: automotive topic... there is a working group

   <cyns> This NIST privacy framework for threat modeling might be useful https://www.nist.gov/privacy-framework/privacy-framework

   <jamesn> "The mission of the Automotive Working Group is to develop specifications for exposing information services for in-vehicle and cloud based uses."

   various mention of web apis (json or xmlrpc perhaps?) related to automotive

   janina: APA met with the Automotive group in Lyon (8-10 years ago?)

   jasonjgw: still haven't optimized the process question in a way that will attract the attention of the top experts in an efficient way

   janina: where's the low hanging fruit

   <Zakim> cyns, you wanted to say have we engaged with the privacy community group? https://www.w3.org/community/privacycg/

   Tess was/is a member of the Privacy CG and was on the earlier version of this call.

   janina: Privacy is one of the horizontal review groups that all need to go through

   cyns: want to "shift left" on privacy

   wrt to risk management

   janina: APA can have a conversation with Privacy on this topic

   cyns: wrt threat modeling

   janina: one of personalization co-facilitators has a bg in privacy

   janina: thanks to all. I will wrap the minutes.


    Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).

   Maybe present: al, clarification, cs, cyns, jc, jgw, jn, js, jt, pg
-- 

Janina Sajka
https://linkedin.com/in/jsajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Co-Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

Received on Wednesday, 27 October 2021 01:54:09 UTC