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

>
<canvas>
<fallback>

I think this is not 'fallback', it is an alternative/additive mapping 
of the visual elements, but the fallback is what happens when 
everything else fails and the 'fallback' content is used instead.
Great you are showing some augmentation details useful for making the 
canvas interactive and I think it is a new category of information 
supporting <canvas> accessibility. Why not call it something that 
indicates a certain category of information that is processed by 
certain types of interfaces like access with some attritues, and 
content like you showed.
Historically, fallback is what happens when the host cannot produce 
any rendering of the parent structure. Instead, this is a target set 
of information aimed at accessibility. This style of defining a 
descriptive container for access info could also be leveraged into 
<object>, <video>, and <audio> to contain alternative interface info.

Thanks and Best Regards,
Joe.



----- Original Message ----- 
From: "Richard Schwerdtfeger" <schwer@us.ibm.com>
To: "Ian Hickson" <ian@hixie.ch>
Cc: <public-canvas-api@w3.org>; <public-html@w3.org>
Sent: Saturday, January 09, 2010 5:09 PM
Subject: 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. 
> `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 10 January 2010 04:40:54 UTC