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

Re: html5 editor responds to Canvas accessibility related bugs

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Mon, 4 Oct 2010 18:50:02 -0500
To: David Singer <singer@apple.com>
Cc: public-canvas-api@w3.org, public-canvas-api-request@w3.org
Message-ID: <OFF81ED269.CB713A68-ON862577B2.0081D2E5-862577B2.0082ECEA@us.ibm.com>

David,

I could not have stated that any better. Frank Olivier, Charles Pritchard,
and I have been looking how to stretch canvas to help support
accessibility. We have already discovered there is a way to monitor and set
carets/selections in contenteditable areas in the backing store. In fact,
Google appears to have a cross browser library to do it.

We just don't want to see HTML 5 go out the door and find we have shut the
door on people as we were unable to look ahead.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	David Singer <singer@apple.com>
To:	public-canvas-api@w3.org
Date:	10/04/2010 06:22 PM
Subject:	Re: html5 editor responds to Canvas accessibility related bugs
Sent by:	public-canvas-api-request@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.







graycol.gif
(image/gif attachment: graycol.gif)

Received on Monday, 4 October 2010 23:50:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 October 2010 23:50:42 GMT