W3C home > Mailing lists > Public > public-html@w3.org > January 2010

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

From: Philip Taylor <pjt47@cam.ac.uk>
Date: Wed, 20 Jan 2010 17:05:03 +0000
Message-ID: <4B5737BF.2090803@cam.ac.uk>
To: Steven Faulkner <faulkner.steve@gmail.com>
CC: public-canvas-api@w3.org, HTML WG <public-html@w3.org>
Steven Faulkner wrote:
> the only immediate point of concern I have about your explanantion is:
> [...]
> 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).

My experience here is limited to Flash content, where pressing tab to 
cycle through controls results in a thick yellow border around the 
currently focused control, which is similar to what I imagine canvas 
implementations would do. A single-pixel-wide black-and-white dotted 
line would likely be impossible to see in a lot of cases, and web 
browsers can't tell whether it's going to be enough, so they'd always 
have to do something much more highly visible (and therefore ugly).

In Flash, if I click on a button or in a text input box then it doesn't 
do that thick yellow border, and I'd expect the same in canvas (i.e. 
don't automatically draw focus rings when the user selects the control 
through the mouse/bitmap interface).

Thinking about it a bit more, I guess this can work alright with the 
current canvas model: When the user interacts with the canvas bitmap, 
set the focus on the appropriate fallback content element; and always 
call drawFocusRing with canDrawCustom=true, and if it returns true then 
do elegant custom drawing (e.g. for a text input it might simply be a 
flashing cursor). Then trust that users with a greater need for focus 
assistance will configure their UA to ignore the canDrawCustom flag and 
draw highly visible focus rings. It should be alright as long as 
browsers provide that configurability, and authors realise they should 
use the API in this way.

Philip Taylor
Received on Wednesday, 20 January 2010 17:05:32 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:08 UTC