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

hi philip, thanks for the explanation, i think i understand better now,

the only immediate point of concern I have about your explanantion is:

* 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.)
 >(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.)

basing the drawing of focus rings only for keyboard users does not resolve
the issue for  a range of users who use a mouse, but benefit from the viusal
cue of the focus ring , telling users you must use the keyboard to get the
focus ring is not really an option.

focus is drawn on most elements in browsers and on the desktop, when an
element receives focus not just for keyboard users. For whizz bang designers
an indication of focus may be something ugly (thus the use of CSS
outline:none) but for the majority of government, ecommerce
educational sites it is necessary if they want to conform to either section
508 or WCAG 2.0.(being a reflection of disabled users requirements).

for example section 508 1194.21 [
http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Software]
(c) A well-defined on-screen indication of the current focus shall be
provided that moves among interactive interface elements as the input focus
changes. The focus shall be programmatically exposed so that assistive
technology can track focus and focus changes.



regards
stevef


2010/1/20 Philip Taylor <pjt47@cam.ac.uk>

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



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