W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: Example canvas element use - accessibility concerns

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>
Message-ID: <20090218161222.GT3789@sonata.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.


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;
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:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC