- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 17 Nov 2009 07:57:19 -0600
- To: Steven Faulkner <faulkner.steve@gmail.com>
- Cc: James Craig <jcraig@apple.com>, public-canvas-api@w3.org, public-canvas-api-request@w3.org, Alexander Surkov <surkov.alexander@gmail.com>
- Message-ID: <OFBD23D653.0C4DF97A-ON86257671.004BDA05-86257671.004CA8A1@us.ibm.com>
Steve,
Excellent point. So what you really want is the ability to set the focus
location in the visual canvas which then translates to an accessibility API
mapping. I was concerned that you were going to try and effect the drawing
on the visual canvas. That would not work as the developer would not
appreciate it.
The only way to do this would be to bind a rectangle to the shadow DOM
object. ATs will be doing an objectFromPoint, etc. on the focusable object.
We would need some script to set the "visible" rectangle on the Shadow DOM
object. Where the visible rectangle actually refers to the object in the
canvas with focus.
Rich
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Steven Faulkner
<faulkner.steve@g
mail.com> To
Sent by: James Craig <jcraig@apple.com>
public-canvas-api cc
-request@w3.org public-canvas-api@w3.org
Subject
Re: handling focus
11/17/2009 04:56
AM
Hi James,
>In the shadow DOM proof of concept I developed, I just drew the focus ring
with the canvas. I don't see any need to have a native focus ring drawn on
top of >the canvas. I'd say, leave a custom view like canvas for the author
to manage.
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?
I consider a solution that does not satisfy the following section 508
criteria [1] as inadequate and have yet to see any proposal that satisfies
this:
§ 1194.21 Software applications and operating systems.
(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.
[1] http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Software
regards
Stevef
2009/11/16 James Craig <jcraig@apple.com>
On Nov 16, 2009, at 5:27 AM, Steven Faulkner wrote:
> at TPAC the provision of a method to draw focus rectangles on a canvas
was discussed, and it appeared that this was considered necessary,
In the shadow DOM proof of concept I developed, I just drew the focus
ring with the canvas. I don't see any need to have a native focus ring
drawn on top of the canvas. I'd say, leave a custom view like canvas for
the author to manage.
> how does this fit in with the use of active-descendent to track focus
in a shadow DOM?
Only using 'active-descendant' would allow for a shadow DOM as deep as
one managed focus widget. This is fine, but a standard focus model inside
the shadow DOM is necessary, too. Otherwise you'd need to render a
separate canvas element for every complex widget, so something as complex
as Bespin could never be achieved by using a single active descendant.
--
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
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic21843.gif
- image/gif attachment: ecblank.gif
Received on Tuesday, 17 November 2009 13:58:29 UTC