[whatwg] Canvas fallback content: IAccessible accLocation
chuck at jumis.com
Thu Jul 28 16:06:50 PDT 2011
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.
My position evolved from experience.
I need a method for canvas to share path data with the browser
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
and I feel an obligation to contribute: SVG implementations in 2007 were
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
enhanced across browser families and ATs. Mozilla has had brought,
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
was the sole interface I could use to target the market; VML too slow
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
interoperable file format serialization and ARIA ensures standards-based
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
with SVG than we are with Canvas. That catches us up to present.
Presently, SVG implementations are not performant for InkML use cases.
still left with Canvas as a solution for that issue. I believe that
to investigate a new graphics API to encompass the functionality of
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
Many CSS extensions are still vendor specific.
Canvas serves most of the existing market; and while CSS3 naming and
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
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
The focus event handling of canvas fallback content, and
immensely helpful in allowing us to meet WCAG principles. I've personally
tested NVDA, Window-Eyes, JAWS, ZoomText, Windows UI Automation and MSAA
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
put forward by the WHATWG. I've tested the spectrum of SVG, as well as
filters onto the GPU via WebGL.
And I've done all of this, because writing web apps, on the belief that
deliver a "native-application level" experience, is my livelihood. I'm
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
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
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.
More information about the whatwg