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

Re: Accessibility, perfect or better Re: hit testing and retained graphics

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 6 Jul 2011 18:26:07 -0700
Message-ID: <CAAWBYDDx9Z_pj1047355tYAzTqztSivb=s-xtDirarVoAuJKWg@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: Charles McCathieNevile <chaals@opera.com>, "E.J. Zufelt" <everett@zufelt.ca>, Paul Bakaus <pbakaus@zynga.com>, John Foliot <jfoliot@stanford.edu>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cameron McCormack <cam@mcc.id.au>, Cynthia Shelly <cyns@microsoft.com>, "david.bolter@gmail.com" <david.bolter@gmail.com>, Frank Olivier <Frank.Olivier@microsoft.com>, "Mike@w3.org" <Mike@w3.org>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
On Wed, Jul 6, 2011 at 6:16 PM, Charles Pritchard <chuck@jumis.com> wrote:
> What do you mean by "run the web"?
> My comment was a reflection on the abundance of canvas implementations and how relative to SVG, canvas was quickly implemented. You asked me why I thought it likely that vendors would pick up -one- additional method in the specs. I answered; relative to more expensive standards such as SVG, which have taken a lot more time to implement.

SVG is already supported by every major browser implementor.

That said, implementations are lower priority than authors or users
when weighing features.  In general, users are most important, authors
are below users, and implementations are below authors.  (Below
implementations are spec authors and theoretical purity.)

> We are still discussing a simple and straightforward continuation of the focus ring / shadow dom effort. The shadow Dom is already in the specs-- this is a minimal addition and neatly fits in with other semantics from the Accessibility tree, the canvas subdom and DOM Core.

The focus ring API was specifically designed to offer some benefits to
the author, and to make it reasonably obvious when they're doing it
right.  This fulfills several of the criteria I offered up previously
concerning what a good accessibility solution would look like.  (Note
that it didn't *have* to do so; in fact, omitting those qualities
would have made a simpler and more understandable API.  But that
simpler API wouldn't be used as much, and thus accessibility would be
helped less.)

So far, the same is not true of binding paths to elements and somehow
figuring out z-order.

(Just creating paths is high-value for several reasons unconnected to
accessibility, but the simplest solution to those problems does not
help accessibility.)

> I understand you're an idealist, but you're blocking the way forward.

Sigh.  I'm trying to make sure you're actually solving real problems.
That's all I've been doing this entire time.  This is a fundamentally
realistic stance that's proven effective in the past.

Received on Thursday, 7 July 2011 01:26:59 UTC

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