W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

Re: [media] proposed a11y TF letter on issue-152

From: Mark Watson <watsonm@netflix.com>
Date: Fri, 22 Apr 2011 16:15:43 -0700
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Eric Carlson <eric.carlson@apple.com>, Ian Hickson <ian@hixie.ch>, "Sam Ruby" <rubys@intertwingly.net>, "public-html-a11y@w3.org Task Force" <public-html-a11y@w3.org>
Message-ID: <CEF3F3EF-E02E-43EB-AF6E-FD6BD5282B70@netflix.com>

On Apr 22, 2011, at 2:50 PM, Silvia Pfeiffer wrote:

On Sat, Apr 23, 2011 at 2:36 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

On Apr 21, 2011, at 9:02 PM, Silvia Pfeiffer wrote:

On Fri, Apr 22, 2011 at 1:14 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

I would suggest a small change to replace the words 'However, we request'

with the word 'with', so that the sentences run together and our proposal to

withdraw 1-3 is somewhat contingent on the changes being agreed to proposal


I do not think that any of the change proposals 1-3 are sufficient and
all of them are inferior to proposal 4, even as it stands now. I've
asked Eric about this, too, and both him and I are going to withdraw
our proposals, no matter whether the changes are applied now or
continue to be worked on in bugs.

It's good that Ian is sympathetic to adding things exposed by media

containers, but I don't agree we should be constrained by that: as I said,

others (MPEG DASH) are looking to W3C to lead on these items and some (all?)

of the proposed 'kinds' are really pretty straightforward and obviously


Discussion is more productive than trying to force things. In the end,
what Ian says doesn't matter - what the browsers implement does. Eric
is supportive of this and IIRC so is Frank. That's the progress you
want - not stopping a solution for multitrack from going in because
not all the details have been sorted out yet.

I don't mean to force anything and maybe I am mis-understanding the HTML WG
process (which is anything but simple), but I think we should avoid the
situation where the multi-track solution goes out for LC with a significant
requirement not addressed (and btw, this requirement has been there from the
beginning and is properly addressed in Change Proposals 2 & 3).
My opinion is that if we shipped the spec to LC with a multi-track solution
that didn't meet the track discoverability requirements, this is evidence
that despite our best efforts we weren't able to converge on a solution in
time. It would be better to leave it out and work on it during Last
Call. Remember that we were all skeptical that we could get this done in
time, but we agreed to try.
The other four issues all have work-arounds, but the kind issue does not.
What's important is to me whether there's a general consensus. If the people
with opinions on this say it's no big deal and they're reasonably confident
we can work it out as a bug, then fine. But last I heard this was not the
case as there was a difference in principle as to whether W3C should define
these "kind" values itself for audio and video.

Hi Mark,

It's up to the chairs now how to deal with this. Maybe they can make a
survey that has proposal 4 accept/reject, and proposal 4 plus "kind"
attribute accept/reject as two alternative change proposals, while
requiring to register the rest as bugs. That way we can at least move
forward and have the multitrack in the spec. The alternative is not to
have any multitrack in the spec (as you are suggesting) and that is
clearly not acceptable from an accessibility requirements POV.

IMO it's not good either to have a solution in the LC draft which doesn't meet the discoverability requirement - from both an accessibility and also a more general perspective.

If UAs have to pick tracks randomly (because there are no kind indications) then it's hard for people to provide accessibility tracks since there's no control over what will be rendered by default. Nor is there any sensible way for UAs to present accessibility choices to users in the absence of external metadata, even if the accessibility choices are available in the resource. Is that acceptable ?

I must say this process is very frustrating. This was a documented requirement which was supported in multiple change proposals from early in the process and at the very last minute we somehow arrive at a proposal which does not include it.

In any other context, we in the a11y group would simply make our proposal, as we all agreed on Wednesday, and ask whether the wider group supports it. Why is this not possible ?


Received on Friday, 22 April 2011 23:16:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:54 UTC