Janina: there are Community Group
conversations toward the end of the agenda.
... no one suggested changes/reordering.
Janina: expects a meeting next
week with a substantive agenda, and again on the 11th.
... TPAC follows (meeting Thursday/Friday face to face).
Janina notes the time shift (to Japan time at TPAC).
Janina notes that the APA meeting is typically cancelled for the week after TAC - proposes we don't meet the week after TPAC but resume in October.
Janina: notes the provisional agenda at the above URI.
Janina also notes the discussion of Decentralized Identifiers at TPAC and its relation to the CAPTCHA work. There is a good opportunity to raise any further use cases with authentication/blockchain specialists.
This meeting is in the hour before lunch on Friday.
Apart from this change, Janina notes that the draft agenda stand.
AOM is request clarification of specific agenda.
Janina inquires about the necessity of a CSS AAM and whether AOM would be involved.
Joanie: Low Vision Task Force and COGA requirements generally don't affect the way in which content is exposed to platform accessibility APIs. However, screen magnifiers benefit from focus tracking; there are scenarios in which different content should be disclosed to different modalities.
<Joshue108> +1 to Joanie
Janina: discusses the possibility of giving AT control of spacing and other CSS properties. This would need to occur via another mechanism (not accessibility APIs at the platform level).
Joanie: if content-level changes are made pursuant to AT, then the changed content should then be exposed to an accessibility API. However, this doesn't change what a user with low vision would experience and how this is controlled.
Janina inquires wehther there's nevertheless a role for AOM.
Joanie/Josh: probably not.
Josh: the visual rendering is separate/distinct from the accessibility API.
Joanie: AOM would allow
manipulation of values via accessibility APIs.
... AOM - allows properties to be set, but not what we wish to
be setitng here (i.e., CSS/style properties in visual
rendering).
Janina: wishes to engage a conversation that would make good on the "cascade" promise of CSS from 20 years ago.
<Zakim> Joshue, you wanted to say AOM and XR
Josh: AOM is primarily designed to fill a gap in Web components, where the components don't have inherent accessibility roles/properties.
Josh suggests that having time to discuss AOM would be valuable nevertheless, e.g., in the XR context.
Janina will be specific about this.
Josh will assist in clarifying the specifics..
Matthew likewise.
<Joshue108> JW: To comment on the AOM, Josh echoed what I wanted to say.
<Joshue108> When I heard a preso, they had a phased implementation plan, they wanted to query roles states and props in JS
<Joshue108> Then they want to define various accessible nodes, and what they were associated with.
<Joshue108> So you could add on an accessibilty tree to a component.
<Joshue108> Also some foo with events, and they hope to move the Web Platform forward, phased implementation plan etc.
<Joshue108> Regarding manipulation of style props..
<Joshue108> There is stuff that can be done in the cascade, AT may be able to implement these details.
<Joshue108> Looks like arcitectural details.
<Joshue108> JS: I was speculating, cascading style sheets may be a good idea.
Matthew: concurs with Josh and Jason. AOM is designed for a unidrectional flow of information to the accessibility tree. It should solve problems with Web Components and with games.
Browsers seem to have minimized the role of user style sheets. Matthew inquires whether there is/needs to be a mechanism that goes from AT to manipulating the content/styling.
Janina: suggests we give the question furhter consideration.
Janina: proposes we don't wish to
object to the WebXR Device API spec, but we wish to engage them
in a discussion of how our concerns can be met over time -
acknowledging that this is in a 1.0.
... asks how semantics should be into-roduced into rendered XR
content, and we need a path to doing so, before "facts on the
ground" become irrevocably established in XR implmeentations
which might make this more difficult in the longer term.
<Joshue108> ack ack me
Josh: echos Janina's concern that we need to be careful to avoid an overly convoluted architectural solution here.
Josh notes interesting opportunities (performance, scalability, access to user agent APIs) in Web Assembly. Likewise, GLTF can represent scene graphs.
<Joshue108> JW: I reviewed this..
<Joshue108> JW: Happy to exchange ideas..
<Joshue108> We need to think carefully how semantically rich representations of XR will be provided.
<Joshue108> Esp when playing with AT - and it will need to play nice with accessibility APIs.
<Joshue108> AOM, could be useful here but may involve constructing a tree with a DOM node, a la <canvas> and associating with tree in A11y API.
<Joshue108> No formal mapping to co-ords of rendered graphics etc but may be possible.
<Joshue108> JS: Co-ords in aural landscape.
<Joshue108> JW: You could here about co-ords in 3D, worth discussing with bods in AOM.
Josh: asks whether we're expected to endorse WebGL as a rendering environment for XR.
Janina: notes we need to review/comment on WebXR Device API spec.
<Joshue108> Device Input https://github.com/immersive-web/webxr/blob/master/input-explainer.md
Josh doesn't object, but thinks it may be under-specified.
<Joshue108> Its very good
<Joshue108> Spatial tracker https://github.com/immersive-web/webxr/blob/master/spatial-tracking-explainer.md
Janina: the response may be - no objection to the spec in its current scope, but we need then to develop our requirements henceforward.
Josh: notes the use of spatial tracking in immersive web. He notes the potential for rich mapping to capabilities of assistive technologies.
Janina will take this idea further.
<Joshue108> JW: It seems that one of the central questions is that are the kind of API mechanisms representing going to evolve to render 3D type content successfully?
<Joshue108> If so we have a solution.
<Joshue108> We need to be careful that it can map these kind of things successfully.
<Joshue108> PDf for example has reverse mapping.
<Joshue108> +1 to the kind of two way rendering.
<Joshue108> We may not have reason to say that WebGL is inherently problematic but we may have a feature request to evolve their tech.
<Joshue108> So there is a question around architectural needs.
Janina: suggests we don't object to the 1.0 spec, but we wish to develop a plan for meeting the needs here discussed.
Josh: we need to clarify with AOM to what extent they've considered the needs arising from XR use cases.
Josh notes that changes resulting from users' actions need to be propagated to all of the renderings available to the user. He draws an analogy with the React framework.
Janina is seeking APA review of presentation slides for the workshop.
<janina> https://www.w3.org/auto/events/data-ws-2019/cfp
Janina will circulate the slides and requesting feedback from APA.
Janina: notes proposal mentioned by Leonie for an upcoming immersive Web/XR workshop in Seattle this November.
<janina> http://lists.w3.org/Archives/Public/public-apa/2019Aug/0067.html
Janina: notes a query about language codes from Lisa.
Janina will follow up.
<janina> sz w3c
<janina> https://www.w3.org/2019/08/proposed-css-2019.html
Janina: notes proposed CSS Charter, and the importance of this if we approach a CSS AAM.
Action expected to be completed next week.
<trackbot> Error finding 'expected'. You can review and register nicknames at <https://www.w3.org/WAI/APA/track/users>.
<scribe> Postponed by a week.
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/secifics/specifics./ Default Present: Matthew_Atkinson, Joshue, Becka11y, Joanmarie_Diggs, janina, Irfan Present: Matthew_Atkinson Joshue Becka11y Joanmarie_Diggs janina Irfan Joshue108 No ScribeNick specified. Guessing ScribeNick: jasonjgw Inferring Scribes: jasonjgw Found Date: 28 Aug 2019 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]