- From: Rob Sayre <rsayre@mozilla.com>
- Date: Tue, 24 Feb 2009 20:29:45 -0500
- To: Jonas Sicking <jonas@sicking.cc>
- CC: "John Foliot - WATS.ca" <foliot@wats.ca>, HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
On 2/24/09 7:40 PM, Jonas Sicking wrote: > On Tue, Feb 24, 2009 at 4:15 PM, John Foliot - WATS.ca<foliot@wats.ca> wrote: >> I challenge you to show us *one* example of<canvas> in the wild that >> attempts to even consider accessibility, never-mind actually achieve any >> modicum of accommodation or equivalency. >> http://www.filamentgroup.com/lab/creating_accessible_charts_using_canvas_and_jquery/ It doesn't use the children of the canvas element, though. More below. >> In the grand tradition of WHAT WG >> the burden of proof rests in your corner - show us that developers using >> <canvas> today have taken the "suggestion" of ensuring that accessible >> fallback is present - I mean, after all, it *is* in the spec. >> > Isn't the question at hand here: would saying MUST rather than SHOULD > result in more sites being accessible? > Interestingly, most examples with fallback I could find use the children of the canvas element to send messages about browser support. One example is http://www.andrewwooldridge.com/canvas/canvasquest/canvasquest.html That tells me that the HTML5 has mixed accessibility and browser support concerns in specifying the fallback content for <canvas>. Beyond that, many of the <canvas> elements I did find were created with JavaScript after the page loaded. That tells me that a validator without JavaScript support isn't going to help much with this element. I don't have a good way quantifying or searching for data on this. Sorry. - Rob
Received on Wednesday, 25 February 2009 01:30:30 UTC