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

On Mon, 11 Jan 2010, Richard Schwerdtfeger wrote:
> >
> > 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.

Are you sure? It seems to work fine for me. A legacy UA would simply 
ignore the <canvas> elements altogether, and handle the fallback content 
natively. A non-visual UA would similarly use the fallback contents and 
ignore the canvas and scripted calls to the canvas. Why would it not work?


> The fallback is intended to be used to drive the accessibility 
> tree with canvas being the rendering of it.

Sure, in visual UAs that support <canvas>; those are not the only case, 
however.


> If we want to have an alternative renderable solution then we would use 
> an alternative modality as I had posted.

I don't understand why one set of fallback content isn't enough. Could you 
show an example where the fallback DOM for accessibility purposes would be 
different than the fallback DOM for non-visual UAs, and where the latter 
case would not be something made available to visual UAs?


> A low vision user may choose to use the canvas UI where it is supported 
> and still be accessible using the fallback subtree.

Sure. That works fine the way I described it (and the way the spec is 
written today), as far as I can tell.


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

Yeah, maybe "fallback" is the wrong word as well. I guess it's just the 
regular DOM tree. The canvas descendants, if you will.


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

This would cause a non-supporting UA to show both sets of content, which 
wouldn't work.


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

Ok.


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

Why can't we just make everything available to every user? In practice 
it's not like there's going to be an overwhelming number of choices 
anyway. It's already common practice to offer multiple "modalities", or UI 
views, for example calendar apps let you pick a "month" view and a "week" 
view. It seems like this woul dbe similar.


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

I don't understand why we would want, or need, to make the accessible 
canvas DOM any different than the regular fallback DOM.

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

Received on Tuesday, 12 January 2010 22:52:50 UTC