Re: Fw: Proposal: Canvas accessibility and a media querries approach for alternative content (Action Item 6 in the HTML Accessibility Task Force)

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

Ian Hickson <ian@hixie.ch> wrote on 01/09/2010 10:57:55 PM:

> Ian Hickson <ian@hixie.ch>
> 01/09/2010 10:57 PM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
>
> cc
>
> "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-html@w3.org
>
> Subject
>
> Re: Fw: Proposal: Canvas accessibility and a media querries approach
> for  alternative content (Action Item 6 in the HTML Accessibility Task
Force)
>
> On Sat, 9 Jan 2010, Richard Schwerdtfeger wrote:
> > >
> > > Fair enough. I strongly encourage you to use the term "fallback
> > > subtree DOM" or something along those lines, as IMHO it is more
> > > accurate than "shadow DOM".
> >
> > ok. Do you see any use for this other than accessibility?
>
> Presumably, the fallback subtree would be used for all user agents that
do
> not support <canvas> (whether because they're not visual, or because
> they're legacy UAs).
>
Actually, that won't work as the visual rendering is assumed to be the
canvas. The fallback is intended to be used to drive the accessibility tree
with canvas being the rendering of it. If we want to have an alternative
renderable solution then we would use an alternative modality as I had
posted. A low vision user may choose to use the canvas UI where it is
supported and still be accessible using the fallback subtree. In fact,
given my understanding of the definition of a fallback tree that does not
accurately reflect the intent. The intent of the DOM Subtree is to deliver
accessible objects and structure represented in the visual canvas.

We had not addressed the use case of browsers that do not support canvas as
our assumption was to support the HTML 5 spec. in its entirety. That said,
what you are considering to be the fallback could be the alternate visual
modality:

<canvas>
  <default > /!--  canvas accessible DOM subtree (using this vs. the
fallback DOM) assumes the canvas is a visual modality --/
 <div role="toolbar"> /!-- The UI for each one of these is drawn in the
visual canvas area --?
       <div tabindex="0" role="button" aria-pressed="false">Double
Space</div>
       <div tabinex="-1" role="button" aria-pressed="false">bold</div>
       <div tabindex="-1" role="button" aria-pressed="true">bulleted
list</div>
 </div>
  </default>
  <visual ATInteroperable="true"> /! This is the default Standard HTML 5
accessible content supporting accessibility interoperability and could be
used by browsers that do not support canvas-->
      <menu type=toolbar>
        <label> <input type=checkbox name=ds> Double Space</label>
        <label> <input type=checkbox name=b> Bold</label>
        <label> <input type=checkbox name=l checked> Bulleted List</label>
      </menu>
  </visual>
  <visual>
  </visual>
</canvas.
>
> > An author may wish to render their own toolbar, like in Bespin, but
> > because it is just a collection of polylines, text, images, and so on
it
> > is inaccessible. To make it accessible, we would simply create a
> > fallback DOM that looked something like the following:
> >
> > <canvas>
> > <fallback>
> >    <div role="toolbar">
> >       <div tabindex="0" role="button" aria-pressed="false">Double
> > Space</div>
> >       <div tabinex="-1" role="button" aria-pressed="false">bold</div>
> >       <div tabindex="-1" role="button" aria-pressed="true">bulleted
> > list</div>
> >   </div>
> > <fallback>
> > </canvas>>
>
> Why not use real toolbars and buttons?
>
>    <canvas>
>      <menu type=toolbar>
>        <label> <input type=checkbox name=ds> Double Space</label>
>        <label> <input type=checkbox name=b> Bold</label>
>        <label> <input type=checkbox name=l checked> Bulleted List</label>
>      </menu>
>    </canvas>
>
I have asked that we support input controls as well in the the aria
mechanism as well. I am waiting to hear back from the browser vendors if
this is acceptable.

> That way the focus is automatically handled, as is all the interaction
> logic, and the fallback works even with UAs that don't support canvas.
> Plus, the accessibility is free -- no need to handle both the logic and
> making sure all the ARIA attributes are set correctly, it's all
automatic.
> Plus, the CSS would work fine with this in the case of visual UAs that
> don't support <canvas> (or indeed, non-visual UAs that aren't ATs, e.g.
> speech UAs).
>

You don't have to sell us on standard controls.

>
> > I think where we may differ is that while alternative visualizations
> > would benefit all users and that they could be applied to the entire
> > page, it is not not necessary that alternative modalities be applied
> > only to the entire page. There is tremendous value add in providing
> > alternatives to individual regions like canvas, video, and audio within

> > the page as the rest of the page may adequately meet the needs of the
> > modality preferred by the user.
>
> Sure, but isn't this already possible? It's pretty common practice for an

> application to provide different ways of interacting with it. It doesn't
> seem like we need to do anything special to support this.
>
This is true. However, what is accessible is based on user needs. An
arbitrary application does not know what a user wants. By allowing a user
to apply their own media query capability they can programmatically tell
the browser what that would be through the use of the style sheet.
>
> I'm basically in agreement with what you're proposing -- but I don't
> understand how it is different than what the spec already does.
>
I hope the above makes this clearer. The purpose of the accessible canvas
DOM I hope explains this better.

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'