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

Re: html5 editor responds to Canvas accessibility related bugs

From: Charles Pritchard <chuck@jumis.com>
Date: Sun, 03 Oct 2010 14:01:18 -0700
Message-ID: <4CA8EF1E.4090405@jumis.com>
To: Ian Hickson <ian@hixie.ch>
CC: Richard Schwerdtfeger <schwer@us.ibm.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>
  On 9/27/2010 3:50 PM, Ian Hickson wrote:
> On Mon, 27 Sep 2010, Richard Schwerdtfeger wrote:
>> I am NOT in favor of directing developers to drop<canvas>  to enforce
>> accessibility in order to force them to do what may be the right thing.
>> That makes accessibility very hard to drive forward when costs are
>> unnecessarily raised.
> Are you also in favour of providing APIs to make it possible to write
> accessible text editors using nothing but radio buttons? Or do you think
> that we should tell people that doing that is not the right way to do
> things and that they should instead use the built-in text editing
> features? Why is canvas different?

I'm going to come out for this. A virtual keyboard is essentially a text 
editor
using nothing but radio buttons.

I've seen the same with online security entry pages. They generally use 
image maps.

Radio buttons are accessed via tab+space (two buttons, with some 
directionality added),
and by mouse events.

I see this as a valid way to implement an eye tracking solution for a 
paralyzed computer user.

How would you recommend such work be done?
I'd prefer to code that IME in the browser than in a OS specific program.

-Charles
Received on Monday, 4 October 2010 01:01:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 October 2010 01:01:35 GMT