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

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.

Cheers,
Silvia.

Received on Friday, 22 April 2011 21:51:43 UTC