Re: You Got Your SVG in my Canvas! Mmm, Delicious!

On Thu, Jul 7, 2011 at 5:51 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
>
> SVG does not have this provision. HTML does.
>
> SVG is not part of the HTML spec.

As Doug explains, these statements are false.

> Right now I am working on ARIA and HTML 5.

And therefore logically should be working on SVG alongside canvas, since
both can be and are being intermixed with HTML.

> I do not have cycles to solve SVG accessibility.

You may not, but the HTML platform includes "canvas" and SVG on an equal
footing. So don't be surprised when people who are implementors of the
platform as a whole, or just care about the accessibility of the
platform, mention SVG approaches problems in an HTML platform context.

> This discussion is on the HTML list.  Currently, the canvas element is
> in HTML 5

As is the "svg" element.

> If you can show me an SVG element in HTML 5 then great. I don't see
> it.

Please see the HTML5 spec for the "svg" element:

http://dev.w3.org/html5/spec/Overview.html#svg-0

Please also see SVG Web, a JS library providing SVG-in-HTML support in legacy
browsers (comparable to ExplorerCanvas, the JS library used to provide canvas
support in old Internet Explorer versions):

http://code.google.com/p/svgweb/

People are pointing to examples of canvas in use in an HTML context
to illustrate the urgency of solving the accessibility problems of
implementing apps this way.

In terms of real-world applications that are already in production,
SVG is being used in an HTML context in extremely similar ways.

For example, you've pointed to LucidChart, a diagramming application
built by sprinkling canvas elements around an HTML tree, as an example
of the sort of applications we want to help make accessible:

http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0089.html

There's a similar application, Diagramly, which sprinkles SVG elements
around an HTML tree:

http://www.diagram.ly/

It seems likely that future applications will use these technologies in
tandem. For example, pdf.js is planning on using canvas for a
first-pass render followed by SVG for a second-pass render. Some JS
graphics libraries abstract over both canvas and SVG, for example
Three.js:

https://github.com/mrdoob/three.js/

I see no reason to believe that the dominant authoring approaches of the future
will be:

    1. Just using ordinary HTML widgets, perhaps annotated by
ARIA.
    2. Painting all widgets to a single canvas element, then provide a
subdom using ordinary HTML widgets plus ARIA inside that element.
    3. Sprinkling canvas elements around an HTML tree to repaint
particular UI components.

Therefore it would be remiss of W3C to address accessibility in HTML5 as
though these will be the dominant approaches, to the exclusion of:

    1. Drawing all widgets inside a single "svg" element, annotated by
ARIA, in an HTML DOM.
    2. Mixing canvas and SVG indiscriminately inside HTML.

> diverging the discussion to another spec. is keeping people from
> focusing on the task at hand.

No, it's recognizing that the HTML WG must address accessibility for
the HTML5 platform not just canvas in particular. It is critical not to
think about canvas in isolation, since that leads to API design that is
bad from the platform perspective. For example, functionality was added
for querying the user's caret blinking preferences to the canvas context
rather than the navigator interface even in the face of early
feedback because this list is obsessively focused on the canvas context
only:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12920

The HTML WG does *not* need to solve the accessibility problems faced by
developers building applications for platforms that implement the canvas
context but do not implement HTML5, and it must especially avoid doing
so wherever that would compromise the usability of accessibility
features in the HTML platform.

Nor does the HTML WG need to solve the accessibility problems created by
developers who insist on replicating widgets in canvas that are better
expressed as normal HTML widgets or SVG in order to deliver a platform
that supports accessible application development.

It is impossible to deliver a platform that cannot be abused to create
accessibility problems. The critical thing is to make it as easy as
possible to do things right and deliver accessible experiences. I think
an opinionated platform has the same benefits as opionionated software:

http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html?page=1

Please note I am not saying we should automatically rule
out solving problems created by developers ignoring the easy way.
Motivations to solve such problems might include:

    - Companies might be willing to put people with
      disabilities out of jobs by building business applications in
      canvas, but also be willing to use accessibility features if we
      do provide them.
    - Low-level APIs might allow developers to progress the web platform
      faster, and accessibility features might allow them to take people
      with disabilities along for the ride.

But when we try to help in these situations, we have a responsibility to
consider the costs and benefits to the HTML platform in general. We
also, I think, have a responsibility to think about whether we are
solving a problem in practice or only in theory. For example, I do not
think the sub-tree approach to canvas accessibility will solve the
remote system access use-case in practice, even if it could in theory
(which is itself questionable). We should be aiming to deliver concrete
benefits to people with disabilities using the web.

--
Benjamin Hawkes-Lewis

Received on Thursday, 7 July 2011 18:52:42 UTC