[whatwg] Canvas fallback content: IAccessible accLocation

Tab,

I do understand your position when you recommend SVG for UI and the 
vendor-level support that will/can evolve from markup
as well as [standard] retained-mode semantics.
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0184.html


My position evolved from experience.
I need a method for canvas to share path data with the browser 
accessibility API:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0187.html

I'd prefer to call it setClickableRegion(element); and I'd prefer that 
it delegates mouse events
to the canvas subdom, as well as sharing region info with the AT. I 
require it to fill out IAccessible accLocation,
the rest is just up to the editor / WG and good practices.

You have opposed the addition of such a method -- the method would 
essentially bring image map-level accessibility data to canvas uis;
currently, there is no way to inform the accessibility tree with such 
information -- image maps were ruled out, and focus management
only applies to the actively focused element.


I'm approaching this issue having put into practice, in as many ways as 
I could approach,
the WHATWG specs in building a "Web Application". The WHATWG picked up 
Canvas early,
and I feel an obligation to contribute: SVG implementations in 2007 were 
not workable;
nor was VML -- work by the WHATWG truly helped us move forward.

Thanks to large investments, RIM and Microsoft pushed SVG support 
forward in two
major browser families.  Thanks to other investments, ARIA support was 
also greatly
enhanced across browser families and ATs. Mozilla has had brought, 
though uneven,
support for SVG for some time.

So, in 2011, we have a much improved landscape for SVG, as well as a full
landscape for Canvas. And yes, I started code bases prior to 2011, when 
Canvas
was the sole interface I could use to target the market; VML too slow 
and inflexible,
SVG mostly unimplemented.

The formalism required by SVG is expensive; just as the formalism 
required by ARIA
is costly. We're supporting both, because SVG output ensures a 
standards-based
interoperable file format serialization and ARIA ensures standards-based 
interoperable
ui serialization and interaction.

The costs of building an SVG 1.x implementation are expensive, relative 
to Canvas. In the order
of a magnitude. SVG Tiny is less costly, though still more so than 
Canvas; and the
design decisions made by an SVG Tiny vendor are not something that can 
be worked-around
by additional javascript coding. As such, we are much more beholden to 
vendors
with SVG than we are with Canvas. That catches us up to present.

Presently, SVG implementations are not performant for InkML use cases. 
We are
still left with Canvas as a solution for that issue. I believe that 
Doug's proposal
to investigate a new graphics API to encompass the functionality of 
SVG+Canvas
should also integrate WebGL+InkML as well as ARIA; that's the stack we have
had to use in practice to deliver a desktop quality application 
experience with Web Apps apis.

As for general UI: CSS3 serves most of the use cases we initially used
Canvas for; and CSS3 support has really caught on in 2010/2011. Just as
with SVG, we certainly work with CSS3 -- round rectangles and gradients 
are super.
Many CSS extensions are still vendor specific.

Canvas serves most of the existing market; and while CSS3 naming and 
semantics
are fantastically useful, Canvas output gives us a level of visual 
control and compatibility
that CSS-only solutions do not. We're also able to stay away from 
vendor-specific prefixes;
using them on a case-by-case basis as a progressive enhancement.

While stand-by, eager to engage in features put forward by CSS4 and 
SVG2, we need
to complete our ARIA support of our Canvas-based UIs. The alternative,
of supporting a completely different, stripped down interface, for 
AT-users, is not
palatable. It does not fit with the concept of "universal design", nor 
of fallback content.

WHATWG has supported every accessibility interface we need, except 
accLocation.
The focus event handling of canvas fallback content, and 
scrollPathIntoView, are
immensely helpful in allowing us to meet WCAG principles. I've personally
tested NVDA, Window-Eyes, JAWS, ZoomText, Windows UI Automation and MSAA 
trees,
and the packaged support in OS X and iOS for accessibility in the browsers.

I've tested the full spectrum of HTML forms as well as some of the new 
input elements
put forward by the WHATWG. I've tested the spectrum of SVG, as well as 
off-loading
filters onto the GPU via WebGL.

And I've done all of this, because writing web apps, on the belief that 
browsers can
deliver a "native-application level" experience, is my livelihood. I'm 
writing applications,
and just as with every other API/stack, writing applications requires a 
lot of work.

I'm invested, because my income is built on my ability to deliver usable 
applications.

I'm very much invested into the Web stack, in any form that is supported;
at this point, I'm one blocking issue away from clearing up my 
accessibility testing bug list.
And so I'm putting in a great deal of effort into confronting that issue.

The proposal put forward is internally consistent, it's cost effective, it's
understandable by existing authors, there are hundreds of existing 
applications
that could use the method, and it completes the IAccessible obligations 
that vendors have to accessibility APIs.

While I understand your position on Canvas UI uses, I appeal to you, to  
understand my obligation to WCAG,
to end users, and the limits of what existing Canvas applications can 
support in practice.

Please consider the merits of allowing Canvas developers to send path 
data to assistive technology,
on their own. I believe they are worthwhile; we are talking simply, 
about setClickableRegion(element) sending
an event, with current method, and the element parameter, to the browser 
vendor's accessibility API.

That's what I've been pushing hard for, for the past few months, and 
that completes the list of issues
I've encountered, from the past four years.


-Charles

Received on Thursday, 28 July 2011 16:06:50 UTC