Re: Proposal: Canvas accessibility and a media querries approach for alternative content (Action Item 6 in the HTML Accessibility Task Force)

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

public-canvas-api-request@w3.org wrote on 01/20/2010 07:17:38 AM:

> Steven Faulkner <faulkner.steve@gmail.com> 
> Sent by: public-canvas-api-request@w3.org
> 
> 01/20/2010 07:17 AM
> 
> To
> 
> Henri Sivonen <hsivonen@iki.fi>
> 
> cc
> 
> Maciej Stachowiak <mjs@apple.com>, Ian Hickson <ian@hixie.ch>, 
> public-canvas-api@w3.org, HTML WG <public-html@w3.org>
> 
> Subject
> 
> Re: Proposal: Canvas accessibility and a media querries approach for
> alternative content (Action Item 6 in the HTML Accessibility Task Force)
> 
> hi henri,
> i think you or I may be misunderstanding.
>  
> >The subdom isn't being rendered to the visual medium, so presumably
> it doesn't have CSS boxes generated for it, so it doesn't exist in a
> coordinate space >where click hit testing could be performed against
> boxes that correspond to DOM nodes.
>  
> I am not talking about applying the click hit testing to the subdom,
> I am talking about what happens when the click occurs
> trigger a window.location thing or
> pass the click to the <a> element in the subdom and let it do the 
> navigation event.
>  
> since one is providing the <a> anyway why would one duplicate its 
> native behaviour?
>  
>  
> thinking about this a little more...
>  
> what about the case of a canvas with a pseudo text input drawn on 
> it, wouldn't it make sense to let the input in the subdom deal with 
> the keystrokes and storage of text input?
>  
> <canvas>
> <input type="text">
> </canvas>
>  
> again, a keyboard user will be interacting with it, what sense is 
> there in saving and processing the canvas pseudo input content 
seperately?

The click would go to the canvas and the mouse handler would either 
activate the link or perform an equivalent action associated with the 
link. The mouse handler is on the canvas and not the shadow DOM so a click 
on the associated canvas area would require the canvas script to draw 
visible focus on the canvas and set focus on the shadow DOM input element.

> 
> regards
> Stevef
>  
>  
> 2010/1/20 Henri Sivonen <hsivonen@iki.fi>
> On Jan 20, 2010, at 15:01, Steven Faulkner wrote:
> 
> > OK, but I am trying to understand why one would do this?
> > if you include a link in the canvas sub dom so it will be 
> accessible to users, why would you duplicate the functionality using
> script instead of pointing the click event on the canvas to the link?

> The subdom isn't being rendered to the visual medium, so presumably 
> it doesn't have CSS boxes generated for it, so it doesn't exist in a
> coordinate space where click hit testing could be performed against 
> boxes that correspond to DOM nodes.
> 
> > in the end if a single method is suitable for all users its a win 
> for all no?

> Yeah. I'd expect SVG+ARIA to provide that. Can't put the <canvas> 
> cat back in the bag at this point, though.
> 
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
> 

> 
> 
> 
> -- 
> with regards
> 
> Steve Faulkner
> Technical Director - TPG Europe
> Director - Web Accessibility Tools Consortium
> 
> www.paciellogroup.com | www.wat-c.org
> Web Accessibility Toolbar - http://www.paciellogroup.com/resources/
> wat-ie-about.html