Re: Canvas Accessibility Next steps

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

James Craig <jcraig@apple.com> wrote on 01/21/2010 02:07:06 PM:

> James Craig <jcraig@apple.com> 
> 01/21/2010 02:07 PM
> 
> To
> 
> Joe D Williams <joedwil@earthlink.net>
> 
> cc
> 
> Richard Schwerdtfeger/Austin/IBM@IBMUS, Ian Hickson <ian@hixie.ch>, 
> public-canvas-api@w3.org, HTML WG <public-html@w3.org>
> 
> Subject
> 
> Re: Canvas Accessibility Next steps
> 
> On Jan 21, 2010, at 11:35 AM, Joe D Williams wrote:
> 
> >> Regarding fallback content ...
> > 
> > Please continue with the term fallback as used in html for a long 
> time. The term is described in detail with <object> as meaning the 
> child html that is exposed when the browser can't do anything 
> constructive with the parent.
> 
> Yes, people discussing this issue appear to have different 
> perceptions of what 'fallback content' means. Thanks for bringing 
> some clarity back to the discussion of that term.
> 
> > When I first saw suggestions in this thread I thought, Great, a 
> standard container for non-rendered accessibility information. I 
> wanted to start calling it <access> as the top layer of 
> accessibility information available for the object or canvas, or 
> whatever else that needs it. So, or instance, a canvas element could be;
> > <canvas ...>
> > <access> whatever non-rendered html accessibility model could go 
> here with ARIA markup?</access>
> > </canvas>
> 
> This seems reasonable to me.
> 
This is fine. We were wrestling with a name to call it. We had used 
<default> for the time being. The reason I did not use the <access> 
element was because there was a discussion to take the <access> element 
out of the XHTML 2 working group to be used as a replacement for access 
key. I don't see anyone driving that at the moment so we could use 
<access> We can discuss this on Monday's call. If we think there is a 
group that is going to drive the access element proposal I want to avoid a 
naming conflict. 

> > Where <access> is never rendered, but <access> dom nodes 
> associated with the object are created and can be accessed by DOM 
> script document.canvas.access.node.attr.value in all cases.
> 
> Actually, that can be done today. Scripts always have access to the 
> DOM descendants of canvas. The main area yet to be decided is how 
> this should affect the focus model. For example, a sighted keyboard 
> user should be able to Tab to interactive elements in the canvas and
> interact with them. Likewise, a blind keyboard user should be able 
> to Tab to the same interactive elements in the canvas and, because 
> he is lacking the visual context, understand the role and other 
> attributes of each control. Hence the ARIA-supported access/shadow/
> sub DOM idea. 
> 
> > I think the only available place for this 'access' dom is as an 
> never-rendered element named <access> which can be included in 
> <canvas>, <object>, <embed>, <iframe>, <video>, and any container 
> that could use the hints provided in this 'shadow' dom to enhance 
> accessibility or interactivity of the frame. In elements other than 
> <canvas> context 2D this element could serve as a top-level 
> container for a model for interactivity of the 2D screen surface 
> exposed to the user. One aspect could be essentially adding some 
> level of interface information as a live overlay to the visual frame
> and providing some top-level elements for aria annotation.
> 
> These suggestions are also reasonable.
> 
> > The only other reasonable location for this information would be 
> an @access='url' attribute that held a link to this abstract model 
> for <canvas> context2D accessibility.
> 
> I'd prefer to keep it in the DOM. References to external 
> "accessible" content have a tendency to go stale.
> 
I think we need to keep it in the DOM if it is going to be in the keyboard 
navigation order. 

> James
> 
>