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

Re: feedback requested: Canvas change for improved hit testing that also facilitates accessibility

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 30 Mar 2011 10:03:20 -0700
Message-ID: <4D936258.5060807@jumis.com>
To: Oliver Hunt <oliver@apple.com>
CC: Richard Schwerdtfeger <schwer@us.ibm.com>, Boris Zbarsky <bzbarsky@mit.edu>, cyns@exchange.microsoft.com, david.bolter@gmail.com, faulkner.steve@gmail.com, franko@microsoft.com, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org, public-html-request@w3.org
I'm not particularly satisfied with the proposal, but the intent is to 
make canvas accessible to coordinate aware AT.
That's why Rich is bringing this to the developers. In an attempt to 
improve accessibility over the long term.

iPhone VoiceOver provides a good example of an area where canvas a11y 
falls a little short.
As the user pushes their position over the screen, a canvas element is 
treated as one whole image.

I believe Rich is looking at magnification ATs, which presumably need to 
know the position
of some elements prior to focus being called.

I had assumed that VoiceOver does not run any events on the DOM until 
after the user double-taps.
I was corrected on that point, and told that it does indeed run focus() 
onto the elements.

It does not run any coordinates through the DOM, however, until after 
the user double-taps in
confirmation. I'm running a little late on verifying and filing a bug 
report on the issue.

i'd prefer something event-based, like onfocus="drawFocusRing", leaving 
the hit
testing up to the author.

Rich, would you give some more examples of AT needs -- I'm still a 
little fuzzy on the Zoom AT,
though I have the general idea that the AT may know which elements it 
wants to try to
zoom into, but does not want to run a focus() command prior to doing so; 
and it may manage
the zoom level, and order, based on some unspecified heuristics.


On 3/30/2011 9:47 AM, Oliver Hunt wrote:
> This feels like an attempt to graft retained mode rendering on to 
> canvas, what am i missing?
> --Oliver
> On Mar 30, 2011, at 8:39 AM, Richard Schwerdtfeger wrote:
>> Thanks Boris. Sorry for being a pest but I really want developers to 
>> work through the issues.
>> So, you would do the following:
>> - Assign the a closed draw path to an element in fallback content: 
>> setClickableRegion(element). This immediately makes the association 
>> and places it at the bottom of the list.
>> - Any time you draw the element it moves it to the top of the list.
>> - If the fallback element is removed the association would need to go 
>> away. I did not address that so I will need to add that to the proposal
>> - When a pointer event (click, etc.) goes to the fallback element the 
>> normal capture/bubbling event processing would apply
>> Rich
>> Rich Schwerdtfeger
>> CTO Accessibility Software Group
>> <graycol.gif>Boris Zbarsky ---03/30/2011 10:05:48 AM---On 3/30/11 
>> 10:55 AM, Richard Schwerdtfeger wrote: > Seeing as nobody has 
>> commented can we assume tha
>> From: Boris Zbarsky <bzbarsky@mit.edu <mailto:bzbarsky@mit.edu>>
>> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
>> Cc: public-canvas-api@w3.org <mailto:public-canvas-api@w3.org>, 
>> public-html@w3.org <mailto:public-html@w3.org>, 
>> public-html-a11y@w3.org <mailto:public-html-a11y@w3.org>, 
>> public-html-request@w3.org <mailto:public-html-request@w3.org>, 
>> chuck@jumis.com <mailto:chuck@jumis.com>, cyns@exchange.microsoft.com 
>> <mailto:cyns@exchange.microsoft.com>, david.bolter@gmail.com 
>> <mailto:david.bolter@gmail.com>, faulkner.steve@gmail.com 
>> <mailto:faulkner.steve@gmail.com>, franko@microsoft.com 
>> <mailto:franko@microsoft.com>
>> Date: 03/30/2011 10:05 AM
>> Subject: Re: feedback requested: Canvas change for improved hit 
>> testing that also facilitates accessibility
>> ------------------------------------------------------------------------
>> On 3/30/11 10:55 AM, Richard Schwerdtfeger wrote:
>> > Seeing as nobody has commented can we assume that developers have no
>> > problem with our totally changing the canvas 2D API to support 
>> clickable
>> > regions?
>> It might just mean that people don't read their mailing list spam every
>> few hours.
>> From reading over your proposal, I'm not sure I follow how it would
>> behave in the face of DOM mutations (e.g. elements being removed from
>> the fallback content).
>> Or put another way, once you draw, you're permanently attaching some
>> element to the canvas, right? Or is that not the proposal?
>> -Boris
Received on Wednesday, 30 March 2011 17:05:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:52 UTC