Re: Updated proposal round two (based on feedback from Monday's meeting)

On Tue, 16 Feb 2010, Richard Schwerdtfeger wrote:
> 
> When possible a facility must me provided to make <canvas> directly 
> accessible to assistive technologies in such a way that an accessibility 
> validator may detect the accessible binding in markup. The accessibility 
> binding should be such that keyboard navigation of <canvas> be 
> consistent with standard HTML navigation in the DOM and as such the 
> author should be able to use the area between the <canvas> </canvas> 
> tags to implement this accessible rendering.

I agree with all the above.


> The fallback subtree differs from the accessible <canvas> subtree in 
> that the accessible <canvas> subtree is designed to have its rendering 
> directly drawn to the <canvas> whereas the fallback subtree is not.

I agree that this is sometimes the case, though not always. In particular, 
sometimes the no-canvas fallback subtree is suitable as an accessible 
subtree also.


> The challenge being that the author also uses the same <canvas> subtree 
> to represent fallback content.

I don't understand why this is a problem at all. Since <canvas> is only 
usable when scripting is enabled, why can't the author simply replace the 
fallback DOM with the accessible DOM when it detects that the canvas is 
supported?

As far as I can tell, this handles all the relevant cases correctly:

 * Legacy UAs get the fallback DOM.
 * Script-disabled UAs get the fallback DOM.
 * New UAs without ATs use <canvas>.
 * New UAs with ATs use <canvas> and the accessible DOM.

In the unfortunate cases where the author has not provided an explicit 
scripted accessible <canvas> subtree, but has provided a fallback subtree, 
the situation still works ok:

 * Legacy UAs get the fallback DOM.
 * Script-disabled UAs get the fallback DOM.
 * New UAs without ATs use <canvas>.
 * New UAs with ATs use <canvas> and report the fallback DOM.

This is better than if we had an attribute to distinguish fallback DOMs 
from scripted make-canvas-usable-by-ATs accessible DOMs, since in the 
latter case the AT would presumably just ignore the <canvas> fallback.

In the even more unfortunate case where the author hasn't even provided a 
fallback subtree, there's nothing to disambiguate, so an attribute is 
again not needed.


Maybe I'm misunderstanding what purpose the proposed attribute would have. 
Could you describe what user experiences you expect ATs to provide for the 
following two cases?

   <!DOCTYPE HTML>
   <title>Demo</title>
   <canvas>
    <p>TEST
   </canvas>

   <!DOCTYPE HTML>
   <title>Demo</title>
   <canvas adom>
    <p>TEST
   </canvas>

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

Received on Wednesday, 17 February 2010 01:12:03 UTC