Re: html5 editor responds to Canvas accessibility related bugs

Rich Schwerdtfeger
CTO Accessibility Software Group

Ian Hickson <ian@hixie.ch> wrote on 09/27/2010 05:50:45 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 05:51 PM
> Subject: Re: html5 editor responds to Canvas accessibility related bugs
>
> 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?
>
Now you are just getting carried away to make a point. Canvas is nothing
more than a drawing surface.
It is no different than Windows GDI calls on a web page. To make it
accessible Microsoft created
an accessibility API that was associated with the drawing "canvas".

>
> > 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:
> > Bug10248 - Canvas requires a Caret Drawing call method
> > Bug10249 - Canvas requires a content selection method
> >
> > What are you going to do with them?
>
> Nothing more until someone adequately addresses the questions I raised in

> those bugs.
>
>
> > You stated that if I wrote two defect that you would take it from here.
>
That was sent in an email to me and not IRC. I followed up with a
discussion on IRC.

> The last I remember talking to you about this was on July 31st, in
> private, on IRC, where I said, and I quote, "it's not clear whether
> there's any point us defining this level of complexity (it would
literally
> be the most complicated function in the entire canvas API) for such a
> narrow edge case".
>
>
Yes, and that point you clearly stated in our IRC discussion. I was
surprised that you made me go off and
create a couple of defects against the Canvas API only to say that it was
not worth the effort -
my summary of your point above.

I translate that to you are wasting my time.

> > Adding features to contenteditable in the hopes that authors will use
it
> > to do the right thing is outside our pervue
>
> Only if you decide to punt on it. That's your decision. You get to decide

> what you spend your time working on. If your mission is to improve
> accessibility of the Web, then this is an area that would further your
> mission, unlike, IMHO, canvas API for caret positioning.
>
>
I think it would further your mission as contenteditable is not feature
complete.
What I have done is work with Mozilla and browser vendors to support a full
featured accessible contenteditable area.
It took 3 months of work as this was the first time anyone tried to bring
office accessibility features to a
web page. Oh and by the way they bind the contenteditable DOM which is tied
to the browser drawing surface to
accessibility API which in fact has a caret API.

> > ... 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>.
>
> There's no guarantee they'll use a caret API either. We don't work in a
> world with guarantees. We _do_ work in a world where we can influence
> authors by making the right way easier than the wrong way.
>
> In http://www.w3.org/Bugs/Public/show_bug.cgi?id=10248 you wrote:
> >
> > I would disagree with your statement Ian that accessibility APIs are
> > largely ignored. Enterprises are required to support accessibility.
>
> If anyone is _required_ to support accessibility then they can: by using
> contenteditable instead of <canvas>.
>
>
There is no guarantee that ANYONE will use an accessibility feature just
like there
is no guarantee that someone (the Bespin team) will use contenteditable for
text
editing.

So, it is clear to me that no matter how much time we spend on a canvas API
for drawing carets and selctions that you will give us a run around as you
simply
don't want authors to use canvas for editing text.

Accessibility services (APIs) have been used since 1995 to make canvas's
accessible. The entire Windows
OS, Mac OS, and Gnome/KDE destkops use them as does Java. Your argument
that nobody will
use these APIs is entirely conjectural and uninformed.

> > The second point I disagree with is dismissing the issue just because
> > you think it is stupid to create editors in canvas. Similar statements
> > were made about applications in HTML 4 then along came Ajax and
> > JavaScript and now they are used for web applications that 7 years
later
> > were made accessible using ARIA. In the meantime people can't do their
> > jobs and they become unemployed.
>
> The difference is that there was no supported way of making custom
widgets
> that could be made accessible, whereas there are at least three separate
> ways of making text editors in an accessible way already, and they are
> widely understood and widely used, and they have a multitude of non-
> accessibility reasons for being better than a <canvas> solution as well.
>
>
Yes but as you state contenteditable is incomplete and there is no
guarantee that
people will used it.

> > What you are advocating for is that magnifier vendors continue to
> > reverse engineer an accessible alternative that is constantly subject
to
> > OS breakage.
>
> Please don't say what I'm advocating or what I'm not advocating.
>
> I'm advocating using existing accessible solutions to the text editing
> problem instead of having people roll their own using an API that has
> nothing to do with text editing, and then, worst of all, having us
> legitimise their mistakes by providing them with APIs to work around
them,
> _especially_ because those APIs would have to be insanely complicated to
> actually address the use cases being proposed.
>
We can advocate that too but we can't make an author stick to doing the
right thing.
>
> > We need an engineered solution.
>
> We have three! <textarea>, contentEditable, and <input type=text> all
> address this use case today, in a fully accessible way, and what's more
> in a way that hooks into the platform features like the clipboard, drag
> and drop, search integration, spell-checking, etc, _for free_.
>
>
> > What you are saying is there is not good solution that solves
everything
> > you would like.
>
> Please don't tell me what I'm saying. There IS a good solution. There are

> THREE good solutions. They are already deployed, shipping, available,
> usable, and indeed widely used.
>
I am saying what you are saying. You have told me that they are incomplete.
If not you
would not be suggesting that I go off and spend time enhancing
contenteditable areas.

>
> > The reality is we may not get everything we need. For now I am
perfectly
> > willing to have an API that drives magnification as I think most
> > accessibility people would.
>
> The spec already has that.
>
>
No it is incomplet and does not handle things like Bespin.

> > What we cannot do is shuffle this problem under the rug as some authors

> > may created some form of text editor in <canvas>.
>
> They might also create one out of <img>s or 1x1 <div>s or radio buttons
or
> use any number of other mistaken approaches, but that doesn't mean we
> should provide mechanisms to support them.
>
>
> > So, if you actually believe that most authors are not going to create
> > text editors in <canvas>, and in fact should not, why would we spend an

> > enormous effort trying to make an API that draws and drive
> > caret/selection/blink in a magnifier at the same time?
>
> Beats me. I'm saying we should not. But if we are going to provide an
API,
> then it needs to be one that people will actually use and that will
> actually work.
>

yes, but you asked us to create a defect against canvas so that you could
add
all this additonal drawing capability. Now you want us to go do the work
for you which
in the end you will probably reject as you still don't want people using
canvas
in this way.
>
> > I wanted to pass one more thing along. When I talked to IBM researchers

> > about canvas and accessiblity the first thing out of their mouths was
> > basically " this is great, we can use it to draw HTML controls. can you

> > make that accessible?" This unfortunately is reality.
>
> If their problem is that they want to make HTML controls look different,
> then you should be working on providing them with features that address
> that use case, e.g. XBL or widget paint servers or the CSS UI module. You

> shouldn't be working on <canvas>, which isn't intended for that use case,

> and cannot do that use case well.
>
My point above. That model does not scale. If you buy a third party company
that
has already used canvas for this purpose you are stuck.

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'