Re: hit testing and retained graphics

Rich Schwerdtfeger
CTO Accessibility Software Group

public-html-request@w3.org wrote on 07/01/2011 01:10:16 PM:

> From: "Tab Atkins Jr." <jackalmage@gmail.com>
> To: Charles McCathieNevile <chaals@opera.com>
> Cc: Matt May <mattmay@adobe.com>, Cameron McCormack <cam@mcc.id.au>,
> public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
> Date: 07/01/2011 01:11 PM
> Subject: Re: hit testing and retained graphics
> Sent by: public-html-request@w3.org
>
> 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.
>
You cannot provide built-in accessibility from custom controls that do not
have the appropriate semantics. That is what ARIA is for. And we agree it
is best to use standard controls as you get accessibility for free. This is
your sneaking it in approach. That said, adding ARIA to host language
semantics still leaves much of the "sneak it in for free" handled by the
browser as if you ask people from the browser team it is a lot of work to
support platform accessibility APIs. In fact we estimate at IBM that it has
saved developers 80% of the development effort over native applications.
Also, when product teams go to HTML 5, I am going to stick the standard
controls in their faces and ask them to try and use those first before
going to a custom solution. It saves me and them a lot of time. That does
not mean they will do what I ask and in those cases that is why we have
ARIA.

In the case of canvas the author has a "blank" canvas on which to draw
whatever they please. With the enabled shadow DOM we are trying to leverage
as much of that 80% benefit as we can. Yet, there are things you get for
free in straight HTML that you do not get in canvas. In particular, that is
the bounds of an object. To provide that "sneak it in for free" piece we
have asked that we introduce retained mode graphics hit testing - or we use
SVG overlays to do the same.

> ~TJ
>