RE: hit testing and retained graphics

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:
> *
> <
> 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.

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:

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 
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.


Received on Tuesday, 28 June 2011 21:33:06 UTC