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

hi maciej,

>If you're using the contained DOM children as a model/controller in this
way, then indeed, it's not just 'fallback'. It becomes a way of building
your application >logic in a way that also makes it very easy to expose to
assistive technologies. Doing it that way is an option, however, not a
technical requirement. You >could just as easily just assign window.location
to navigate, in this example.
 yes i understand that it is not a requirement nor was i suggesting it
should be. I was/am trying to undertsand the mechanics of the relationship
between the focus rectangle and the canvas sub dom. Though I do think it is
very useful to know that developers place content in the canvas element and
use it to drive interaction on the canvas rather than having to create it
all from scratch.

You could just as easily just assign window.location to navigate, in this
example.

but then you would be doubling up no? one method of triggering the
interaction for mouse users and one for keyboard users, seems like a waste
of effort?

>If you're using the contained DOM children as a model/controller in this
way, then indeed, it's not just 'fallback'.

so then the definition of what constitutes canvas fallback in the spec needs
to change.

regards
stevef


2010/1/20 Maciej Stachowiak <mjs@apple.com>

>
> On Jan 20, 2010, at 4:21 AM, Steven Faulkner wrote:
>
> > Hi Ian,
> >
> > >The click fires on the <canvas>, and the script is responsible for
> > >propagating the click to the link to cause the navigation (the UA has no
> > >idea that it corresponds to the <a>, so it can't happen automatically).
> >
> > so if the script propagates the click to the link element, it would seem
> that the content of the canvas element should no longer be considered
> 'fallback' as interaction and resulting actions are routed through the a
> element in the canavas element for all users not only those with
> disabilites.
>
> If you're using the contained DOM children as a model/controller in this
> way, then indeed, it's not just 'fallback'. It becomes a way of building
> your application logic in a way that also makes it very easy to expose to
> assistive technologies. Doing it that way is an option, however, not a
> technical requirement. You could just as easily just assign window.location
> to navigate, in this example.
>
> >
> > >On the other hand, if the user hits enter while the link is focused, the
> > >event goes to the link and the UA does the navigation automatically.
> >
> > so if the link is focused and the user clicks on the region within the
> focus rectangle then the click will pass to the link without the need for
> the script?
>
> According to what Ian said, that won't happen.
>
> Furthermore, objects in a canvas need not be rectangular and in general can
> be all sorts of funny shapes. While a rectangle might be the best
> approximation we can do for focus purposes, it would not be appropriate to
> force that restriction for hit testing. Not only that, but visual objects in
> the canvas can stack, and knowing their focus rectangles alone does not tell
> you the z-order, so even hit testing of purely rectangular objects might not
> work right (z-order might not match logical order and therefore might not be
> the order in which things appear in the hidden/fallback/model DOM.
>
> Regards,
> Maciej
>
>


-- 
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