- From: Robin Berjon <robin@berjon.com>
- Date: Wed, 18 Feb 2009 16:16:12 +0100
- To: Philip Taylor <pjt47@cam.ac.uk>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, Janina Sajka <janina@rednote.net>
On Feb 18, 2009, at 15:52 , Philip Taylor wrote:
> The main problem I see with adding built-in (as opposed to bolt-on)
> accessibility to canvas is that I can't even begin to imagine any
> way that could ever possibly work at all :-). That may be largely
> because my imagination is limited - I'd be interested in concrete
> suggestions of how it could be done. Otherwise I can't think of
> anything the spec could say to help accessibility here.
Well the canvas text API gets text in, so it's possible that one could
get text out. The problem is: in what order. There are various
heuristics that could be used (the order in which it's drawn, its
rendered distance from the origin, or other more elaborate
approaches). I'm not saying it's ideal, or even the right thing to do,
but there certainly is information being provided by the developer to
the canvas API that could be exposed to AT.
There could, furthermore, be additional pushAnnotation(string)/
popAnnotation() calls added to the API that could provide alternative
text information about what is being painted. Again, I'm not sure that
that's a good idea, I'm just indicating that there /might/ be options.
Since Bespin is designed largely as an experiment (even if it is meant
to continue) it might just be the right place/occasion to have such
discussions.
At first thought I would tend to consider that a good first step would
be to write an authoring guide providing guidance as to when to use
canvas and when to use something else.
--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/
Received on Wednesday, 18 February 2009 15:16:50 UTC