Re: another example of HTMl 5 canvas with interactive UI elements.

On Fri, Jul 10, 2009 at 2:19 AM, Robin Berjon<> wrote:
> On Jul 10, 2009, at 09:14 , Joshue O Connor wrote:
>> Yes, the WG could strongly advocate the use of <canvas> for nothing
>> other than eye candy or pretty pictures. In fact the spec already pretty
>> much states that it shouldn't be used when there is a better solution -
>> not that many will listen as the genie is already out.
> That's not a solution. People advocated for years that images shouldn't be
> used for textual content and that changed exactly nothing. The only thing
> that could make textual images go was always going to be support for
> arbitrary fonts, because it then becomes easier to do it and to maintain
> than if you have to pull up Photoshop.

Indeed, this is the sort of solution I would strongly advocate.

While I do think we should come up with an official way to make
<canvas> accessible, it will by nature be a bolt-on accessibility
solution. And I think everyone agrees that these are all too often
simply not used by authors. What we can do is advocate authors of JS
libraries that make use of <canvas> and ask them to make the library
make use of the bolt-on mechanism, that way we would probably be able
to affect a larger number of sites.

But ultimately I think a better strategy is to look at *why* people
use <canvas> and give them to features that they need in order not to
use it. @font-face will hopefully be able to get rid of a lot of
in-accessible textual images (as long as the font foundries agree to
simple enough licensing terms). I think other CSS/CSS-like features
could help a lot with other places where <canvas> was used.

For example wouldn't it have been great if SVG or something like it
had been able to turn a <table> into the graph on, or the display on (which really is just a glorified table).

To paraphrase a well known quote: I want <canvas> to be legal,
accessible and rare ;)

/ Jonas

Received on Friday, 10 July 2009 18:04:30 UTC