- From: Janina Sajka <janina@rednote.net>
- Date: Wed, 18 Feb 2009 11:12:22 -0500
- To: Robin Berjon <robin@berjon.com>
- Cc: Philip Taylor <pjt47@cam.ac.uk>, Steven Faulkner <faulkner.steve@gmail.com>, HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, Janina Sajka <janina@rednote.net>
It's got to do even better than just providing text out, though. It's got to sexpose semantics, whatever structure, cursor in edit fields, status for buttons, etc., etc., -- all those excellent technologies already quite well understood in existing W3C technologies. Which realization raises in my mind the question, "Why? Why Canvas?" I don't see the benefit, either for a11y or for the web ingeneral. This rather reminds me of efforts over the last several years to make PDF "accessible." As we can plainly see in the history of PDF accessibility, it can indeed be possible to graft existing a11y support, but to what benefit? PDF can claim to be accessible, but only sometimes is the user who needs that accessibility better off with a PDF document. So, I'm of the opinion that solid value needs to be demonstrated for canvas. I'm not generally inclined to reinvent the wheel, or our perfectly good existing web technologies just because someone has a cool idea. Cool ideas need to integrate, else they're not cool at all. Janina Robin Berjon writes: > 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/ > > > -- Janina Sajka, Phone: +1.202.595.7777; sip:janina@CapitalAccessibility.Com Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina@a11y.org Linux Foundation http://a11y.org
Received on Wednesday, 18 February 2009 16:13:10 UTC