Re: Action-219: Draft Response to MSE on Bug 23661

On Thu, 12 Dec 2013 20:25:42 +0100, Aaron Colwell <acolwell@google.com>
wrote:

For those who don't know me, I am chaals, co-coordinator of the  
Accessibility TF inter alia. Except when giving the results of a formal  
Call for Consensus I cannot speak on behalf of the TF, but I believe my  
views are at least reasonably representative as a rough guide to what the  
Task Force is likely to agree or not.

> Comments inline..

Likewise, but let me preface my remarks by explaining that the point of  
this request is to find the least painful point of consensus in the  
spectrum between insisting that all implementations meet all accessibility  
requirements in order to conform, and changing W3C policy to acknowledge  
its specifications do not actually provide for accessibility as a core  
value.

> On Thu, Dec 12, 2013 at 10:28 AM, Paul Cotton  
> <Paul.Cotton@microsoft.com> wrote:

>> See the extract from the A11Y TF IRC log below in which I made some of  
>> the points in your response during the A11Y TF discussion this
>> morning:
>>
>> http://www.w3.org/2013/12/12-html-a11y-irc
>
> Thanks. I appreciate this.
>
>>> Does HTML5 have a similar note?
>>
>> The TF plans to open a bug on HTML5 to cause this to happen.
>
> Ok. That seems like the proper path forward to me.

If you look at the log, you will further note that the reason for raising  
this against MSE first is that MSE is likely to ship well before HTML.

>>> I object to adding this note to the MSE spec. This is an attempt to  
>>> give weight to an accessiblity issue that should be solved by the spec  
>>> that defines HTMLMediaElement behavior (ie HTML5 & HTML.next) and
>>> not an extension spec that is simply providing an alternate way to
>>> supply media to the HTMLMediaElement.

Enabling a superior experience for users is a laudable goal. Indeed, it is  
also at the core of accessibility as understood at W3C.

A general part of W3C's claims about its technology is that they work for  
all people, regardless of disability - which in this case I believe one  
can reasonably interpret as "…including those who require signed  
captioning and other advanced potential sourceBuffers to be delivered to  
the HTMLMediaElement".

>> Without arguing for the TF’s request I do want to point out they are  
>> only asking for the addition of a non-normative Note.
>
> I understand, but I don't think we need to add an informative note in  
> MSE indicating how multiple tracks would be useful. In my opinion this  
> is a quality of implementation issue and if implementations want to make  
> MSE content accessible then they will support more than the minimal  
> requirements.

It is normal for W3C specifications to support maximal accessibility "out  
of the box", since access for all is one of W3C's core values. A  
specification which did not do so and required special unexplained extra  
implementation to support basic accessibility use cases would be  
reasonably likely to attract formal objections.

The proposed resolution of the Task Force assumes there will be shipping  
implementations incapable of supporting these use cases, but nevertheless  
useful in more restricted environments. It also assumes that there are  
people who expect to support accessible use cases by default, and indeed  
to look for solutions which do so as a matter of preference. It recognises  
this as a quality of implementation issue. It does not assume that the  
*only* way to provide high-quality accessibility is through the use of  
MSE. It merely requests that the specification acknowledge that a  
minimally conforming implementation may not satisfy certain use cases.

Indeed, the simplest method of satisfying it I can think of is adding a  
note on the addSourceBuffers method, after the definition of minimum  
requirements, pointing out that for some use cases, including  
accessibility-related ones such as signed video captioning, additional  
capability is necessary.

> I think people are reading too much into the 1 audio track and 1 video  
> track requirements. The primary purpose of these 2 bullet points were to  
> make sure that both "multiple tracks per SourceBuffer" and "multiple  
> SourceBuffers with a single track" must be supported by implementations.
> The 1 track requirement is simply a reflection of the fact that many
> devices will only be able to support these 2 configurations. Obviously
> if a UA was able to support sign language video tracks, then they would
> go beyond the minimal requirements.

It is not a priori obvious that a conforming implementation of a W3C  
Recommendation is unable to support basic use cases for accessibility. It  
is certainly not the general message that W3C promotes with regard to its  
specifications.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals@yandex-team.ru         Find more at http://yandex.com

Received on Monday, 16 December 2013 15:43:07 UTC