Accessible Platform Architectures Working Group Teleconference

08 December 2021


anevins, becky, Fazio, Fredrik, Gottfried, janina, JF, Jonny_James, Joshue108, Lionel_Wolberger, mike_beganyi, PaulG
Lionel, Lionel_Wolberger

Meeting minutes

<Lionel_Wolberger> present?

Agenda Review & Announcements;

<janina> https://lists.w3.org/Archives/Public/public-apa-admin/2021Nov/0012.html

janina: RQTF agreed for Captcha to go into FPWD
… goal is to get to Statement Status

<Gottfried> Master thesis: Development and validation of a concept for layered audio descriptions. https://nbn-resolving.org/urn:nbn:de:bsz:900-opus4-66690

Gottfried: A masters Thesis for 'new concept for audio descriptions' offering short, med and long
… with the player supporting end-user preference for short or long
… Support for audio explanations, targeted to COGA users
… 'Development and validation of a concept for layered audio descriptions'
… references the MAUR
… the student could present this material to APA

becky: Next week?

janina: Suggest January

Gottfried: I will check the 5th or the 12th for next year

janina: I'd appreciate the extra time in order to publicize the work prior to presenting it

JF: It uses an XML data structure, note that browser vendors prefer JSON today

Fredrik: How much of a proof of concept stage is it?

Gottfried: The open source AblePlayer was extended to consume the XML descriptions
… ble Player is a fully accessible cross-browser HTML5 media player.

Task Force Updates;

janina: RQTF update. Working on the SAUR.

PaulG: Pronunciation met with ARIA-WG.
… revising the candidate

Fazio: COGA spoke about a11y remote meetings, sent that in a comment to APA
… how to reference the Content Useable document (platform provider section)

janina: This won't be ready until next week.

Lionel_Wolberger: Personalization's response i18n was recorded in git this should clear the blocker
… went on to Modules 2 and 3, we see COGA involvement in future

New Charters Review https://github.com/w3c/strategy/issues?q=is%3Aissue+is%3Aopen+label%3A%22Horizontal+review+requested%22

MichaelC: Second Screen discussion

<janina> https://lists.w3.org/Archives/Public/public-apa/2021Dec/0011.html

<MichaelC> https://github.com/w3c/strategy/issues/291

janina: Had a dialogue with Francois regarding the broader meaning of Second Screen
… and the sending of captions

becky: Clarifying. Ignoring a11y. Does second screen mean separating audio, video, caption streams?

JF: Discussed on MAUR. It is simply a second screen, sending streamed content to the device
… refreshable braille output device distracts from the fundamental question
… which is, when sending content to a Second Screen, the supplemental pieces (caption) can be furnished in-band or out of band
… out of band should be sent with the child construct of, "track"
… this ensures the second screen(tablet, watch, telephone) will have the responsiblity to provide the AT support
… Consider a dumb terminal without a speaker-- it will lack the ability to drive audio
… the second screen is never in the control (aka master) role. e.g., only the primary device can hit pause, which controls the media stream
… APA could insist that the second screen must support assistive technologies

becky: This is about chartering

janina: The charter can enforce that they are defining an API
… we are still clarifying what they can and cannot achieve

JF: The issue seems to be output vs input. the second screen can process the stream regardless of the primary device
… make sure the second screen is not constrained in any way

Lionel_Wolberger: It seemed that some people hinted that the second screen has all capabilities. We want to be sure that the second screen can consume the API properly, and then render whatever it is a capable of rendering, including any AT-oriented information

JF: Yes, that is the intention. The Second Screen API should ensure that all the relevant HTML is sent to the second screen including any anciallry data,
… particularly a11y information
… must remain intact so that if the second screen *can* render, it will

janina: For example, the Bluetooth Speaker may be selected (by the user) to only receive the audio descriptions
… this relies on a good definition of the controller

JF: Two use cases
… (1) the controller is a selector, determining what the second screen renders
… (2) the secondary device has all information

becky: Main receiver is the controller, implies that the second screen has an API that can be queried, and respond with a list of the services that are supported

janina: A dumb braille display cannot. Other devices can.

Joshue108: Second screen may not be able to be a completely dumb device.
… an API to mediate the choices sounds important

JF: Their response was centered on a dumb device. What I seek is more clarification when the second screen is a *smart* device
… which can help the end-user make selections

janina: The response also said Second Screen APi would not support a text stream. This is a problem, as captions are always a text streem

JF: Text output does not imply that it will be a text stream. It may be transmitted in MP4 wrapper

janina: The use cases are in the MAUR
… we will ask for further clarifications
… as this is quite important to APA that we ensure the a11y information in HTML is made available to the Second Screen

JF: We want the HTML information to be preserved. We dont need it to be supported

janina: made available?

JF: Agree

+1 to preserving HTML a11y information to the second screen

MichaelC: They are pressuring to send it fast

janina: Will try to resolve before next Wed

Accessibility Review Comment Tracker https://w3c.github.io/horizontal-issue-tracker/?repo=w3c/a11y-review

<MichaelC> https://github.com/w3c/csswg-drafts/issues/6710

MichaelC: Scrollbars do not meet WCAG 2.0 AA requirements

janina: I suggest we track it

MichaelC: we will track

new on TR http://www.w3.org/TR/tr-status-drafts.html

<MichaelC> Explainer for W3C Accessibility Guidelines (WCAG) 3.0

<MichaelC> IMSC Hypothetical Render Model

becky: Consensus on this call: no need to track the explainer

<MichaelC> self review

MichaelC: It's about painting text subtitles

Lionel_Wolberger: What happens when the rendering device finds that it cannot render the subtitle?

PaulG: This is just a deciding process, and does not involve the failure state

Lionel_Wolberger: Due to a concern over handling of the rror state, Lionel to review the spec and give a summary to the APA list. Decide next time whether to close it

Dangling Spec Review Cleanup: https://www.w3.org/WAI/APA/wiki/Category:Spec_Review_Assigned

new on TR http://www.w3.org/TR/tr-status-drafts.html

Dangling Spec Review Cleanup: https://www.w3.org/WAI/APA/wiki/Category:Spec_Review_Assigned

becky: EPUB Reading Systems 3.3 was closed at TPAC

<becky> https://lists.w3.org/Archives/Public/public-apa/2021Dec/0012.html

<becky> WebXR Layers API Level 1

<Joshue108> https://www.w3.org/TR/webxrlayers-1/

WebXR Layers API Level 1

Joshue108: Adds composition layers (projection, quad, cylinder...)
… there is a question on rerendering and how it impacts legibility
… resolution for eye buffers
… The eye buffer is a required intermediate step when rendering stereo 3d on a rift.

MichaelC: The comment is not ready to send as-is, as it has an a11y question and is not an a11y statement

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).


Maybe present: MichaelC