Re: hit testing and retained graphics

On Fri, Jul 1, 2011 at 7:41 AM, Charles McCathieNevile <chaals@opera.com> wrote:
> On Thu, 30 Jun 2011 03:16:18 +0200, Cameron McCormack <cam@mcc.id.au>
> wrote:
>> Matt May:
>>> Flash uses retained-mode graphics.
>>
>> If Flash doesn’t support immediate mode graphics, then I’m not sure how
>> it would be that the “Bespin/Skywriter canvas-as-UI problem … would have
>> been reasonably well supported by the accessibility support found in
>> Flash Player 8”.  Would you not have had to rewrite Bespin with Flash’s
>> retained mode graphics API (and thus avoiding this whole problem in the
>> first place)?  Isn’t this the same as people saying “rewrite your app in
>> SVG”?
>
> No, because if you *can't* write with immediate mode, you won't. If you
> *can* - as you can on the open web, using canvas, we can be reasonably
> sure that *someone* (and most likely, following that a whole lot more
> someones doing ever crazier things, and sometimes actually seriously) will
> do so. As was the case for Skywriter/Bespin. As was the case for certain
> products we have worked on at Opera.
>
> "Rewrite your app in SVG" is probably, in most cases, quite a lot of work.
> By comparison, "add a bit of SVG-like stuff to your app" (should that be
> the agreed way to improve things that for some reason or other are done in
> canvas) is often going to be rather less. Which is important in achieving
> accessibility.
>
> Demanding perfection is great if you only care about accessing what is
> perfect, but history bears out the fact that people want the stuff that is
> actually pretty badly put together, with minimal attention to
> construction, but which is actually interesting content. Simplifying the
> path for a developer to get it "right", and making it possible to get
> incremental benefits, is better than instituting an all-or-nothing
> approach which many people would predict will lead to a very large dose of
> nothing in places where we could have had "not perfect, but better than
> nothing".

I've expressed my feelings on this already, that an optional
accessibility solution that doesn't offer benefit beyond "makes the
app accessible in some aspect" is essentially useless.  It's not a
matter of being just "good" instead of "perfect", I think it's
actually bad - it will only be used by a tiny fraction of web devs
voluntarily, and generally only by companies when they're legally
required to do so (and even then, only the minimum required to comply
with the law, which can easily still end up being useless), but every
browser has to support and many authors have to learn about it.

The only way to do good accessibility is to sneak it in so that the
author accidentally makes things accessible while making it work well
for themself or their majority userbase.  It's almost impossible to do
"very good" or "perfect" accessibility this way, but it's relatively
easy to do merely "good" with this strategy if you're sufficiently
clever in designing the system, and more importantly, *every* app
gains this "good enough" accessibility.

I believe that, *after* doing the built-in accessibility, it's
reasonable to explore optional solutions so that people who really
care can patch their apps up past "good".  This is essentially what
ARIA does to HTML, which is fine.  But starting from the optional API
is, imo, almost guaranteed to have bad results, because you don't yet
know what's easy and what's hard to do, so you don't know what's
worthwhile to spend effort on.

~TJ

Received on Friday, 1 July 2011 18:11:08 UTC