W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2010

Re: change proposal - Provide a method for canvas subtree to be hidden from all users

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 17 Mar 2010 18:34:31 -0700
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-id: <92E6095E-035E-437E-ABCB-7E4C031AA04E@apple.com>
To: Ian Hickson <ian@hixie.ch>

On Mar 17, 2010, at 6:25 PM, Ian Hickson wrote:

> On Wed, 17 Mar 2010, Maciej Stachowiak wrote:
>> On Mar 17, 2010, at 5:51 PM, Ian Hickson wrote:
>>>
>>> Not just accessible content outside the canvas, but accessible  
>>> content
>>> outside the canvas that represents static content that is generated
>>> with the page, and not fetched separate from the page. Most uses of
>>> canvas I've seen for graphs, including all those I've written, get  
>>> the
>>> data after the page is loaded, and would have to generate the table
>>> just like they generate the graph.
>>
>> Well even in that case you are saved one line of script to  
>> conditionally
>> clear the canvas fallback.
>
> Why would it be conditional?

Because you don't want to clear the fallback in browsers where canvas  
is not supported. (You also don't want to do any canvas drawing in  
that case, but you *do* still want to provide alternate content, even  
if it is generated dynamically).

>
>> In addition, the alternate form of the data could be behind a link,  
>> in
>> which case whatever is found on the same page as canvas is purely
>> static.
>
> True, though at this point we're way past the 80% rule IMHO.

It's hard for me to tell how common it will be to put a more  
accessible alternative outside the canvas, where everyone can see it  
or follow the link to it, as opposed to  inside. But I think in the  
case of an alternative visible to everyone, the nonav attribute would  
make it slightly easier to get it right, and slightly increase the  
odds that screen reader users won't be faced with an "upgrade your  
browser" message followed by actual accessible content.

I'm still not sure it is a hugely compelling feature, but it does not  
seem problematic in the same way as prior proposals (like the adom=""  
proposal or the <accessible> proposal). So while I do not strongly  
support it, I also cannot find a reason to object.

REgards,
Maciej
Received on Thursday, 18 March 2010 01:35:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:06 GMT