Re: html5 editor responds to Canvas accessibility related bugs

Oliver,

I don't think anyone one is disagreeing with Ian or your rational that this
is a great deal of work. But unfortunately, many of us have worked in the
accessibility field for a very long time and if we do not address
accessibility in Canvas now we will see a rash of people creating full page
inaccessible canvas applications as we move more cloud based. I am sorry to
say this but Apple opened up a gigantic can of worms when it created
canvas. Accessibility was not addressed at all. So, now we are left having
to address accessibility late in the cycle. What I am telling you is we
have to hack this stuff in because the designers left it out and if we do
not address it we are hosed. A similar situation happened in the early
1990s when Windows was inaccessible. I was there when industry moved from
DOS to Windows. You really have no idea what will be coming.

I will also tell you that canvas accessibility has become a public concern
beyond our small team. I just had a discussion with the new accessibility
lead at e-bay and he stated that <canvas> accessibility was not addressed
and wanted to know how we could address these issues early on in the design
life cycle. Nobody dislikes more about having to clean up messes like this
late in the cycle as than accessibility people. All the designers point at
the accessibility people of creating an undue burden on them when it was
the designers who are in error.

You know back in the late 1990s the HTML community and the accessibility
community never envisioned that JavaScript would be used to create
applications and so they ignored the problem so much so that WCAG 1.0
prohibited the use of technologies like script and CSS. So, just because
neither you or Ian have never seen applications that do all of what you are
suggesting it is perfectly reasonable to expect someone to do so going
forward and I think all of us want to avoid a repeat of WCAG 1.0 technology
restriction clauses. Every government today is in the midst of redoing all
their accessibility legislation. It is entirely conceivable that they will
say "do not use canvas" as it is inaccessible. I will also tell you that
the editors public fighting to block things like longdesc and other
accessibility features are now getting seen negatively by many very large
IBM customers. If we continue down this path of exclusion I can see HTML 5
being blocked by government agencies. Are you suggesting that we allow this
to happen again?

Now, let me tell you what you need to know about accessibility. EVERY
accessibility API is bound to an object model that exposes accessibility
interfaces. We are looking to use the <canvas> subtree as that object
model. All the semantics and text are there to do most things we need to
do. Think of <canvas> as the view part of an MVC architecture. This DOM
will be used to populate the accessibility API used on every browser on
earth that supports an accessibility services layer.  In the infrastructure
you have the same type of architecture where there is an object model, a
UI, and an event model with some code to drive the UI.  What we do not have
with canvas is a way for a magnifier to track position dependent UI
information so that a magnifier can track where the user is on the page.
These would be:

- The caret position as it is typed
- The focus ring of where the user is operating
- The point of regard in text (on the screen) where they are selecting
content

We need your help in getting this right and we will gladly do all the
discouraging you and Ian desire to get people to not use it this way.
However, if they do something this stupid (which someone will) we can if
them a solution. If we can't do this I am perfectly willing to tell
industry to not use canvas because it is inaccessible which means
technology restrictions.

Now, for the normal text editing machinery in HTML 5 we already have
everything we need for accessibility.

Rich




Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Oliver Hunt <oliver@apple.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	Ian Hickson <ian@hixie.ch>, "public-canvas-api@w3.org"
            <public-canvas-api@w3.org>
Date:	09/28/2010 12:36 PM
Subject:	Re: html5 editor responds to Canvas accessibility related bugs
Sent by:	public-canvas-api-request@w3.org



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