RE: Accessibility and EME (was RE: Is EME usable regardless of the software/hardware I use ?)

Duncan Bayne wwrote:
> 
> 3. accessibility tools like screen-readers rely entirely upon being
> able
> to access media content and shift it into a format accessible by
> disabled users

This is not entirely correct, and with regard to media is a non-issue.  

Accessibility of Media (in HTML5) is achieved in a number of different ways,
dependent on the individual's disability. The "complete" [sic] list of
user-requirements can be found here:
http://www.w3.org/TR/media-accessibility-reqs/   

For users with mobility impairments ("physically disabled" as you wrote),
the real issues focus primarily on interoperability with the media player
controls, which will be part of the screen output from the browser (either
through JavaScripted controls, or via the native browser controls). Since
encryption will have little to no impact on those controls, EME/DRM has
little to no impact there. (If you believe otherwise, and have evidence to
support that belief, please do bring it forward. Assumptions, presumptions
and suppositions don't count. The accessibility sub-team will be reconvening
shortly to look at a few outstanding issues, and serious input will be
looked at fairly and without bias. If you are so inclined, I can ensure you
are invited to the teleconference.)

Screen reading tools used by the blind and low-vision user essentially
interacts with the DOM (or a virtual snapshot of that DOM, depending on the
tool), and so anything that is in the DOM is "shifted" to an alternative
output mode: text is rendered via either a speech output or Braille output
device via the Accessibility APIs of the different operating systems.  Blind
users however will be able to hear the encrypted videos audio stream exactly
like you will if you (or they) are using a device that supports the
decryption of the media stream. 

Deaf-blind users will need/expect captions/described video/transcripts, all
of which may, or may-not, be served as encrypted files or "clear" files if
delivered out of band - that is wholly dependent on the content owner and
creator. To date, we have zero evidence of that happening, and we've both
looked for that, and canvassed others of an awareness of that - no evidence
*at all* has surfaced. That search continues.


> 4. therefore, accessibility of content protected by CDMs will be
> limited

There is *no* evidence of that assertion today. The HTML5 Accessibility Task
Force (which included me - in person) specifically asked about this at the
Face-to-Face (the minutes of which I posted earlier), and the only concerns
we have at this time surround the "supporting" content that would consist of
captions, described video (audio feed), described video (text feed), and
related content such as picture-in-picture sign language interpretation (and
it is worth noting that we specifically looked beyond "just" closed
captions). 

The response we received then was that currently, if the supporting content
(closed captions, etc.) was transported in band (inside the media wrapper),
then it would be decrypted at the same time as the primary media content was
decrypted. If the supporting content was delivered out of band (see HTML5's
<track> element), and *WAS* encrypted, then it is conceivable that more than
one CDM *could* be deployed (where the primary media is encrypted/decrypted
by CDM "A", and the supporting content by CDM "B"). However there has been
no demand for this level of content protection by the major content owners
to date. It seems that there *might* be some additional overhead and
synchronization issues should that need arise, but the principle engineers
did not see any insurmountable technical issues around supporting that
use-case (any more than the overarching issues of synchronization, and
"time-shifting" - see the requirements doc). We left that discussion with a
"one-to-watch" status, but no significant concerns.

This is also significantly different that earlier DRM schemes in closed
systems, that wrongfully saw "Assistive Technologies" as some form of
"attack" and thus blocked access. With EME/CDM, the AT interacts with the
browser (which is the media player), and those browsers are already speaking
directly to the Accessibility APIs - my suspicion here is that access will
actually improve for PWD, not diminish as you have suggested. To prove
either however, we need implementations to test, which is yet another reason
for the FPWD at the W3C.

> 
> Please correct me if I'm wrong about any of that.

So you were basically wrong about *all* of that, from understanding how
Assistive Technology actually works, to *any* of the potential accessibility
issues of "HTML5 Media", as well as initially expressing this as an issue
for "physically disabled" users. It did not go un-noticed to me that you
then attempted to try and make this a screen-reader issue/problem (which it
really isn't either). 

My accusation of FUD stands, and my frustration and outright anger of you
attempting to invoke "accessibility" as a justification for not working on
EME is, to my mind, unconscionable. This is not the first time I've
encountered others attempting to "play the accessibility trump card" with
little-to-zero knowledge or understanding of the real issues, but, what the
heck, who is actually going to *oppose* accessibility and "doing the right
thing", so it's an easy point to score, right? Right.


That said, I also think that it is extremely valuable to point out here that
one of the benefits of working on this type of technology within the W3C is
this invaluable "cross-talk" between SMEs of different backgrounds and
expertise. Chasing this work out of the W3C eliminates (or significantly
reduces) the ability to have fresh eyes and ears looking at the spec, and
poking at it from unusual and different perspectives, such as
"accessibility". This is one of the greatest strengths of the W3C in my
mind, and a significant reason why, if this technology is going to evolve
(and it will, and be deployed first by the browsers, and then employed by
content owners) we should stay inside of that development and those
discussions: the alternative being that it happens anyway, but without the
involvement of other SMEs (who might not be considered as important, or even
at all, if developed behind closed doors).

Working on this technology inside of the W3C is probably *the best thing* to
happen to ensure accessibility issues are addressed.

JF

Received on Thursday, 13 June 2013 03:46:47 UTC