- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 7 Jul 2011 16:48:47 -0700
- 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