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

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

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 22 Apr 2011 20:49:42 -0400
Message-ID: <4DB22226.9080205@intertwingly.net>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Mark Watson <watsonm@netflix.com>, Eric Carlson <eric.carlson@apple.com>, Ian Hickson <ian@hixie.ch>, "public-html-a11y@w3.org Task Force" <public-html-a11y@w3.org>
On 04/22/2011 05:50 PM, Silvia Pfeiffer wrote:
> On Sat, Apr 23, 2011 at 2:36 AM, Mark Watson<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>  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
>> 4.
>> 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
>> useful.
>> 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.
>> ...Mark
> 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.

The chairs are requesting an actual Change Proposal for anything that 
people would like to have surveyed.  More information in this post:


> Cheers,
> Silvia.

- Sam Ruby
Received on Saturday, 23 April 2011 00:50:11 UTC

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