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

Re: Helping Canvas Tag Be Accessible

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 30 Jul 2009 16:49:47 +0200
To: "Richard Schwerdtfeger" <schwer@us.ibm.com>
Cc: "Steven Faulkner" <faulkner.steve@gmail.com>, "HTML WG" <public-html@w3.org>, "W3C WAI-XTECH" <wai-xtech@w3.org>
Message-ID: <op.uxvx49cv64w2qv@annevk-t60>
On Thu, 30 Jul 2009 16:36:37 +0200, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
> "Anne van Kesteren" <annevk@opera.com> wrote on 07/30/2009 08:10:49 AM:
>> Doesn't this defeat the whole idea of <canvas>? If you want an
>> object model you could use SVG.
> I agree but we cannot ensure authors will do the right thing. It is just  
> a fact of life. I ask why IBM product teams can't use Dojo components and
> have to create their own equivalents for buttons, tab panels, etc.. I  
> would prefer that authors use SVG too.

If we cannot ensure authors to do the right thing, how can we ensure they'll do the right thing if we add APIs to <canvas> that make it do the same as SVG? That argument doesn't really add up.

>> A collection of callback interfaces that can be applied to objects
>> to support an accessibility API mapping on each browser and platform
>> and potentially a vehicle to fire events to ATs.
>> I'm not quite [sure] I follow this point.
> So for anything that is a property (like and ARIA property) we could  
> simply provide set/get functions in canvas objects. When specific properties
> change the browser fires an accessibility event. Pretty basic stuff.

But there are no <canvas> objects. That's sort of the point of <canvas>.

> However, for when it comes to text and tabular data this is not so  
> simple. Under the covers the browsers implement richer accessibility API for  
> tables and rich text that are bound to the corresponding data. That data  
> includes text, positioning information, caret position, selected text, table
> headers, etc. In fact, both IE and FF bind text interfaces to  
> text-related data in contenteditable areas. The problem with <canvas> is that once you
> draw the text the data is lost.

If you want a table you should not use <canvas>. (And please don't tell me that developers are stupid. They very well may be, but if they are they will also not do the right thing if you provide them even more APIs.)

>> This is already possible. Just include content between the two tags
>> of the element.
> I need to look at this more. There may in fact be a need to pull in an
> entirely alternative resource. Also, we need a vehicle to allow the  
> browser to choose which alternative to provide the users. For example, you may  
> need to interact with the alternative content between the <canvas> </canvas>
> tags. How does the browser know which to render?

If software was more tuned towards the users that would be no issue, but for now I think the page would have to provide some way to get to the alternate content just in case the user does not get it by default.

Anne van Kesteren
Received on Thursday, 30 July 2009 14:50:40 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:51 UTC