Real-time communication: accessibility-related use cases and requirements.

<scribe> scribe: janina

<jasonjgw> Janina notes an upcoming deadline for a transportation workshop.

<jasonjgw> Janina has started preparing a draft.

jgw: Notes Josh's latest draft

https://www.w3.org/WAI/APA/wiki/Accessible_RTC_Use_Cases

jb: Notes very timely items in Josh's drafts
... Were some comments already sent/ Which?

<jasonjgw> Judy notes a need quickly to identify and clarify any comments already submitted to the WebRTC Working Group.

jb: RTT is noted for next WebRTC
... Notes possibly polyfil implementations already, possibly two

<jasonjgw> Judy plans to clarify whehter real-time text is required in this version of WebRTC and the status of implmentations. It is desirable to look at RTT before extending to broader use cases.

<Zakim> Joshue, you wanted to ask if those comments to WebRTC were submitted before I started

jo: Nothing formally submitted from APA
... Notes RFC5194 defines RTT well
... Believe we want to see them implemented as appropriate
... Unclear on timing and current vs. next version prioritization

jb: Just what I'm trying to negotiate now

jo: Believe RTT is critical to 911 emergency support

<jasonjgw> Judy notes the need for high-quality RTT implementation in support of emergency services, and the need for coordination on schedule and WebRTC requirement development.

jo: Noting already a good set of well evolved use cases

jb: Yes, but not determinative of whether required for this version or can be the next

jgw: Wondering about interoperability and how much is dependent on implementation

jb: Believe current client implementations are polyfill

jgw: Any implementation guidance likely to take considerable time

jb: Don't think it's related to AGWG timelines

jgw: Thinking of app implementation once protocols are in place. Do we need to say anything?

<jasonjgw> Janina inquires as to the time-line of the next version of WebRTC - not just the one currently under development.

jb: Standard answer on timelines: Best not to wait for multiple reasons

<jasonjgw> Judy cautions against the risks of postponing requirements to future versions.

<jasonjgw> Janina notes the desire to preserve unique functionality of being able to buffer the entered characters until the message is complete (for nonvisual access use cases).

jgw: Thinks multiple ways to implement without protocol support, i.e. timeout and/or eol chars

<Zakim> Joshue, you wanted to say we need to make sure we capture that in doc

js: Accepts the action to wrtie this up for Josh

<scribe> ACTION: Janina to explain blind persons requirements that differ from standard rtt behavior

<trackbot> Created ACTION-2201 - Explain blind persons requirements that differ from standard rtt behavior [on Janina Sajka - due 2019-07-10].

jo: Please observe current format, please

<jasonjgw> Josh: notes that many of the use cases have implications beyond the WebRTC specification itself. Josh clarified this in the introduction, ensuring that the use cases are clearly seen as relevant by all pertinent groups (e.g., Web audio).

<jasonjgw> Janina agrees these changes are desirable.

<jasonjgw> Josh will have more to contriute on WEb of Things next week.

<jasonjgw> Josh collected use cases for RTT (derived from requirements documented elsewhere). Some of the use cases could be candidates for merging, but this raises the concern that nuances may be lost in that process.

<jasonjgw> Josh has noted use cases that may be merging candidates in the titles as given in the current draft.

<jasonjgw> Josh resumes from where we ended at the last meeting - the need for user control of volume and panning position of multiple audio streams.

<jasonjgw> Different sound sources could be used for different audio streams.

<jasonjgw> Judy raises the question of whehter any of these use cases introduce architectural issues - especialy as extended to meet future needs derived from the use cases.

<Joshue108> https://www.w3.org/WAI/APA/wiki/Accessible_RTC_Use_Cases

<jasonjgw> Janina: clarifies that it is important to specify which audio device is being used for real-time communication, and it might not be the default audio device of the operating system.

<jasonjgw> Josh concurs.

<jasonjgw> Janina: it's often necessary continually to adjust volume (e.g., changing it to accommodate different speakers in a teleconference).

<jasonjgw> Josh notes that meeting these requirements should be achievable, but the support in web technologies is the question.

<jasonjgw> Janina will review the use cases in this area as currently documented in Josh's draft.

<jasonjgw> Josh suggests text communication data channel could be a good location for additional material addressing buffering of real-time text as entire messages.

<jasonjgw> Janina agrees it might belong there.

<jasonjgw> Josh: Live transcription and captioning.

<jasonjgw> Janina suggests referring to RFC5194 where apporpirate.

<jasonjgw> Josh agrees.

jgw: Agrees on referring to 5194 as appropriate

<jasonjgw> Janina notes that it's also a question of bringing signing into the channel.

<jasonjgw> Second screen video implementation may raise implementatoin issues, but it isn't different from another user joining a teleconference.

jgw: Supports referring as appropriate, inferring use cases as necessary
... balance of reference and explanation

<jasonjgw> Josh will identify and appropriately document use cases that are addressed in other documents/specifications.

<jasonjgw> Josh notes new use cases (e.g., interference minimization).

<jasonjgw> Josh: switching between different media (text, voice, video) amid a conversation should be clearly brought out in the draft.

<jasonjgw> Josh will work on the draft, taken account of this discussion.

<jasonjgw> Janina: no substantive comments on CAPTCHA that haven't been addressed in editor's draft.

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/currently polyfill/current client implementations are polyfill/
Default Present: jasonjgw, Joshue, scott_h, janina, SteveNoble, Judy
Present: jasonjgw Joshue scott_h janina SteveNoble Judy Joshue108
Found Scribe: janina
Inferring ScribeNick: janina
Found Date: 03 Jul 2019
People with action items: janina

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