Re: HTML 5 Canvas Accessibility Call on January 10

On 1/16/2011 8:35 AM, Benjamin Hawkes-Lewis wrote:
> 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.
Fine with that: provided the opportunity cost is actually analyzed.
As you know, I'm a big fan of serialization.

Currently, contentEditable is something of a black box, with a few 
features thrown
in, borrowed from Microsoft's early work on the feature.

As for canvas-specific: there are a few details that should be addressed,
and they are, via drawFocusRing, blink rate and the caret selection command.

Beyond that, I think the defects are in contenteditable, existing html 
form elements,
and some parts of viewport handling.
> 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).
Yes, some of the use cases are a little artificial, as my original 
intent was more technical:
I'd like methods for serializing the UI-state of an RTE, per WCAG, so 
that it may be restored,
and so that it may interface with AT.

I'd like the RTE to work to the standard that users expect.

1. This started from technical use cases: serialization, unit testing.
The "cloud" IDE is just something to point to.
I really think the basics should have been sufficient.

2. Enabling authors to develop rich text alternatives. Yes, it may be 
for transliteration,
it could be for handwriting recognition -- it could be for an artificial 
language, or it
could be a UI for an AT solution. It could also be for design: think 
Adobe Illustrator,
where the user can edit text in place.

Those two categories usually meet enthusiastic support. Programmability, 
serialization.

There's a dark cloud hanging over Canvas text support.

I've brought up legibility, to Mozilla, and been denied.
I've brought up text alignment (putting two fonts on the same baseline), 
and been denied.

It's a miracle that the Shadow DOM ( drawFocusRing ) was allowed through.
That said, WebKit is still lagging on allowing focus to elements in the 
shadow DOM.
Chromium developers are having broad issues with JAWS, with 
"non-focusable" elements.

> 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
There's a basic fallacy in that sentiment: that all IMEs should be 
written directly in the browser.
One of the purposes of the scripting environment is to allow authors to 
develop alternatives.

I've said it many many times -- language is not static, and programming 
is a form of expression.

Restricting IME to that which is supplied ONLY by browser vendors goes 
against free speech.

Fortunately, things have not devolved to that point. More work is being 
done to extend
DOM events. inputLocale is actually being discussed. That's a positive sign.

I'm still trying to eek-out additional APIs.

> 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.
Yes, current remote desktop environments use pixels.

There are some basic implementations of Flash using Canvas: they provide
something of a demonstration of using an API, instead of pixels, for 
display.

It's certainly possible to hook into higher level API functions, and send
those function calls over the wire, and implement them in Canvas.

I've implemented Canvas atop several APIs. It's certainly possible to 
implement
those APIs in Canvas.

> 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.

WebApps have a very different use case than hypertext. It's not 
reasonable to expect
all app developers to have a fully accessible non-graphical UI to their 
application.

Still.. it's a nice goal to have.

I certainly recommend using standard HTML semantics and fallback content 
whenever possible.

Even in our image editor, we're finding ways to accompany our UI with 
hypertext cues.

> 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
This isn't an either-or situation.
It makes a lot of sense to use HTML specs in Canvas RTEs.
Richard's Checkbox example uses actual checkbox elements.

Canvas based HTML Forms use HTML elements, per the specs.

This is [if I'm not going to far], the right way to do a canvas RTE:
<canvas><div contentEditable>Editable Content</div></canvas>

The issue at hand, is that it can not be discussed, without being 
chilled by authority figures who have
no experience nor stake in the matter.

Opportunity costs are not being weighed.

Proposals which cost very little are not rationally analyzed as their 
use case is labeled "Canvas RTE".

When a browser vendor like Mozilla outright states that things have been 
obfuscated, intentionally,
it means there's Zero room for sending in patches to fix the issue, and 
there's little room with
other browser vendors, to move the issue forward, as they'd really like 
to see a shared standard.

>> 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.
We've got good buy-in through DOM + ARIA.
We're looking at deficiencies there.

And we're looking at a few deficiencies in the Canvas spec, which hinder 
accessibility.

>> 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. :)

Bad style to complain... but still... Apple has been absurd in this area.
They control their stack, from top to bottom.

Whenever AT is brought up, the answer is, "we already have it in our OS".

With other vendors, the standard vendor reply is, "well that's something 
that should be handled automatically by the UA, not by the author."
I've been told, repeatedly, that authors don't know what they're doing, 
so vendors can't expose additional APIs. Even at the cost of a11y.

There's a very difficult atmosphere working with Mozilla and Apple: 
they've got some boundary issues.
Microsoft is generally silent, though I appreciate their growing public 
attendance.

-Charles

Received on Sunday, 16 January 2011 17:34:52 UTC