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

Steven Faulkner wrote:
> [...]
> what i mean is when a region of the canvas is being monitored for clicks and
> the response to a click is to call the drawfocus() method, this method
> includes a reference to an element, then the calling of the drawfocus()
> method should cause the focus to move to the referenced element. rather
> than  the developer having to manually move focus to the element via
> scripting.

I'm not sure I'm following this discussion correctly, but it seems to be 
diverging from what the HTML5 spec currently says about drawFocusRing(). 
If it's meant to be about what the spec says, it might be useful to try 
to clarify that (or maybe I'll just make things more confused...)

As per the documentation and example in 
<http://whatwg.org/html5#dom-context-2d-drawfocusring>, when you are 
writing a page using canvas I think you need to:

* Put some user-interaction elements (<input>s etc) inside the <canvas> 
element.

* When you redraw the canvas bitmap, call drawFocusRing(element, x, y) 
for *every* graphical shape that corresponds to any of those 
user-interaction elements. The UA will automatically draw the focus ring 
only when the element is focused - the canvas script doesn't have to 
worry about that.

* (The canvas script can choose to worry about it, if it wants to draw 
custom focus rings rather than the system default appearance, but that 
should usually be unnecessary.)

* Register event handlers on the user-interaction elements (onfocus, 
onblur, onchange, etc), and make them redraw the canvas bitmap to 
reflect the changes to the focus and to the content of input controls.

* Register event handlers on the canvas element (onclick, onkeypress, 
etc), and make them update the canvas bitmap as normal (you'd have to do 
this even if you don't have any accessibility support, to handle input 
from basic graphical users), and also update the user-interaction 
elements to match the current state.

* These canvas-element event handlers shouldn't change the focus (I 
think). If they did, it would cause focus rings to get drawn for basic 
graphical users who don't care about the accessible fallback at all, and 
focus rings are ugly. (Users who do care can use the tab key etc to 
focus the user-interaction elements, which will cause the focus rings to 
get drawn.)

It seems the difference is that you're expecting drawFocusRing() to be 
called by the script only once, for the shape corresponding to the 
currently-focused element. Is that a misunderstand of the spec, or a 
preferred alternative to what the spec says, or am I getting everything 
mixed up? :-)

(I don't think what the spec currently says is necessarily great, and 
the API is quite confusing, so I'm not arguing in favour of it. I 
haven't thought about it enough to identify specific problems or 
potential solutions, though.)

-- 
Philip Taylor
pjt47@cam.ac.uk

Received on Wednesday, 20 January 2010 15:53:00 UTC