Re: Canvas Accessibility Next steps

> I was referring to the focus model of descendant elements of the 
> canvas

OK, and maybe that is why this should be looked at as giving data for 
an abstract model of the interactive aspects instead of a real thing. 
Maybe I should study this more but generally if you want to do this 
you need a model for each action/reaction in each modality. Then 
use/addto ARIA as necessary so that you can express that model in the 
modality of interest. The data will then be used by AT to create an 
appropriate presentation with interfaces based on user requirements 
and preferences.

> Currently descendant elements cannot receive focus because the 
> elements are not rendered in any context, visual or otherwise.

Yes, that seems reasonable. The AT has to figure out how to make it 
happen and keep track of what has happened. I think the author doesn't 
do this, the AT helper does it. So, for simple 2D <canvas> 
http://dev.w3.org/html5/2dcontext/
if there are multiple buttons or controls and you want to keep track 
of what is being clicked, you have to do it yourself using host 
resources external from <canvas>. So, the way you get a dom for a 
control panel built in canvas 2D working is to build one, then keep it 
up to date as the user interacts. This might be entirely in script or 
maybe use some hidden html elements to save state.

> Those elements will probably need to behave as if they were rendered 
> but not visible.

I think you are asking the author to create this shadow dom that has 
some certain behaviors. But this is soon too much authoring for 
complex interactions in a 2D canvas. It is much easier in html, svg, 
and x3d, for example, where some of what you want is automated for the 
author.
I think for accessibility you only need to give enough information for 
each control to allow the AT to create a 'shadow' dom as appropriate. 
I still think that there is good in this progression, but I keep 
gettin tripped up on the shadow dom for canvas 2D where there is no 
DOM to shadow. There will only be possibly something approximating a 
DOM that can be shadowed after you code the simulation of it.

Anyway, I should think some more about this because it seems like a 
real opportunity to consider how to describe a set of functionalities 
that may be mostly hidden from the host DOM, as in <canvas>, <object>, 
and <embed>, maybe <iframe>, and even the old <img> with <map> combo.

Thanks Again and Best Regards,
Joe












I think an experimental thing could be produced by using a <canvas> 
that is intended to produce an event in the DOM when a <canvas> 
created button is clicked. If the button is the entire <canvas>, no 
problem and ARIA can be added directly to the <canvas> element. If 
there is more than one control in the <canvas>, then We will want to 
sense when the selector is over a particular button, and where it is 
when clicked, and where it is when the click is released. If the 
completed click is in the select area, then start a script that 
updates the containing page. .  . . .


the select is released.
 then add menus, sliders, and select lists. . , but suppose I wanted 
to construct a "real" overlay for the purpose of treacking clicks on 
the <canvas> window. I might draw a representative overlay and use 
browser pointer x,y tracking and some state in a script to rember what 
is focused and selected. Then the AT can extract the model and figure 
out what to do.
I would think there is only one decendant element, a model of the 
interactive aspects.

> In order to make a "shadow DOM" accessible, this focus model will 
> need to change for all modalities. Those elements will probably need 
> to behave as if they were rendered but not visible.





----- Original Message ----- 
From: "James Craig" <jcraig@apple.com>
To: "Joe D Williams" <joedwil@earthlink.net>
Cc: "Richard Schwerdtfeger" <schwer@us.ibm.com>; "Ian Hickson" 
<ian@hixie.ch>; <public-canvas-api@w3.org>; "HTML WG" 
<public-html@w3.org>
Sent: Thursday, January 21, 2010 4:58 PM
Subject: Re: Canvas Accessibility Next steps



On Jan 21, 2010, at 3:57 PM, Joe D Williams wrote:

>> The main area yet to be decided is how this should affect the focus 
>> model.
>
> I will say there is no <canvas> 2D  focus model except the general 
> element focus model for the canvas element itself. I think the 
> <canvas> element can get focus easily enough? That is all .. 
> literally no focus model for pixels of the bitmap.

I was referring to the focus model of descendant elements of the 
canvas, not pixel data in the bitmap. Currently descendant elements 
cannot receive focus because the elements are not rendered in any 
context, visual or otherwise. In order to make a "shadow DOM" 
accessible, this focus model will need to change for all modalities. 
Those elements will probably need to behave as if they were rendered 
but not visible.

Received on Friday, 22 January 2010 05:08:00 UTC