Evaluate Presentation API against the Media Accessibility User Requirements spec

[tidoust]

The Protocols and Formats WG has developed a set of requirements with a specific focus on secondary screens:
http://w3c.github.io/pfwg/media-accessibility-reqs/#requirements-on-secondary-screens-and-other-devices

The Presentation API should be evaluated against this list of requirements with a view to initiating discussions with the Protocols and Formats Working Group (PFWG). I propose to give it a try and report in this issue (unless someone else is willing to do so!).

The plan is to start discussions with the Protocols and Formats WG before TPAC so that we may schedule a joint meeting at TPAC to discuss outstanding issues, if needed.

That said, it may be wise to wait until the interface names and conformance classes (#91 and #93) get consolidated to ease discussions with other groups. It seems also a good idea to wait until we have a proper first draft for presenting the content of <audio> and <video> elements since potential media accessibility issues are more likely to arise there.

[tidoust]

I reviewed the list of media accessbility requirements that focus on secondary screens:
http://w3c.github.io/pfwg/media-accessibility-reqs/#requirements-on-secondary-screens-and-other-devices

Introduction

My understanding is that these requirements apply to user agents that would implement the Presentation API, and that our role is to ensure that the Presentation API does not contain anything that would prevent user agents from fulfilling them.

As written in the spec, the Presentation API always ends up with two different browsing contexts that do not share anything on top of a communication channel established between them. These browsing contexts may run on the same user agent (1-UA case) or on different user agents (2-UA case).

I believe that most of the multi-screens media accessibility user requirements were written with the presentation of <audio> and <video> content in mind, which the Presentation API does not address. That will be done in a separate spec.

The Presentation API does not really create a "system supporting secondary devices" but rather a situation where two devices exchange messages. As such, most of the accessibility requirements are either covered already at the single device level or rather apply to the Web applications that will run on the two devices and exchange messages.

Reviewing requirements

[SD-1] Support a platform-accessibility architecture relevant to the operating environment. (UAAG 2.0 4.1.1)

In the context of the Presentation API, this means that user agents that run the browsing contexts must support platform accessibility services. In the 1-UA case, the controlling user agent can guarantee that the receiving browsing context will run in an accessibility-friendly environment. In the 2-UA case, the controlling user agent cannot easily make such a guarantee (except for a restricted set of secondary devices which it may know about, e.g. because the browser vendor is the same for the controlling and receiving side).

The controlling user agent could perhaps flag secondary devices for which it does not know the accessibility support when the list of devices is read through some platform accessibility service. I'm not sure how this can be done in practice and how to phrase such a note in the spec though.

[SD-2] Ensure accessibility of all user-interface components including the user interface, rendered content, and alternative content; make available the name, role, state, value, and description via a platform-accessibility architecture. (UAAG 2.0 4.1.2)

A user agent may offer a mechanism to create/terminate a presentation on the controller's behalf (via defaultRequest) through UI buttons. If it does, it must make them available through its platform accessibility services. Does it need to be explicitly pointed out in the spec?

[SD-3] If a feature is not supported by the accessibility architecture(s), provide an equivalent feature that does support the accessibility architecture(s). Document the equivalent feature in the conformance claim. (UAAG 2.0 4.1.3)

The accessibility architecture of the user agents involved should be able to support all features.

[SD-4] If the user agent implements one or more DOMs, they must be made programmatically available to assistive technologies. (UAAG 2.0 4.1.4) This assumes the video element will write to the DOM.

In the 1-UA case, a user agent that supports platform-accessibility services must also expose the receiving browsing context to assistive technologies. Does it need to be explicitly mentioned in the spec?

[SD-5] If the user can modify the state or value of a piece of content through the user interface (e.g., by checking a box or editing a text area), the same degree of write access is available programmatically (UAAG 2.0 4.1.5).

Does not seem to apply to the Presentation API.

[SD-6] If any of the following properties are supported by the accessibility-platform architecture, make the properties available to the accessibility-platform architecture (UAAG 2.0 4.1.6): [...]

This requirement applies to each browsing context in isolation in our case. No change required.

[SD-7] Ensure that programmatic exchanges between APIs proceed at a rate such that users do not perceive a delay. (UAAG 2.0 4.1.7).

Does not seem to apply to the Presentation API.

Conclusion / Next steps

I did not identify a need to modify the interfaces and behavior of the Presentation API per se.
I suggest to get back to the Protocols and Formats Working Group with that first draft evaluation and ask for feedback.

[tidoust]

Note that I pinged the Accessible Platform Architectures (APA) Working Group, the new Protocols and Formats WG for spec reviews, after TPAC, as agreed. The APA WG is tracking the request on their own tracker, with 17 February 2016 as due date:
https://www.w3.org/WAI/APA/track/actions/2003

[anssiko]

Accessible Platform Architectures (APA) Working Group has produced an observations document as a response to the Request for an accessibility review of the Presentation API.

Summary: APA did not find any issues that would suggest changes to the spec.

@tidoust Since you interfaced with the APA folks, would you like to thank them for their review and confirm with them we can close this issue with no changes to the spec?

[tidoust]

@anssiko I got back to the Accessible Platform Architectures Working Group:
https://lists.w3.org/Archives/Public/public-apa/2016Apr/0028.html

I asked them to confirm that we may close this issue.

[anssiko]

Joanmarie Diggs of APA confirms:

As the one who reviewed your spec, I think it is safe to close the issue on your side with no changes needing to be made to the spec.