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