Re: HTML 5 Canvas Accessibility Call on January 10

On Sun, Jan 16, 2011 at 5:34 PM, Charles Pritchard <chuck@jumis.com> wrote:
> 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.

Sure.

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

"black box" in what sense?

http://en.wikipedia.org/wiki/Black_box

> 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 don't understand the distinction you're making, but I think we should
discount "artificial" use cases and focus on real ones like the above.

> I'd like methods for serializing the UI-state of an RTE, per WCAG,

What WCAG requirement are you talking about? WCAG2 does not mention
serialization.

> so that, it may be restored,

As I've said before, you don't need new features to support this.

> and so that it may interface with AT.

I think there's general agreement that web RTEs should be accessible.

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

Which standard is that?

> 1. This started from technical use cases: serialization, unit testing.

Re unit testing: I cannot find the previous discussion of unit testing
in this context. Would you mind linking to it? Has anyone analyzed what
sort of things need to be unit tested, what unit testing cannot be done
at the moment, and whether the proposed features are sufficient to
enable it? Have any alternative approaches or features been considered?

Re serialization: use cases are about user needs. "Serialization" is a
feature but it's not a use case. I could say I need to serialize the
names of my cats, but that's not a use case.

http://en.wikipedia.org/wiki/Serialization

http://en.wikipedia.org/wiki/Use_case

If by "technical use case", you mean a "use case" that is not directly
tied back to meeting end-user requirements, I think we should discount
such "use cases" in order to make sure we're solving real user problems.

> The "cloud" IDE is just something to point to.

Are you saying we should ignore this use case? If so, I disagree.

Unlike serialization, it's a real case based on user requirements that
user agents might be interested in supporting, and we should consider
whether we can support it and how. And if the use case is brought
forward - however tenuously - as a rationale for introducing specific
features, we should certainly analyze whether those features address
the use case well or not.

> I really think the basics should have been sufficient.

If the "basics" were collectively recognized as sufficient, then people
would not be "pointing" to additional use cases.

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

These all sound like use cases, although obviously we'd need to
elaborate them in detail to work out what features would support them
best and how much urgency to assign to them.

Transliteration: Not sure what you mean or how the proposed features
help.

Handwriting recognition: I don't understand why we need the proposed
features for handwriting recognition.

Artificial languages: I can't see implementors treating this as a strong
motivation for adding new features. I think the web stack already
supports outputting these using a series of SVG, canvas, or img
elements.

UI for an AT solution: Not sure what you mean or how the proposed
features help.

Vector graphics editing: Given that Adobe Illustrator can output SVG,
it seems like SVG is already a great fit for this, so I don't see why
we need the new features to support this.

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

Hammer vendors have their own ideas about the purposes of hammers,
which don't include turning them into spanners.

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

I haven't heard about these difficulties. Do you have any links to
further information?

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

My sentiment does not depend on such a strong claim. I'm saying the
reasons mentioned are all better reasons to improve browser (and system)
IMEs than to require browser developers to add features for authors to
roll their own.

> One of the purposes of the scripting environment is to allow authors to
> develop alternatives.

It's a way authors use the environment, but it's inefficient to require
the diversion of development resources that would be better spent
elsewhere.

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

Authors and browser vendors are not different types of people, they are
just people (not that infrequently the same people) playing different
roles.

*You* are proposing new restrictions on people's form of expression -
that software written by other people must include X, Y, and Z features
to be conforming with a web standard. Of course, this is a fairly weak
restriction, as generally developers won't implement requirements they
feel are unreasonable. (For example, developers generally don't go out
of their way to use complex bolt-on accessibility features.)

Just because some hammer vendors won't make you a hammer that also works
as a spanner, doesn't mean you have the right to demand a hammer-spanner
from them or deny you the freedom to make your own hammer that does.

If you're not interested in writing the software to solve the problem of
enabling developers to code an RTE in canvas, that does not (in my view)
give you some sort of special ethical right to demand that other
software writers solve it for you.

We are talking about what constraints we can reasonably place upon
conforming HTML5/ARIA implementations. We cannot ultimately constrain
what developers do on the open web, so "Restricting IME to that which is
supplied ONLY by browser vendors goes against free speech" is a
strawman.

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

