W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2009

Re: handling focus

From: James Craig <jcraig@apple.com>
Date: Thu, 19 Nov 2009 10:30:34 -0800
Cc: public-canvas-api@w3.org
Message-Id: <6574CDF3-6B42-42FF-801C-A1FDC86AF5DF@apple.com>
To: David Bolter <david.bolter@gmail.com>

On Nov 19, 2009, at 8:41 AM, David Bolter wrote:
> On 18/11/09 9:26 PM, James Craig wrote:
>> On Nov 17, 2009, at 2:56 AM, Steven Faulkner wrote:
>>> How do AT such as screen magnifiers provide focus highlighting of interactive parts of the canvas if native focus is not provided?
>>> How are they able to follow and bring currently focused elements into the viewport if there  focus is not programmatically exposed provided?
>> That's can be done with standard CSS positioning on the interactive elements in the shadow DOM. I'll update the proof-of-concept to include that use case. I can't promise it before the U.S. Thanksgiving holiday though.  
> This is a creative idea and reminds me of a very similar technique we had used for Dojo widgets, whereby we put a real, transparent input control overtop of the pretty dojo control, and the user (unknowingly) interacted with the real input. The pretty dojo control responded to the real input state and as such was really just a 'rendering' of that was going on. I think this mirrors what you want to try for canvas here.

Precisely. The main difference is that the keyboard user would be interacting with the real form element *behind* the visible representation, as opposed to your example, where the user was interacting with an invisible form element layered on top of the visible representation. 

Received on Thursday, 19 November 2009 18:31:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:48 UTC