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

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:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0533.html

> Cheers,
> Silvia.

- Sam Ruby

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