Re: Updated proposal round two (based on feedback from Monday's meeting)

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

Ian Hickson <ian@hixie.ch> wrote on 02/16/2010 07:11:31 PM:

> Ian Hickson <ian@hixie.ch>
> 02/16/2010 07:11 PM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
>
> cc
>
> "public-canvas-api@w3.org" <public-canvas-api@w3.org>:
>
> Subject
>
> Re: Updated proposal round two (based on feedback from Monday's meeting)
>
> On Tue, 16 Feb 2010, Richard Schwerdtfeger wrote:
> >
> > When possible a facility must me provided to make <canvas> directly
> > accessible to assistive technologies in such a way that an
accessibility
> > validator may detect the accessible binding in markup. The
accessibility
> > binding should be such that keyboard navigation of <canvas> be
> > consistent with standard HTML navigation in the DOM and as such the
> > author should be able to use the area between the <canvas> </canvas>
> > tags to implement this accessible rendering.
>
> I agree with all the above.
>
>
> > The fallback subtree differs from the accessible <canvas> subtree in
> > that the accessible <canvas> subtree is designed to have its rendering
> > directly drawn to the <canvas> whereas the fallback subtree is not.
>
> I agree that this is sometimes the case, though not always. In
particular,
> sometimes the no-canvas fallback subtree is suitable as an accessible
> subtree also.
>
Ian,

Yes, that might be true if the fallback subtree consisted of links, for
example. The point I am making is that the intent of the fallback tree,
currently, is not to exactly represent an accessible subtree for <canvas>.
In other words they have different purposes.

>
> > The challenge being that the author also uses the same <canvas> subtree

> > to represent fallback content.
>
> I don't understand why this is a problem at all. Since <canvas> is only
> usable when scripting is enabled, why can't the author simply replace the

> fallback DOM with the accessible DOM when it detects that the canvas is
> supported?
>
> As far as I can tell, this handles all the relevant cases correctly:
>
>  * Legacy UAs get the fallback DOM.
>  * Script-disabled UAs get the fallback DOM.
>  * New UAs without ATs use <canvas>.
>  * New UAs with ATs use <canvas> and the accessible DOM.
>
Ian, I think we are in violent agreement here. There is a difference in how
the subtree is used. When <canvas> is being rendered, today, the <canvas>
subtree is not used for keyboard navigation. This is in part due to the
fact that the fallback DOM was intended as a replacement for <canvas> in
non-supporting <canvas> UAs. It was meant be rendered in legacy browsers
when <canvas> is not supported.

So, we are in a situation where:

- When <canvas> is rendered the <canvas> subtree is not in the keyboard
navigation order.
- The <canvas> subtree may not directly map to the UI elements in <canvas>.
- A user agent does not know whether the <canvas> subtree can be mapped to
an accessibility API as a direct representation of <canvas> UI
- If the <canvas> subtree is a direct accessibility subtree mapping of
<canvas> an accessibility test tool needs to know this to test the subtree
and a user agent needs to know. There is no point in testing something for
accessibility if it is not actually used for accessibility such as when
<canvas> is supported.

> In the unfortunate cases where the author has not provided an explicit
> scripted accessible <canvas> subtree, but has provided a fallback
subtree,
> the situation still works ok:
>
>  * Legacy UAs get the fallback DOM.
>  * Script-disabled UAs get the fallback DOM.
>  * New UAs without ATs use <canvas>.
>  * New UAs with ATs use <canvas> and report the fallback DOM.
>
> This is better than if we had an attribute to distinguish fallback DOMs
> from scripted make-canvas-usable-by-ATs accessible DOMs, since in the
> latter case the AT would presumably just ignore the <canvas> fallback.
>
> In the even more unfortunate case where the author hasn't even provided a

> fallback subtree, there's nothing to disambiguate, so an attribute is
> again not needed.
>
So, the purpose of the adom attribute is to say that when it is set to
"true":

- Direct the browser to include whatever is in the subtree in the keyboard
navigation order as it is currently
being used to represent what is in the UI.
- Direct the browser to map what is in the the subtree to the platform
accessibility API as it is the author's intent to use
it as the accessibility subtree.
- Direct an accessibility test tool to analyze the subtree for
accessibility support when it <canvas> is being rendered

If <canvas> is not supported you don't need the adom attribute to be set to
achieve the above. Whether it is set or not is irrelevant.

If the exact same subtree can serve as dual purpose (fallback and
accessible shadow DOM) power to the author. UAs, DOM-accessing ATs, and
test tools simply need to know
the intent of the subtree <canvas> is supported.

Does this make sense to you?

>
> Maybe I'm misunderstanding what purpose the proposed attribute would
have.
> Could you describe what user experiences you expect ATs to provide for
the
> following two cases?
>
>    <!DOCTYPE HTML>
>    <title>Demo</title>
>    <canvas>
>     <p>TEST
>    </canvas>
>
>    <!DOCTYPE HTML>
>    <title>Demo</title>
>    <canvas adom>
>     <p>TEST
>    </canvas>
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'