Re: HTML 5 Canvas Accessibility Call on January 10

On Fri, Jan 14, 2011 at 5:37 PM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
> I think the IE team needs to look at the following:
>
> GTK client on HTML5 canvas:
> http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/
>
> noVNC - VNC client using HTML5 Canvas: http://kanaka.github.com/noVNC/
>
> A colleague of mine, Artur Ortega from Yahoo, was kind enough to point me to
> these implementations of canvas.  As I said, time and again, now that canvas
> has been been put into HTML we are going to find rich applications making
> extensive use of it and not basic HTML. With canvas HTML 5 has given the
> developer the keys to the store. I have seen a general trend by people in
> WhatWG (just going to lay it out there) that by inhibiting the efforts to
> make things like rich text editing and canvas (in the broader sense)
> accessible that this is going to somehow stop developers from doing things
> that they would prefer only be done in straight HTML.

No.

The idea is *not* that failing to provide bolt-on accessibility features for
canvas RTE will prevent people building canvas RTE. (Although it is
sometimes said that trying to provide them might provide false
encouragement, that's not the same thing.)

The idea is that people use canvas to build RTEs to solve a series of
problems that are not canvas-specific and that there is a severe
opportunity cost to helping people solve those problems with canvas
rather than @contenteditable. This goes for multiple aspects of building
an effective RTE, including not only accessibility but also security,
internationalization, and integration with system services.

We need to be very clear about what problems we are trying to solve since it
may be that different approaches work better for different problems.

We're dealing here with at least four broad use cases:

   1. Collaborative coding in an integrated development environment in
      the cloud (Bespin).
   2. Enabling users to enter rich text in multiple languages (Google IME).
   3. Using a cross-platform widget set to write an application once and
      deploy it in multiple environments (GTK client).
   4. Providing access to a remote desktop environment (VNC client).

It's not clear that the proposed features provide solutions to these use
cases, so it worries me that they're being presented as a hand-wavey
justification for speccing and implementing them.

The reasons given for creating an IME in canvas are all /stronger/
reasons for implementing good IMEs directly in the browser:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029759.html

With respect to cross-platform widget sets, it's not obvious to me why
"canvas" is a good solution for the problem. Interestingly, the GTK client
just renders pixels supplied by the server, which means it's behaving
more like a remote desktop environment client.

I think canvas does have a potential role to play in addressing the
remote desktop environment use case, but I don't think the proposed
features help. I'll discuss that use case in a new thread.

> I will say that the web standards community took a similar approach to
> JavaScript. In the early examples JavaScript was used for neat little
> advertisements on web pages. So, because people did not know how to
> solve the problem and there were not enough use cases for it at the
> time web accessibility basically degraded to say "if you use it you
> must provide an alternative as it is inaccessible". All the example I
> have been pointed to as the reasons for not addressing canvas
> accessibility are much like these advertisements. That led to new
> legislation that took years to extract. We did that using ARIA.

I've provided documentary evidence that undermines parts of this
historical account:

http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0001.html

The web standards community did advise against *depending* on JS; that
was good advice at the time and remains good advice today. There are use
cases where it's impractical advice; text entry isn't one of them but
real-time gaming, instant messaging, and remote desktop access are.

The critical problems faced by developers trying to make "Ajax"
accessible were poor styling abilities for controls on the part of CSS,
the poverty of the native HTML widget set, and the treatment of webpages
as static virtual buffers of text by AT. The first problem has only
been solved for users applying publisher images and CSS in GUI browsers,
the second one has been partially addressed by adding new semantics in
HTML5 and ARIA, and the third one has been addressed primarily by
changes in how AT approaches web applications and a shift away from the
virtual buffer model.

So long as we're looking at history, though, Flash provides a good case
study of why built-in accessibility (@contenteditable) is preferable to
bolt-on accessibility (canvas RTEs): authors don't use bolt-on
accessibility features, implementors don't fully implement them, and
users who would depend on them end up mistrusting the format. So if we
can meet a use case without depending on built-on accessibility, that
would be good.

> All the reall applications like those linked to above and Bespin that
> have proven to actually provide use to people we are being asked to
> ignore.

Nobody is proposing ignoring the people or the use cases. The discussion
is about what solutions to their problems we should concentrate on
providing.

> Now this may mean we need to create an accessibility API for the web
> which we can do and I have heard people from Microsoft and Mozilla in
> favor of that but let's go through the engineering process to get this
> right.

Agreed.

> I can't make the browser vendors address accessibility for canvas

In practice, we need browser buy-in unless AT vendors are happy to
query DOM properties directly.

> but we have an AT vendor here willing to work with us on this
> problem.

It's been a struggle to get AT vendors who are not *also* browser
vendors (Apple, Opera, Microsoft) involved in the standards process, so
I'd like to complement you on getting AI Squared involved. It's really
good news. :)

--
Benjamin Hawkes-Lewis

Received on Sunday, 16 January 2011 16:37:57 UTC