W3C

- DRAFT -

Accessible Platform Architectures Working Group Teleconference

11 Sep 2019

Attendees

Present
jasonjgw, Joshue108_, SteveNoble
Regrets
Chair
jasonjgw
Scribe
Joshue108, SteveNoble

Contents


<janina> I'm on my way, but I need to reboot my phone ...

Real-time communication accessibility: interdependencies and opportunities for coordination.

<Joshue108_> scribe: Joshue108

<Joshue108_> JW: I understand that we are concentrating on the interdependencies between groups etc that arise between use cases and user requirements etc

<Joshue108_> I've written a summary and posted that to list.

<Joshue108_> For each one there are dependencies between one or more working groups or community groups etc

<Joshue108_> I'm not totally sure which ones are addressed and/or are a matter of implementation.

<Joshue108_> The AGWG are clearly a dependency for all that needs to be implemented in RTC type communications.

<Joshue108_> There may be other requirements that Silver will need to look at.

<Joshue108_> https://lists.w3.org/Archives/Public/public-rqtf/2019Sep/0026.html

<Joshue108_> Real-time communication accessibility - working group interdependencies mail from Jason

<Joshue108_> JOC:Can we walk thru them

<Joshue108_> JW: Sounds good.

<Joshue108_> scribe: SteveNoble

Josh: Incoming calls - added this with callerID merged these
... User need - where the user needs to know identity of incoming calls

Janina: suggests the ability of routing this through a differt device

For instance one streat through a buetooth headset and another stream through another device

Call notification could be routed to a briller without interupting the audio stream

Is there an API in RTC for notifications?

Not sure, but we could ask about this.

But we could ask for standard notification techniques to be used

Strandards may differ per browser and platform

Janina: Could be a role for ARIA, but we don't know yet

Could be a use case for ARIA live regions for notifications when these appear in the same HTML document

<Joshue108_> I've captured Janinas suggestions a la ARIA.

<Joshue108_> Accessible Call Set up

Josh: safe to take this out
... Audio rooting of multi channel
... second screen issues

<Joshue108_> Josh to discuss Audio Routing use case with Second Screen at TPAC.

Use case to manipultae volume levels of independent audio streams with audio description

<Joshue108_> Josh to mention Dynamic Audio description values Media Working Group, Web and Networks IG, Second Screen at TPAC

Jason: the content of the audio stream can be filtered to go to the desired output

Audio-subtitling/spoken subtitles

User need example, Spanish subtitles need to be spoken during a movie

Janina: this is a rare use case - where would this happen?
... probably not a WebRTC use case

More of a media-retated thing

Josh: will take that one out

Communications Control of Alternate Content

Josh: had a merge flag on this one - perhaps with data channel?

Jason: live captions in a teleconference session

Janina: this is a growing use case

Josh: will merge this is another example of the text communication
... change to communication chanel control

Janina: mentioned focus tracking bug issue in Android, but should remove that as it is ephemeral

Judy: pleased with the process of this document - looking good

<Zakim> Joshue108_, you wanted to suggest looking at the Merge items

Jason: we will postpone the second agenda item

merge “Audio routing and multi-channel” and "communication channel control"

<Joshue108_> Am making that edit now..

<Joshue108_> Audio Routing and Communication channel control

<Joshue108_> https://www.w3.org/WAI/APA/wiki/Accessible_RTC_Use_Cases#Audio_Routing_and_Communication_channel_control

Janina: components need to be individually controlled

“Control relative volume and panning position for multiple audio" could be merged with "“Audio routing and multi-channel” as long as we include the different use cases

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/09/11 14:04:31 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Default Present: jasonjgw, Joshue108_, SteveNoble
Present: jasonjgw Joshue108_ SteveNoble
Found Scribe: Joshue108
Found Scribe: SteveNoble
Inferring ScribeNick: SteveNoble
Scribes: Joshue108, SteveNoble
Found Date: 11 Sep 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]