Re: html5 editor responds to Canvas accessibility related bugs

Anyone attempting to use canvas as a mechanism to implement a text editor (I am unsure why people insist on wanting to do this) has more problems than simply accessibility.  You also have to worry about the text input managers that people use, and that's something that cannot be reasonably standardised.

The fundamental problem with input managers is that the event model from one platform to the next differs vastly, and the events and behaviour expected by each input manager are substantially different even on a single platform.  Any API that attempted to expose input manager behaviour and interaction would be extraordinarily complicated and unlikely to be used correctly, and even then would still not offer the full set of functionality people expect, depending on the platform, language, and specific input manager used for that language, IMs expect to be able to:

   * Access the full document that's being edited
   * Insert multiple different underlines around arbitrary text
   * highlight arbitrary amounts or arbitrary text, in arbitrary colours
   * replace multiple characters at once with an arbitrary number of different characters, in an arbitrary character set and font
   * insert text both before and after the cursor as the user types
   * be able to arbitrarily decide that a stream of text typed by the user should be removed
   * expect arbitrary sets of the changes they make to a document to not appear in (nor effect) the undo/redo history

To get correct behaviour an application needs to implement a huge amount of functionality so that all languages are covered.  I have yet to see _any_ attempt to create a text editor that gets this right, even those attempting to simply position their own logic between the use input and the browser's own editing machinery.

I think that rather than trying to hack accessibility onto a feature so that it may be used for something it was never intended to do, you should detail the missing functionality that you want/need from the normal text editing machinery that lead you to attempt to write your own editor in a canvas.

--Oliver

On Sep 28, 2010, at 4:49 AM, Richard Schwerdtfeger wrote:

> 
> 
> 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.   `._.-(,_..'--(,_..'`-.;.'
>