W3C home > Mailing lists > Public > public-canvas-api@w3.org > July to September 2011

Re: hit testing and retained graphics

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 7 Jul 2011 16:48:47 -0700
Message-ID: <CA+c2ei8h-WpBQ0dbcRTEAVGsg9d87cZSR2+SzcAy6dnEwf3-2w@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: John Foliot <jfoliot@stanford.edu>, Charles Pritchard <chuck@jumis.com>, 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
Sorry for replying to an old email here, but this sat in my "drafts"
folder and I figured I might as well send it.

On Tue, Jun 28, 2011 at 4:40 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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*.
> I agree.  Did you think I was defending the current <canvas> API?  My
> argument is simply that I don't think the approach taken in this
> thread of defining a minimally-invasive API atop the 2d context is
> good.  "Minimally-invasive" fixes usually result in bad solutions.  We
> should instead be starting from a list of problems to be solved, so we
> can determine if the best solution is to patch the 2d context, create
> a new canvas context that better solves the problems, or use a
> different technology entirely like SVG.

For what it's worth, I don't think the disconnect is in if we should
start with use cases or not. I think the disconnect is between what
type of feature we're designing and thus the use cases are.

Some people are seeing the features as "accessibility APIs for canvas"
which essentially leads to the use case "support anything that people
can do with canvas".

Others are thinking of the features as "additions to the web platform
to enable it to do stuff in an accessible manner" at which point the
use cases are things like "pie charts", "angry birds", "fancy
checkboxes", "rich text editing".

As long as people have this disconnect, I believe we will be talking
past each other. Further, given the unbounded set of things that can
be done with canvas (which is basically the same set of things that
you can do with computer displays), I don't believe that we can come
up with good solutions for accessibility that actually makes pages
more accessible to people.

Or, put another way, when working with accessibility for computers, we
don't try to attack the problem "how do we make computer displays
accessible", we attack the problem "how do we make microsoft word
accessible, how do we make the OSX file system browser accessible".

/ Jonas
Received on Thursday, 7 July 2011 23:50:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:32 UTC