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/08/2010 04:30:21 PM:

> Ian Hickson <ian@hixie.ch>
> 01/08/2010 04:30 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 Fri, 8 Jan 2010, Richard Schwerdtfeger wrote:
> > > >
> > > > It is not like XBL 2 as the XBL 2 shadow tree cannot be accessed in

> > > > the browser DOM.
> > >
> > > It _is_ exposed to script, if that's what you mean.
> >
> > As I understood it, and I may be wrong, the XBL shadow DOM was not part

> > of the actual web page DOM ... I could walk the main DOM tree to access

> > these DOM elements in script. If it is then yes it is like the XBL
> > shadow DOM and we should stay with the term shadow DOM.
>
> The XBL2 Shadow Tree is exposed on the shadowTree IDL attribute on the
> DOM of the bound element.
>
>
> > Would a DOM inspector get the subtree DOM?
>
> That depends on the DOM inspector. There's no reason why one shouldn't.
>
>
> > > From your description it just sounds like the regular DOM. Maybe
> > > "fallback subtree DOM", if you feel the need to qualify the term.
> >
> > Yes, I feel we need to qualify this.
>
> 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?
>
> > If we were to expand this to the entire page that would be great but we

> > also need the ability to replace specific components of the page with
> > alternatives. For example, parts of the page may meet the user's need
as
> > is where other parts do not.
>
> Could you give a concrete example where there is alternative content that

> could not be given in the <canvas> element's fallback content and would
> not be appropriate for all users, such that you would want to actively
> hide it from some users? I'm having difficulty imagining what this case
> would be. The examples I've seen so far, and the user cases I studied
when
> designing the <canvas> accessibility story several years ago, all fall
> into the two categories of either (a) appropriate for <canvas> fallback
> contents or (b) suitable for all users.

Sure, but by hiding I mean the actual visual rendering would be the 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>>

The author would simply draw on the canvas and update the fallback DOM
which would be the accessible tree version of the canvas toolbar. The
fallback DOM would be mapped to the accessibility API. Visual focus on the
toolbar would be rendered in JavaScript. However, this fallback solution
has no styling as the actual rendering is being performed on the canvas.
There is no reason to use a style sheet on the fallback DOM. AS the
fallback DOM is not drawn in a consumable way (except via the canvas) it is
not suitable to all users. However, an browser can map the fallback DOM to
the platform accessibility API and transform them into accessible objects
for access by an assistive technology.

Now, I think we are almost on the same page regarding alternative
visualizations. The subway alternative visualization I provided was not
only accessible but would also be suitable for all users. Yet, for some
users the richer graphical version of the subway map on the canvas may be
more usable to others. It is simply a personal preference. 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.

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