Re: hit testing and retained graphics

On Fri, Jul 8, 2011 at 12:15 PM, John Foliot <jfoliot@stanford.edu> wrote:
> So having a higher-level conceptual model of how to address the larger
> question has value, even if that high-level model seems complex, less
> elegant or unintuitive. We all agree (well, certainly I agree) that this
> is sub-optimal, but so is using aria-role="button" on a <div> versus using
> <button>. When I work with devs on campus, I call this "Plan B" - if Plan
> A fails, what is your Plan B? If a developer uses immediate-mode graphics
> "incorrectly" we can wag our fingers and say shoulda, coulda, woulda, but
> that doesn't solve the immediate issue at hand: how do we retro-fit the
> problem to make it accessible? Where's our Plan B? ("Go back to square 1"
> is not a viable answer)

Why isn't it?  If an author starts by designing all their graphics as
table-based-bitmaps (like
<http://neil.fraser.name/software/img2html/>), should we go out of our
way to make them accessible, or should we tell them they're doing it
wrong and they should instead use this other tool that's
better-designed for their problem?

(Table-based bitmaps even share qualities with <canvas> - they're
dynamically generated from script, can change in arbitrary ways based
on user interaction, etc.  The only real downside from a practical
point of view is that they're very slow.)

It's not always worthwhile to spend effort on making it possible to
retrofit everything.


>> "rich text editing"
>> I think that the only good solution here is to severely improve
>> contentEditable. Currently contentEditable is a pain for authors to
>> use because it doesn't provide a low level API, only high-level things
>> like execCommand. It also works dramatically different in different
>> browsers and with lots of different bugs in all browsers. It's really
>> quite terrible. It's not surprising that some developers have said
>> "screw it" and attempted to do better using canvas.
>
> And it seems then that this is a major itch that needs scratching right
> now - certainly not the only one, but a really big one. The fact that "...
> some developers have said "screw it" and attempted to do better using
> canvas" is the very reason why telling them "don't do it" has very little
> traction - they don't have other choices right now. So faced with this
> truth, the canvas accessibility folks are attempting to develop an
> "ARIA-like" solution: sure it seems bolt-on, more complex, less elegant,
> less intuitive... but solving the problem that needs to be solved, and
> hopefully in a framework type of way that can be used for the next
> unimagined cool thing in <canvas>.

First, high-profile attempts to say "screw it" and do better with
canvas have failed, precisely because it's very hard to do.  It's
simply not feasible to do this sort of thing well.  People will
continue to try, and they'll likely continue to fail.

Second, Jonas outlined exactly what's needed for our "don't do it" to
actually mean something - we have to make @contenteditable better.
Luckily, we're doing that right now, with efforts like Aryeh's to
actually spec the features.

A "bolt-on" solution is entirely the wrong direction to go for this
problem.  We can solve it directly, and we're working on that solution
right now.

~TJ

Received on Friday, 8 July 2011 20:15:02 UTC