Today's desktop environments do not draw using Flash, so I don't see the
relevance.

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

That requires that desktop environments and their applications be
reimplemented to restrict themselves to higher level API functions that
could be sent over the wire.

I think it's more likely that in twenty years:

1) The remote desktop environment access use case will be obsoleted by
ubiquituous cloud computing.

*or*

2) People will still require remote access to desktop environments where
applications still take advantage of platform-specific low-level APIs.

If I'm wrong, then adding some extra API to HTML5 canvas to support
remote access will be the most inconsequential part of the puzzle that
needs solving to get us from where we are to where you think we could
be. Rewriting the desktop application stack and devising protocols
for transmitting instructions over the wire to express those
applications remotely even on different platforms would be the hard
parts.

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

I suspect we're going to keep disagreeing on that point. :)

> It's not reasonable to expect all app developers to have a fully
> accessible non-graphical UI to their application.

Requiring or not requiring JS and providing or not providing a fully
accessible non-graphical UI are strictly orthogonal concerns.
Non-graphical UIs may require JS; graphical-only UIs may not require JS.

If you mean there are some applications for which it is impossible to
create a fully accessible non-graphical UI, then I've yet to see an
application of which this is true, but I can believe they might exist.

I think where the technology exists to create multiple representations
of the same application flow from the same blueprint, it's not an
unreasonable user expectation. I favour expanding the parts of the web
stack that support that ability. That's not the same as saying that
users have an ethical right to *demand* such alternate representations.

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

If there's a right way to do it, that's probably it, but it still
requires bolt-on accessibility so it's still subject to the historical
lesson of Flash.

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

I think "chilled" is the wrong word to use for a situation where
hammer vendors are not keen on making the spanner you want.

> Opportunity costs are not being weighed.
>
> Proposals which cost very little are not rationally analyzed as their use
> case is labeled "Canvas RTE".

I disagree that the proposals "cost very little" and "are not being
rationally analyzed". Which is not to say that the analysis cannot be
improved.

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

I don't think the statements of individual Mozilla developers mean
there is zero room for sending in patches.

Anyway, Gecko's a FOSS code base. Disagree with a decision from on high?
Fork it.

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

Minding positive iPhone and Mac experiences enjoyed by blind
acquaintances, I disagree that's a bad thing.

http://blog.fawny.org/2010/11/25/badtastehasacost/

http://behindthecurtain.us/2010/06/12/my-first-week-with-the-iphone/

Please note: As a long-term user of *both* stacks, I also value the
ultimate freedom to DIY offered by FOSS stacks like Linux-Gnome-Orca.
I'm glad we have an ecosystem capable of supporting both types of stack,
and people working on accessibility in both stacks.

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

Sounds good to me. :)

But it's worth noting that actually Apple isn't the only company working on
AT on their platforms.

http://www.assistiveware.com/

http://www.macspeech.com/

> With other vendors, the standard vendor reply is, "well that's something
> that should be handled automatically by the UA, not by the author."

Indeed. Hammer vendors like making hammers that hit nails, rather than
hammers that require you to get the nail vendor to make their own
special attachment for your hammer in order to hammer in their brand of
nails.

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

If authors are totally sacrificing accessibility in order to use canvas,
sounds like good evidence that they either don't know what they're
doing, or don't care enough to take advantage of bolt-on accessibility
features and that if their work ever achieved web-scale importance, it
would require a flock of accessibility experts to come and redo their
work so that it's no longer broken. Ahem…

http://groups.google.com/group/jquery-a11y

http://www-03.ibm.com/able/resources/dojo.html

Built-in accessibility means that ignorant authors can still produce
accessible content and functionality, that knowledgable authors
don't end up trading in accessibility to cut development time, and
that you don't need to retrofit accessibility after corners are cut.

There are use cases where built-in accessibility seems very difficult to
achieve, such as providing audio descriptions or captions for media. I
don't think RTE is one of those use cases.

> Microsoft is generally silent, though I appreciate their growing public
> attendance.

I agree the growing involvement of Microsoft in web standards is a good
thing. :)

--
Benjamin Hawkes-Lewis

Received on Sunday, 16 January 2011 22:06:18 UTC