[Bug 27054] Accessibility Concerns

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

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |27093
         Whiteboard|Accessibility               |Accessibility, TAG

--- Comment #5 from David Dorwin <ddorwin@google.com> ---
Thanks, John. I've added some clarification and context inline.

(In reply to John Foliot from comment #3 with corrections from comment #4)
> (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). 

EME does not provide mechanisms for decrypting out-of-band support materials.
Only in-band content passes into the media stack and CDM.

In-band support materials _could_ be passed through the CDM. Ideally, these
would then be returned to the user agent to be presented as usual. I think the
concern is platform-based CDMs where this might not be possible. Also, some
implementations might directly render captions, etc. along with the video.
Perhaps we should normatively require that any in-band support materials (when
supported) be returned to the user agent and/or discourage encrypting them.

EME does not support multiple CDMs being used with the same media element. With
the push for interoperability and DRM-independent content (i.e. bug 27093),
this should not be necessary.

<snip>
> > 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-transport layer, and once the transport is "unlocked" all of the
> piece-parts (including any inband 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. 

EME assumes encryption is on blocks within the media container. That means the
media data can be read (i.e. to generate "encrypted" events) and the various
tracks can be processed independently. This is different, for example, than
traditional MPEG2-TS encryption.

As mentioned above, whether in-band encrypted support content is made available
to the UA depends on the DRM implementation.

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

I'm not aware of any current EME implementations that support decrypting
in-band support content. (That's probably a good thing as it implicitly
discourages encryption of such content.) If an implementation did, it should
return it to the UA as it would unencrypted timed text tracks.

The concern for high-contrast mode relates to implementations that do not rely
on or allow the user agent to do the rendering. For example, protected
audio/video pipelines may render the content directly, in which case the user
agent stack is not involved and unable to apply a high-contrast filter. See
https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#media-element-restictions
for related restrictions issues.

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

What are they intending to test? Since this is an implementation issue, you
would need to test all implementations.

Note that content is not "encrypted using EME". Content is encrypted per a
container-specific common encryption specification. Such content can be used
with EME as well as other platforms.

> (This response closes PFWG Action-285)

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

Received on Monday, 20 October 2014 21:10:35 UTC