Comments on: Canvas, accessibility and SVG

By: breton Slivka

breton Slivka — Mon, 21 Dec 2009 01:02:27 +0000

My thoughts on the canvas api and accessibility in the link to my name..

Basic summary: The canvas API is the wrong target for making bespin accessible. What needs to be made accessible is its widget toolkit, not the way it draw the widgets to the screen. How do we do that?

Nobody complains about CSS not being accessible. Why is that? I think canvas belongs firmly in the “Presentation” teir of the webstack, sitting right next to CSS. what’s missing is not some feature of the Canvas API, but the ability to expose Bespin’s object model to an accessable client without having to construct essentially a hidden and duplicated HTML DOM. What else is missing? A design that makes creating accessible apps useful to developers that are not disabled in some way.

By: suki

suki — Fri, 07 Aug 2009 03:40:55 +0000

Canvas and SVG are different, so they cannot be compared, but what is clear is all the propreitary rubish are given more attention by Browser implementors, except Opera and Firefox… W3C is more like the Don managing all the mafia…

By: Just how accessible is SVG? » iheni :: making the web worldwide

Just how accessible is SVG? » iheni :: making the web worldwide — Thu, 23 Jul 2009 10:50:35 +0000

[...] XML, being a text based language, also lends SVG to better accessibility than current headline grabbers such as HTML5 canvas which lacks an accessibility API or hooks for screen readers. While the WHAT-WG currently recommend a fallback – a draconian circa 1999 HTML alternative that confines screen reader users to a disability ghetto – they are working on a “built in” rather than “bolt on” approach asking for input from the accessibility community for viable solutions to make canvas accessible. Bruce Lawson has the lowdown on SVG versus canvas in his post Canvas, accessibility and SVG. [...]

By: David Storey

David Storey — Wed, 15 Jul 2009 13:30:44 +0000

Henri: The SVG tiger is just a image drawn using SVG. You can tell it is a tiger by the same way you would tell a jpeg is a tiger; use the alt attribute in HTML if you are using the image in HTML using the img attribute, or you could add a title or desc element to the SVG.

Where it becomes more important is when there is text in the document. In SVG it is just regular text, so can be pulled out or accessed fairly easily, instead of just being pixels on the screen. For UIs you can add attributes to describe what the elements are, such as the role attribute and WAI-ARIA. You could even transform the document using XSLT if you really wanted to.

There are obvious accessibility limitations to SVG at the moment as screen readers don’t read it yet, and less people know how to do it well yet. Once SRs get on the ball, there is no reason why SVG documents can’t be as accessible as HTML documents with little work. You can even include regular HTML elements in SVG via foreignObject if there is a need.

With canvas, doing the equivalent of the SVG tiger can probably be as accessible as SVG, but anything involving text and UI becomes a lot more complex without making an alternative version.

By: Bruce

Bruce — Wed, 15 Jul 2009 12:39:51 +0000

@Henri, good call. I mean (but didn't say) that for UI controls etc, SVG can have aria roles attached to it.

By: steve faulkner

steve faulkner — Wed, 15 Jul 2009 10:02:34 +0000

lachlan wrote:
“Using ordinary fallback content was and still is mostly fine for the major use cases of a few years ago”

I agree that this is the case, but think providing inbuilt methods in the canvas API to include fallback would make it much more likely that it is provided.