Comments on: Thoughts towards an accessible canvas

By: Martin Kliehm

Martin Kliehm — Wed, 18 Mar 2009 23:45:08 +0000

I doubt that anybody will provide redundant content, because either the canvas content is way too advanced and beyond anything that is possible in plain old semantic HTML, or because nobody will take the pains of creating complex content twice. Therefore I would propose to make the child objects available in the DOM where they can receive any ARIA enhancements you can possibly bolt on by scripting. It is true that currently is just a flat bitmap that you can save as PNG or data URL, but when creating shapes and contents in a canvas, why shouldn’t you be allowed to add semantics at the same time? But a prerequisite would be browsers mapping those child objects to the DOM, and perhaps using the RDF features of the XHTML role module to expand the available roles by textnodes or things to describe 3D image galleries or future progressive UIs I can’t imagine at this time.

By: Olivier G.

Olivier G. — Wed, 18 Mar 2009 10:06:57 +0000

I think that the alternative to a Canvas element will often be much more complicated than just a paragraph of text.

What about a element, that could be linked to the canvas element through a id/for link ?

Your example of “american idol votes” could be alternatively renderer using a table element…

By: John

John — Tue, 17 Mar 2009 16:00:17 +0000

Ah…

Cat, I believe that all images ‘must’ (RFC 2119) have some form of textual equivalent, but believe as well that @alt is not always the answer. See: http://tinyurl.com/dgrd8b

I’ve taken heat over my comments about Bespin (and really, I don’t want to pick on them), but what, exactly, would you add as an alternative to that? In that situation, telling users what the region contains (and who built the thingy) is about all we can reliably and truthfully tell users – it isn’t perfect, far from it, but it *is* accurate, informative and at the very least shows some basic respect to those users barred from any further participation.

Overall, I have some real issues with canvas at a higher level, but the reality is that it is here, and will not be going away. Once again, we are playing catch-up, as once again the spec delivers us something new, with little real thought to the accessibility ramifications. All we can hope for at this point is to try and improve a shoddy implementation with some basic repair suggestions: right now the spec looks something like:

We can (‘must’ RFC 2119) do better! This is just a suggestion to start the dialog – I would love for somebody to better this idea.

By: catherine

catherine — Tue, 17 Mar 2009 15:32:35 +0000

Well, I guess I am one of the last people on the planet who still thinks ALT should not be optional but required. I understand that bad content is not helpful but I continue to worry about what kind of message this sends.

By: John

John — Tue, 17 Mar 2009 07:42:08 +0000

Because sometimes, from what I can see, there will be no real alternative. Good developers will likely try and provide an alternative, but the idea that bad alternative content is as bad, or worse than no alternative content makes sense to me, so personally I would rather keep this value optional, rather than have it gamed with bogus values. This BTW is the same issue as with alt in images, where uninformed developers will add crap values simply to have the tick-box satisfied.

By: catherine

catherine — Tue, 17 Mar 2009 01:24:28 +0000

Johnny,

An interesting proposal but, if I may ask, why make the ALTERNATE attribute optional ? From a user perspective, is that not where all the meat is ? I mean, if, as an AT user, all I can access is a short description of function (via TITLE) and the author’s name, what am I left with ? A short description of something I can not use and the creator’s “name” so I may perhaps let them know how I can not use their pretty thingy in the hopes they will let me in ? Am I missing something ? Or maybe you are hoping that WCAG will cover this, for those who adhere or are mandated to do so ?