[Bug 27054] Accessibility Concerns

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27054

--- Comment #3 from John Foliot <john@foliot.ca> ---
(In reply to Sergey Konstantinov from comment #2)

On behalf of the media accessibility sub-team of the HTML5-a11y Task Force:

> 
> - a number of technologies which make video accessible exists; some of them
> work or could potentially work in the Web;
> - we are very concerned that EME (especially coupled with hardware
> decryption) automatically makes most of these technologies inapplicable;

The HTML5-a11yTF, and the accessible media sub-team, have been monitoring
potential accessibility issues around the EME deployment. Specifically, this
was discussed at the F-2-F meeting of the HTML WG on 2013/04/23
(http://www.w3.org/2013/04/23-html-wg-minutes.html#item11).

Since EME is encrypting/decrypting the media stream content, a potential
problem could arise when accessibility support content (captions, described
audio, transcripts, etc.) is encrypted by a third party using a CDM different
than the source video content. At the 2013 meeting however, this edge-case
seemed unlikely, as content owners today are not requesting this level of
encryption support: the media asset is encrypted but any out-of-band support
materials are traditionally not. (Of course any encrypted in-band support
materials would be decrypted at the same time as the media.)  While this
edge-case still exists today (i.e. can a browser decrypt two streams, reliant
on two different CDMs, simultaneously and in sync?) it was felt that this rare
scenario could/should be best addressed at the authoring guidance level (i.e.
don't do it). 


> - so we'd like to encourage HTML WG to evaluate this question: find out what
> Web video accessibility technologies exist and how to make them work with
> EME.

The accessible media sub-team has already created the Media Accessibility User
Requirements (http://www.w3.org/WAI/PF/media-a11y-reqs/) which outlines what we
believe is a complete list of requirements, both from a content creation
perspective, as well as a playback/UI perspective, and when we looked at where
EME might have an impact, we could not see any other specific areas of concern.
We are however always open to more feedback and examples.


> 
> For example, to be sure that user will be able to increase subtitles font
> size or redirect them to a system text-to-speech service, EME spec should
> require CDM to have an API to transfer subtitles back to user agent after
> decryption

While I will ask an engineer more involved with the technical aspects of CDMs
to weigh in if I am incorrect, it is our understanding that the encryption is
done at the media-wrapper layer, and once the wrapper is "unlocked" all of the
piece-parts (including any in-band support content) would be exposed to the
existing APIs in exactly the same fashion as unencrypted content. In the case
of out-of-band content, again we have a low expectation of seeing encrypted
support content (while still leaving open the possibility that it could
happen), but once again, once the stream is unlocked, the content that comes
forth should operate and interact with the UA in exactly the same way as
non-encrypted content. 

There is no indication at this time that encrypted captions (for example) would
result in decrypted VTT or TTML files that would lock-down text scaling, as the
scalability of the text is controlled by the UA/UI, and not the
encryption/decryption of the media stream. Likewise for high-contrast mode or
TTS; it is our understanding that because EME only encrypts the content, and
has no direct impact on the user-agent stack, once the content is unlocked all
of the piece-parts are rendered to the DOM, where assistive technology then
picks up the thread.


> ...and/or encourage developing encrypted media transfer format with
> flat unencrypted subtitles stream alongside encrypted video stream.

We agree with this suggestion, and PFWG will ensure that this is taken back to
the WCAG WG as authoring guidance that should be formalized (Action on JF).
Based upon the feedback from representatives of Netflix, Comcast and others at
the 2013 meeting however, this already appears to be the case today: content
owners are not requiring encrypted support content at this time.

Finally, it is worth noting that PFWG intends to continue to monitor this
topic, and there are plans underway to begin testing using Assistive Technology
and demo content encrypted using EME

(This response closes PFWG Action-285)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 17 October 2014 20:13:19 UTC