RE: html5 editor responds to Canvas accessibility related bugs

Rich Schwerdtfeger
CTO Accessibility Software Group

Ian Hickson <ian@hixie.ch> wrote on 09/26/2010 09:39:34 PM:

> From: Ian Hickson <ian@hixie.ch>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: Frank Olivier <Frank.Olivier@microsoft.com>, Charles Pritchard
> <chuck@jumis.com>, Steven Faulkner <faulkner.steve@gmail.com>,
> "janina@rednote.net" <janina@rednote.net>, "public-canvas-
> api@w3.org" <public-canvas-api@w3.org>
> Date: 09/26/2010 09:39 PM
> Subject: RE: html5 editor responds to Canvas accessibility related bugs
>
> On Sun, 26 Sep 2010, Richard Schwerdtfeger wrote:
> >
> > Aside from individuals who care that accessibility is the right thing
to
> > do, companies that sell product to governments (federal, state, local,
> > and international) are required to sell accessible IT. Furthermore, the

> > U.S. Dept. of Justice recently stated that their interpretation of the
> > ADA is that it applies to all public web sites much the same way that
> > companies are required to put wheel chair ramps in place so that
> > mobility impaired people can access buildings. They do this so that all

> > people can participate in society regardless of ability and because
> > there are people and companies out there who see accessibility as a
cost
> > and if they were required to do it to sell to a customer would not.
What
> > you are hearing is that both IBM and Microsoft believe we need the
tools
> > to do the job as both companies have a long legacy of supporting people

> > with disabilities as it is the right thing to do and because our
> > customers demand accessible products. They also demand that we innovate

> > and possibly use canvas in ways you would not like. Also, we may buy an

> > innovative startup some day where, in most cases, accessibility is low
> > in priority and seldom addressed. Our job in accessibility is to allow
> > authors to innovate yet be given the tools to make the results
> > accessible. Frankly, it is a bit of a culture shock when they get
> > absorbed that they now have to support a whole host of requirements
they
> > did not have to before: IPV6, internationalization, accessibility,
> > security, privacy, etc.
>
> I completely agree and understand. My point is that the way to make a
> canvas editor accessible is not to bolt on some API to report the caret
> and selection position. It's to rip out the canvas and do it the right
way
> with contentEditable or <textarea>. As a side-effect, you will
> simultaneously also achieve better internationalisation (since it's
> unlikely the canvas editor will have bidi support), better features
(since
> it's unlikely the canvas editor will have platform-native drag-and-drop,
> spell-checking, selection-to-speech, direct-clipboard access, search
> integration, and all manner of other features present in browsers these
> days), and better reliability (since browsers are much more likely to
have
> been thoroughly debugged than a small team's canvas editor).
>
I would agree but imagine you are a company that has just bought some
startup that uses a canvas editor. The first thing that happens is it needs
to turn that puppy around and get it out the door in product. If you tell
the dev. team that what they did was stupid and the way to make it
accessible is to start over from scratch vs. add an API to track the caret.
They will choose the inexpensive route. Down the road, and after a number
of releases, they may do the right thing but in the mean time people do not
have access.

What I am trying to impress on you is that we do not live in a perfect
world and people don't do the right things. When they don't you and I can
use these technologies but other people are excluded in the process. That
is unacceptable.

>
> > A good analogy is seat belts. Many states have seat belt laws to
protect
> > people from themselves and to reduce the insurance liability costs. All

> > cars have seat belts - a tool to meet the law and to protect yourself.
> > You have the choice to ignore the seat belt warning and clip the belt
> > behind your back and continue on your merry way. That is your choice.
If
> > a person wants to assume the risk of injury and risk of getting a
ticket
> > who are we to argue?
>
> If clipping the belt behind your back is using a canvas editor, and
> clipping it in front is doing it right, then providing a caret/selection
> API is like providing a belt that you can tie to the belt behind your
back
> and then wrap around yourself. Nobody sells that, it would be stupid.
> Instead, if people want to be safe (if people want to make an accessible
> editor) they should unclip the belt from behind them, and clip it in
front
> of them (they should throw out the idea of using canvas, and use the
> native editing features). That's the law (both for belts, and for Web
> pages -- unless we provide an API, in which case we'll be saying you can
> use canvas, even though we all agree that's a bad idea).
>
Yes, but you keep ignoring the points we are making - a common debating
tactic.

1. Not everyone will clip the belt in the front.
2. Removing the API will not prevent people from drawing a caret. To your
point, not everyone thinks about
accessibility when developing new technology. Hence, we have Bespin.

Now if you ask me should we encourage people not to use <canvas> for this
purpose I would agree. However, you can't
regulate people just by using accessibility as a tool to do it.

> Let's not provide a belt to tie to the belt behind one's back.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'