W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2010

Re: html5 editor responds to Canvas accessibility related bugs

From: David Singer <singer@apple.com>
Date: Mon, 4 Oct 2010 16:16:54 -0700
Message-Id: <BE118264-5061-4204-A716-01B16E0ECE5F@apple.com>
To: public-canvas-api@w3.org
I wonder if there are some conclusion jumps being made here, or at least extreme positions (these are both upcoming olympic sports, by the way).

I feel that one of the important aspects of a good 'tool' is that it can be used effectively in *unexpected* ways.  A good design has 'depth' and can be a platform for creativity.  So, while it might be inappropriate to write a text editor in canvas (in that, there are better ways to do it that work better and have fewer restrictions), we could take the attempt to do it as a example 'stretch' application and see what that tells as about the tool we have in hand (i.e. canvas).  The lesson is not 'writing text editors in canvas is the right thing to do' but that 'canvas might be weak in its accessibility support'.

This backs into another one; we should be careful letting a failure of imagination on our part dictate what is possible on other people's part.  If we cannot imagine writing something that needs 'deep' accessibility in canvas, should we therefore make it difficult or impossible to make such applications accessible?  We need to be pretty sure of ourselves to say 'no', unless the provision makes the design complex, unworkable, unlikely to be adopted, a lot of (assumed to be pointless) specification work, and so on.

Can we make it possible to write interesting interactive accessible applications in canvas, without doing harm to the ourselves or the specification?  If so, we have broadened the scope for invention.

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Monday, 4 October 2010 23:22:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:51 UTC