- 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 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. 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 ? ...Mark Cheers, Silvia.
Received on Friday, 22 April 2011 23:16:12 UTC