Request for an accessibility review of the Presentation API

Dear ex-PF and new-APA WG,

[Not sure if I'm using the right mailing-list but public-apa@w3.org does not seem to exist yet]

With some delay on the initial schedule that we had in mind, I evaluated the Presentation API specification against accessibility requirements on behalf of the Second Screen Working Group. The result of that evaluation is below. Could you look into it and into the Presentation API itself?

The current plan is to move the Presentation API to Candidate Recommendation early 2016, so we'd like to ensure the API is on solid grounds from an accessibility perspective before the end of the year, if possible. Anssi, chair of the WG, Mark, editor of the spec, both in copy of this email, and/or myself, would be happy to present the spec to the APA WG or to answer questions on the spec as needed.

The latest editor's draft of the Presentation API is available at:

  http://w3c.github.io/presentation-api/

The Presentation API enables web content to access external presentation-type displays and use them for presenting web content. 

I reviewed the specification against the list of media accessibility requirements that focus on secondary screens in particular:

  http://w3c.github.io/pfwg/media-accessibility-reqs/#requirements-on-secondary-screens-and-other-devices

However, in the end, I am not convinced that these requirements directly apply to the Presentation API. I believe that most of the multi-screens media accessibility user requirements are written with the presentation of `<audio>` and `<video>` content onto second screens in mind, which the Presentation API does not directly address. The Second Screen Working Group will work on that as well, but in a separate spec that barely exists as of today.

Instead, 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).  As such, the Presentation API does not really create a "system supporting secondary devices" but rather a situation where two devices exchange messages.

Looking at the requirements with that in mind, I did not identify a need to modify the interfaces and behavior of the Presentation API per se, although the spec could perhaps benefit from additional text related to accessibility support here and there:


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


> [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 as it will not appear as a regular browsing tab. The spec should probably mention that explicitly. Do you have suggestions for this clarifying text?


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

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

This does not seem to apply to the Presentation API.


Thanks,
Francois Daoust,
W3C Staff Contact
Second Screen Working Group

Received on Friday, 6 November 2015 16:10:07 UTC