– DRAFT –
(MEETING TITLE)

<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.