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?


> 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?

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.

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".


> 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.


> ... 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>.


> 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.


> 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 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.


> 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.


> 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.


> 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.

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