Re: html5 editor responds to Canvas accessibility related bugs

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.

So, you have two defects out to address the issues you point out in your
note in the canvas 2D API:

http://lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/0028.html

They are:
Bug 10248 - Canvas requires a Caret Drawing call method
Bug 10249 - Canvas requires a content selection method

What are you going to do with them?

You stated that if I wrote two defect that you would take it from here.
None of the accessibility team are familiar with how <canvas> is
implemented under the covers nor do we contribute to the source code of
<canvas>.

Adding features to contenteditable in the hopes that authors will use it to
do the right thing is outside our pervue, ... and even if all that
functionality were added to contenteditable areas there is no guarantee
that the author would not then try to render it with <canvas>.



Rich

Rich Schwerdtfeger
CTO Accessibility Software Group

ian.hickson@gmail.com wrote on 09/27/2010 01:53:17 PM:

> From: Ian Hickson <ian@hixie.ch>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
> Date: 09/27/2010 01:53 PM
> Subject: Re: html5 editor responds to Canvas accessibility related bugs
> Sent by: ian.hickson@gmail.com
>
> On Mon, Sep 27, 2010 at 5:40 AM, Richard Schwerdtfeger
> <schwer@us.ibm.com> wrote:
> >
> > 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.
>
> Exactly. That's why IMHO we must NOT provide them with an inexpensive
> route. If their ONLY option to make things accessible is to drop
> canvas, then they'll have no choice.
>
> By providing a caret/selection accessibility API, we would be _harming
> accessibility and usability_ by making it possible to do the wrong
> thing.
>
>
> > 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.
>
> Realistically, the people doing this aren't going to (correctly) use
> the accessibility APIs to make such tools accessible, unless they
> match the criteria I described in detail here (near the end):
>
>
http://lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/0028.html
>
> So far nobody has proposed an API that matches those criteria, and
> having tried to make some, I'm not sure it's possible. Until we have a
> proposal on the table that actually addresses those criteria, we're
> not arguing about whether to make things accessible, we are instead
> just playing accessibility theatre.
>
>
> > 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.
>
> I'm not saying we should. I'm saying we should provide better APIs for
> contentEditable to make it more likely that people will do the right
> thing.
>
> --
> Ian Hickson