- From: Frank Olivier <franko@microsoft.com>
- Date: Thu, 19 Nov 2009 17:47:55 +0000
- To: Richard Schwerdtfeger <schwer@us.ibm.com>, Steven Faulkner <faulkner.steve@gmail.com>
- CC: James Craig <jcraig@apple.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-canvas-api-request@w3.org" <public-canvas-api-request@w3.org>, Alexander Surkov <surkov.alexander@gmail.com>
- Message-ID: <DBB7A800D05F0C44A5EBA0231C567C39205A6284@TK5EX14MBXW652.wingroup.windeploy.ntde>
We discussed this at the HTML 5 Canvas accessibility breakout session. The two main reasons for creating a way to draw an 'OS styled' focus rectangle was: (1) The user gets to see the focus rectangle drawn in the correct 'big yellow border/high contrast' style (if the user set their display to be in black-on-white/white-on-black/big yellow focus rectangle high contrast mode) (2) If the user is zooming the screen using a magnifier, the user agent can tell the OS where focus is inside the canvas; the magnifier can then pan to the correct location on the screen. From: public-canvas-api-request@w3.org [mailto:public-canvas-api-request@w3.org] On Behalf Of Richard Schwerdtfeger Sent: Tuesday, November 17, 2009 5:57 AM To: Steven Faulkner Cc: James Craig; public-canvas-api@w3.org; public-canvas-api-request@w3.org; Alexander Surkov Subject: Re: handling focus 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 [Inactive hide details for Steven Faulkner ---11/17/2009 04:57:20 AM---Hi James,]Steven Faulkner ---11/17/2009 04:57:20 AM---Hi James, Steven Faulkner <faulkner.steve@gmail.com> Sent by: public-canvas-api-request@w3.org 11/17/2009 04:56 AM To James Craig <jcraig@apple.com> cc public-canvas-api@w3.org Subject Re: handling focus 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<mailto: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<http://www.paciellogroup.com/> | www.wat-c.org<http://www.wat-c.org/> Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Attachments
- image/gif attachment: image001.gif
- image/png attachment: image003.png
- image/png attachment: image004.png
Received on Thursday, 19 November 2009 17:48:38 UTC