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


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

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


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


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.

-- 
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:58:26 UTC