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

On 7/6/2011 6:26 PM, Tab Atkins Jr. wrote:
> 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.
Partially implemented by major browser vendors; and it took quite  along 
time. Accessibility
is still not implemented and it's not part of HTML5.
> 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.)
Users are important to me as well, that's why I'm pushing so hard to
make my -Canvas- applications accessible.

>> 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
...
> So far, the same is not true of binding paths to elements and somehow
> figuring out z-order.
Richard's suggestion of including hit testing would certainly make 
things more -obvious-
to the author. What is the confusion you're having regarding z-order? 
z-index is pretty
widely known and defined. We're just using the DOMString semantics of 
z-index as
part of hit testing.

> (Just creating paths is high-value for several reasons unconnected to
> accessibility, but the simplest solution to those problems does not
> help accessibility.)
I agree. The simplest part, of having CanvasPath with stringify would 
certainly
help authors provide a space to improve efficiency in implementations, 
but by itself
does not improve accessibility. It does get us a step closer to a 
solution, however,
as it creates  a code path in the implementation to share data with ATs.
>> 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.
That's not a fair assessment. I've developed Canvas apps and I'm here 
because of -real- problems.
Several on the list have posted examples of -real- canvas apps as well 
as -real- data needs by ATs.

Your stance has been that the Canvas 2d spec is not an appropriate place 
to add a hook
to bind bounding box and path information to shadow DOM nodes, despite 
the precedence
set by drawFocusRing.  You've repeatedly said that SVG should be used 
instead... which does
not at all address the -real- problems I and others have encountered.

Received on Thursday, 7 July 2011 13:48:09 UTC