RE: FW: [canvas accessibility: faked "shadow DOM" proof of concept]

One more scenario

Low-vision keyboard users who have modified the rendering of the keyboard focus to make it more visible.  This modification can be done with OS-level settings (at least in Windows, and I think elsewhere), or by AT.

-----Original Message-----
From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Laura Carlson
Sent: Monday, November 16, 2009 6:02 AM
To: HTML Accessibility Task Force
Subject: Re: FW: [canvas accessibility: faked "shadow DOM" proof of concept]

The forwarded message below from Steve also relates to HTML WG tracker
issue 133:

http://www.w3.org/html/wg/tracker/actions/133


-- Start forwarded message --
From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Mon, Nov 16, 2009 at 7:27 AM
Subject: handling focus
To: public-canvas-api@w3.org

Hi all,
at TPAC the provision of a method to draw focus rectangles on a canvas
was discussed, and it appeared that this was considered necessary,
how does this fit in with the use of active-descendent to track focus
in a shadow DOM?

The user scenarios that need to be addressed are:
keyboard only users.
screen magnifier users who use focus highlighting features.
screen magnifier users who rely upon the characteristics of focusable
elements to move focused content into their viewport.

>From the discussions so far in regards to the shadow DOM, it does not
sound as if their will be a relationship between focus on the canvas
and elements in the shadow DOM.
If this is the case then not only will a shadow dom with focus managed
via active descendent have to be created to represent content to the
subset of AT users who do not require the content to be visually
rendered , but also focus management for areas drawn visibly on the
canvas, this seems like an unnecessary duplication?

--
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


-- End forwarded message --

Source: http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/0027.html


-- 
Laura L. Carlson


On Wed, Nov 11, 2009 at 6:58 AM, Michael(tm) Smith <mike@w3.org> wrote:
> The forwarded message below from James relates to HTML WG tracker issue 133:
>
>  http://www.w3.org/html/wg/tracker/actions/133

>
> The zip file containing James' proof-of-concept is archived at:
>
>  http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/att-0026/canvas_fake_shadow_dom.zip

>
> ----- Forwarded message from James Craig <jcraig@apple.com> -----
>
> From: James Craig <jcraig@apple.com>
> Date: Mon, 9 Nov 2009 09:36:19 -0800
> To: public-canvas-api@w3.org
> Subject: canvas accessibility: faked "shadow DOM" proof of concept
> Archived-At: <http://www.w3.org/mid/2A558E65-E5CF-45EC-AA8B-E325C3871B3F@apple.com>
>
> Last week at TPAC, I put together a faked "shadow DOM" proof of concept for
> the PFWG face-to-face meeting. I got a chance to work out the remaining
> bugs this morning, and promised Rich and Frank I'd send it to the list. The
> zip includes the demo as well as a copy of the Prototype JavaScript library
> that I used for event abstraction.
>
> The demo was tested and works on Mac OS X 10.6 Snow Leopard, with Safari
> and a WebKit nightly. The WebKit nightly will provide a slightly better
> experience due to recent implementation of the WAI-ARIA presentation role.
> Keyboard access works in Firefox (tested v3.5.5), but Firefox doesn't yet
> have AX API support, so I had no way to test the accessibility. That said,
> I expect it will work as intended in Firefox on Windows.
>
> Please view the comments in the HTML, CSS, and JavaScript for specifics on
> how it works now and is intended to work.
>
> Thoughts?
> James Craig
>
> ----- End forwarded message -----
>
> --
> Michael(tm) Smith
> http://people.w3.org/mike/


-- 
Laura L. Carlson

Received on Wednesday, 18 November 2009 20:58:20 UTC