Re: [presentation-api] Evaluate Presentation API against the Media Accessibility User Requirements spec

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.

-- 
GitHub Notif of comment by tidoust
See 
https://github.com/w3c/presentation-api/issues/162#issuecomment-145823173

Received on Tuesday, 6 October 2015 11:04:33 UTC