- From: David Bolter <david.bolter@gmail.com>
- Date: Fri, 05 Feb 2010 15:11:15 -0500
- To: Ian Hickson <ian@hixie.ch>
- CC: Philip Taylor <pjt47@cam.ac.uk>, HTML WG <public-html@w3.org>, Henri Sivonen <hsivonen@iki.fi>
On 05/02/10 2:38 PM, Ian Hickson wrote: > On Fri, 5 Feb 2010, Ian Hickson wrote: > >> On Fri, 5 Feb 2010, Philip Taylor wrote: >> >>> To develop and test an accessible canvas application with focus >>> management, I'd expect it would be much easier if the author could see >>> the bitmap and the fallback content simultaneously, using their normal >>> mouse and keyboard input to interact with either version, and check >>> that both representations stay in sync and that the focus highlighting >>> is handled correctly. Once they've finished testing, they would want >>> the published version to work like it currently does (i.e. users are >>> shown the bitmap if possible, else the fallback content is shown >>> instead). >>> >>> Is this possible with the current spec? If not, I think there should >>> be a way to make the fallback content and bitmap visible together, >>> e.g.<canvas showfallback>...</canvas> (and authors can add some CSS >>> to the fallback content so it's rendered in a sensible position), to >>> help with this kind of testing. >>> >> That's a good point. I'm skeptical about allowing elements outside of >> <canvas> be focused while drawFocusRing() renders, because that means >> the screen would have two focus rings... but maybe that's ok? >> > (It would be a disaster while a magnifying AT is present, since the AT > would be jumping back and forth trying to magnify both at once.) > > Good point. I think the browser could decide to fire a native focus event just for the drawFocusRing case. cheers, David
Received on Friday, 5 February 2010 20:11:52 UTC