RE: Canvas Accessibility Next steps

"I'd prefer to keep it in the DOM. References to external "accessible" content have a tendency to go stale."
I very much agree with this - Also, from an author's perspective, this is a more laborious process to create/maintain.

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of James Craig
Sent: Thursday, January 21, 2010 12:07 PM
To: Joe D Williams
Cc: Richard Schwerdtfeger; Ian Hickson; public-canvas-api@w3.org; HTML WG
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.

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

James

Received on Friday, 22 January 2010 19:32:46 UTC