<scribe> scribe: Joshue108_
JW: We are talking about RTC Accessibility.
There was a join meeting at TPAC with the WebRTC group.
The Accessible RTC draft was discussed.
Who would like to start?
<jasonjgw> Josh: there was a meeting with WebRTC WG.
<jasonjgw> Josh: WebRTC Working Group participants found our use cases to be valuable.
<jasonjgw> Josh notes the availability of implementations of real-time text, some of which require polyfill implementations; it was suggested that the approach be captured in the relevant specification.
<jasonjgw> Josh: the WebRTC Working Group will determine the relevance of the use cases for their work.
<jasonjgw> Josh notes the request to review the IETF draft [on use of real-time text in the WebRTC data channel.]
<jasonjgw> Janina: we should identify what use cases may need to be resolved that may not be well served by the draft.
Here is that doc they would like us to review https://tools.ietf.org/html/draft-holmberg-mmusic-t140-usage-data-channel-02
JW: I think there is a code you can input if you are using your phone away.
JS: That is news to me!
So that was a suggestion.
So we don't have to localise all the time.
So the issue seems to be what sort of buffering or delay etc needs to be implemented.
JS: Discussed data streaming and RTT type coms..
This approach may help the poor pronunciation or braille display output.
JW: Yeah, like waiting for an end of line, and waiting indefinitely.
JS: That is the emergency concern.
They will get what ever is transmitted, but where is the time out.
SH: Great to hear it all went well.
JS: We had a great week, there is a lot to report.
JW: I've looked at the draft, included in the minutes.
<Zakim> Joshue108_, you wanted to ask about the review of https://tools.ietf.org/html/draft-holmberg-mmusic-t140-usage-data-channel-02
<jasonjgw> Josh: inquires about the details of the review process.
JB: Dom and I have something to go about explaining the ways RTT can be done and linking with the polyfill implementation.
That needs to get tied in with APA.
JS: And they said the reason WebRTC doesn't say so much about RTT is that the IETF spec covers this.
<jasonjgw> Josh inquires whether the message was that the IETF spec will cover the RTT use cases.
JW: I've had a look at this spec.
It is a detailed control level spec for how to transfer RTT over the WebRTC data channel.
It is some kind of reliable protocol, they are aiming to define the protocol and WebRTC will mint APIs to support it.
It does define the direction of text, if it is send only etc.
JS: Are you saying the IETF RFC refers to WebRTC in the data channel of the WebRTC spec?
JW: Its a divided deliverable.
JOC: It doesn't refer to the W3C WebRTC spec.
JS: WebRTC gave us the interesting reponse about the IETF doing protocols and we do web APIs.
Not suprised, but until IETF finish the protocol how are they write the API?
It confims our suspicion that the data channel is sufficient.
JW: Consistent with my understanding.
We were told ~ that VoiceOver works, we were urged to share our use cases with IETF.
<jasonjgw> Josh wishes to ensure that the different responsibilities are understood and taken into account.
JS: The WebRTC data channel may be sufficient but they need to be talked about and validated more.
The next steps are they we look at this document.
<scribe> ACTION: Josh and Jason to review IETF doc https://tools.ietf.org/html/draft-holmberg-mmusic-t140-usage-data-channel-02
<trackbot> Created ACTION-2213 - And jason to review ietf doc https://tools.ietf.org/html/draft-holmberg-mmusic-t140-usage-data-channel-02 [on Joshue O Connor - due 2019-10-02].
JS: We've got to look at community groups etc.
JW: Lets continue this next week.
Anything else on RTC?
JS: So unlike RTC that was a one hour meet, we spent ~ 3-4 hours talking about XR.
We had enlightening sessions, the intro to 3D on Friday morning by Nell from Amazon was very good.
Aims to develop a common vocabulary so we can work together.
It is well minuted.
https://www.w3.org/2019/09/20-apa-minutes.html#item01
JS: There was also the conversation from the day before. But we talked XR on the Thurs sesh, the APA sesh etc
JW: Thats helpful Janina, I've read some.
Good discussion on rendering, and related AOM discussion and scene graphs.
So valuable territory was addressed.
JW: So what are the central ideas that will help with use cases etc.
JS: The AOM converstaions were in the TAG hour, AOM and scene graphs etc.
My take away was that, we are not the only ones with concerns to have semantic data coming out of XR.
Immersive web and XR people want to get to doing declarative programming and semantics.
So I think this is a common goal and I'm heartened by that.
It takes the WebGL, WebGPU stuff off the table IMO.
glTF seems promising for WebGL.
That was confirmed by Nell, Ada and other folks but the main concern is the semantics we need, and matching that with their requirements.
SH: Do you think it is more of a technology or terminology issue?
Is this from a semantic POV or from just having the conversation.
JS: I took away that we were using similar terms but coming at them from diff angles - we need a common vocab.
Alice was quite involved - so is our model a tree or more like a scene graph?
This distinction is an open question - immersive web are more scene graph oreintated.
FOr interative or augmented envs, you dont have time for static DOM/tree, you need it all at once.
SH: So how do we get that work into our documents?
<jasonjgw> Josh: affirms Janina's summary.
<jasonjgw> Josh: we should be clear about the generic need for declarative semantics for accessibility and other purposes.
<jasonjgw> Josh suggests we need to understand how different components of the stack work, how semantic scene graphs work, and what is needed on the semantic side.
<jasonjgw> He thinks we may need to combine current accessibility tree-oriented approaches with semantic scene graphs.
<jasonjgw> In summary, Josh thinks the various aspects of this landscape need to be better defined an understood for purposes of a dialogue.
<Zakim> Judy, you wanted to discuss timing, and circulation of a backgrounder
<jasonjgw> Josh considers the notes to be of high quality.
https://www.w3.org/2019/09/20-apa-minutes.html#item01
<jasonjgw> Josh is currently capturing the ideas for purposes of understanding the material. These notes can be developed into a primer, once shared with the group.
<discussions on attending Inclusive XR workshop>
Some of us may make it.
JW: Part of the intent is to consider what are priorities will be post TPAC.
We've done that, and know what we need to do.
Are there other TF conversations that should be noted.
JB: I've started doing debriefs.
JS: Relevant to this, we had a good meet with Authentication people, decentralised identifiers.
We asked for CAPTCHA to die.
They may be able to kill it. They validated what we have reported.
No disagreement.
SH: Thats great.
JW: Yes indeed. The AGWG are also talking about authentication. etc
I've also sent a note to the chairs of AGWG offering help but not had a response.
We have things to offer, and I'm not sure if they've read our doc.
JW: Is there any authenitcation stuff to bring back to the TF?
JS: No.
<jasonjgw> Josh: notes discussion of the FAST which clarified the objectives of the document.
http://w3c.github.io/apa/fast/checklist
<Judy> [JB: Yes -- FAST is *really* hard to find -- let's fix that!]
We need a user needs discovery on FAST for anyone developing accessibility specs, then we need to iterate it.
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/anetc/etc/ Default Present: jasonjgw, janina, Joshue108_, scott_h, SteveNoble Present: jasonjgw janina Joshue108_ scott_h SteveNoble Found Scribe: Joshue108_ Inferring ScribeNick: Joshue108_ Found Date: 25 Sep 2019 People with action items: jason josh 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]