Re: "Where's the Beef?" department (was RE: Example canvas element use - accessibility concerns)

On 2/25/09 1:33 PM, "Geoffrey Sneddon" <foolistbar@googlemail.com> wrote:
>> Isn't the question at hand here: would saying MUST rather than SHOULD
>> result in more sites being accessible?
> 
> Or is it: would saying MUST rather than SHOULD result in less sites
> being inaccessible? I bring up this nuance because MUST could result
> in sites having <canvas>pointless text to make this validate</canvas>.

Without a directly accessible <canvas> element, you're tilting at windmills
either way. Since there is no model for assistive technology to access
content within the canvas (even with basic functions like fillText()), the
only way to meet the SHOULD in the present spec is to reconstitute a second,
independent view using the HTML content of <canvas> as a common model, and
two controllers (or one really well-constructed one).

Bottom line? Won't happen. No matter what RFC2119 token you put in there.
The HTML accessibility model is predicated on the document structure itself
being solid enough to map to known assistive technology roles. <canvas> is
one of many deviations from this model in HTML5, which force authors to do
the work twice. If we can't get most of them to put 1% of their development
effort into accessibility, demanding double the work (in the spec that few
of them will read) is a non-starter. We may see a few basic examples that
follow this advice, but on the whole, virtually no one will.

I'd rather see a statement that <canvas> is not directly accessible, and
stop there. Anything less suggests that it shares the default accessibility
story of HTML 4, which it clearly does not. The cleanup techniques for
<canvas> should go in the WCAG 2 techniques for HTML5.

-
m

Received on Wednesday, 25 February 2009 23:32:49 UTC