- From: John Foliot <jfoliot@stanford.edu>
- Date: Tue, 28 Jun 2011 14:32:27 -0700 (PDT)
- To: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, "'Charles Pritchard'" <chuck@jumis.com>
- Cc: "'Charles McCathieNevile'" <chaals@opera.com>, "'Richard Schwerdtfeger'" <schwer@us.ibm.com>, "'Cameron McCormack'" <cam@mcc.id.au>, "'Cynthia Shelly'" <cyns@microsoft.com>, <david.bolter@gmail.com>, "'Frank Olivier'" <Frank.Olivier@microsoft.com>, <Mike@w3.org>, <public-canvas-api@w3.org>, <public-html@w3.org>, <public-html-a11y@w3.org>
Tab Atkins Jr. wrote: > > The WHATWG wiki pages for Video Caption and Modal Dialog use cases > exemplify what is meant by compiling clear use-cases: > * > <http://wiki.whatwg.org/wiki/Use_cases_for_timed_tracks_rendered_over_v > ideo_by_the_UA> > > They examine existing usage to discover what features are important, > and give several examples of each. This way we can tell directly > whether the solutions we're crafting are adequate, by attempting to > recreate the examples with the proposed solution. And right there, you've identified the disconnect. Those "use cases" for video captioning are, frankly, bollocks, as they do not address a significant amount of accessibility concerns. Tab I must tell you that most folk I know scoffed at that WHATWG wiki page of anime examples and other screen-captures, as they barely scratched the surface in terms of identifying use-cases, or rather *user-requirements*. How could they? They are pictures, with no examination of what is actually trying to be solved, or even a clear understanding of what the problems are - at best those pictures illustrate some visual design requirements. That wiki page accurately exemplifies the slap-dash WHATWG approach to addressing any accessibility problem on the web - the "close enough, we can fix it later" approach. Contrast that collection of incomplete pictures with the detailed User Requirements that the media sub-team created, and you will quickly see that the incomplete "use-case" exercise that the WHATWG folks undertook was woefully inadequate. (http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_User_Requirements) Now today we have a <canvas> element that took the first approach (rather than the second one), and so we are in a situation where <canvas> is woefully inaccessible - in part because when it was being designed it wasn't examined and thought through w.r.t. accessibility, once again it was "close enough, we can fix it later". (I don't mean to pick on Ben Galbraith or Dion Almaer, but Bespin epitomized this: http://benzilla.galbraiths.org/2009/02/18/bespin-and-canvas-part-2/) Well, "later" is *now*. > > Note that not all use-cases are necessarily solved. For example, in > the captioning case, the "watermark" use-case was purposely not solved > by WebVTT. ...and for what it's worth, WebVTT is not the only solution for captioning videos. In fact, right now it is not even a full "standard". Specific to WebVTT however, it could and should support multi-level content navigation(http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Media_Accessibility_Checklist#cn) but it currently doesn't, as that user-requirement was never captured in those anime screen captures. > > I don't think I've expressed any objection along those lines. > However, talking about where mouse events are dispatched is definitely > on the "solution" side of things, and should be irrelevant at this > point (except as something to keep in mind as a potential avenue for > solutions). I think that Rich and company have been very clear in describing what the user-requirements are, and they have come forward with a solution based upon that investigation, continued discussion, and collaboration with AT vendors and now, game authors. Contrast that with the responses from the browser teams to date - "we don't think we need to do this, we don't want to do this, etc. etc." and even with the user-requirements before your very noses the engineers are rejecting a possible solution. I don't have a solution here, but I recognize foot-dragging when I see it, and the browsers really do seem to be dragging their feet. It's time they took responsibility for what they unleashed, and got this fixed. Either move forward with the solution that is being proposed, or come back with something better. Pretending that the user-requirements for hit testing don't exist, or that we don't have appropriate anime screen captures - er, use cases - doesn't cut it at this late date. The need for accessible canvas solutions has been known since at least 2009, if not earlier. JF
Received on Tuesday, 28 June 2011 21:33:01 UTC