W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2010

Re: html5 editor responds to Canvas accessibility related bugs

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Sun, 3 Oct 2010 18:35:15 +0100
Message-Id: <4702261C-9874-4B2D-9A5C-3FBFCE4C75B6@googlemail.com>
To: public-canvas-api@w3.org
Richard Schwerdtfeger writes:
> You know back in the late 1990s the HTML community and the accessibility
> community never envisioned that JavaScript would be used to create
> applications


The 1995 press release for JavaScript introduced it as "an open, cross-platform object scripting language for the creation and customization of applications on enterprise networks and the Internet".


The 1997 HTML 4.0 specification said that with scripts, "authors may create dynamic Web pages (e.g., 'smart forms' that react as users fill them out) and use HTML as a means to build networked applications."


Seems fairly prescient to me.

> and so they ignored the problem so much so that WCAG 1.0
> prohibited the use of technologies like script and CSS.

While WCAG 1.0 did require authors to provide webpages that work without script, it did not prohibit the use of script or CSS:


The stated rationale was not that JS should not be used to build applications, but that some software did not yet support JS or dynamic updates.

Given the convenience of being able to access content and functionality without JS, the practical difficulties developers face in producing robust JS-driven interfaces, and the ongoing struggle of user agents including assistive technology to keep pace with the evolution of clientside scripting, producing web applications that work with or without script remains sound advice today, in my view.

> I think all of us want to avoid a repeat of WCAG 1.0 technology
> restriction clauses. Every government today is in the midst of redoing all
> their accessibility legislation. It is entirely conceivable that they will
> say "do not use canvas" as it is inaccessible. I will also tell you that
> the editors public fighting to block things like longdesc and other
> accessibility features are now getting seen negatively by many very large
> IBM customers. If we continue down this path of exclusion I can see HTML 5
> being blocked by government agencies. Are you suggesting that we allow this
> to happen again?

It's consistent to argue that HTML5 should prohibit the use of "canvas" to create text editors, and accessibility legislation and guidance should follow suit. Doing so does not require prohibiting HTML5 in general, which is impractical since HTML5 standardizes currently non-standard processing and APIs on which the Web - including bluechip and government websites - already depends, since HTML5 introduces some new features that may ultimately prove more accessible than the current widgets developers hack together with DHTML and CSS, and since adoption of HTML5 features is no technical barrier to continuing to use interoperable older features even if they are non-conforming.

That said, you make a fair point that we are likely to be making plenty of incorrect assumptions about future usage. Reading the WAI archives suggests that contributors in the late 1990s thought the future would see "img" replaced by "object" and screen readers catered to with content negotiation and aural CSS. So we should pay close attention to what developers are already doing today.

I think Bespin constitutes existence proof that we need to add features to the web stack to support the creation of accessible, sophisticated text editors.

That need not involve adding text editing APIs to "canvas". Although Bespin uses "canvas", the Google Docs word processor uses the DOM, so it's not like the market has already made a clear choice.

It's worth reviewing why Bespin uses "canvas":




What we learn is that Bespin deployed "canvas" because:

    1. Native controls don't have the required feature set.
    2. "canvas" was more consistently implemented than SVG.

    3. They got better performance rendering text with "canvas" than DOM.
Including support for inline SVG in HTML5 is already fixing the second problem (see IE9); the critical question now involves speed.

If we cannot give "textarea" the features authors and users want from "canvas"-based UIs, then it won't be used instead.

If we cannot make the "contentEditable" DOM as fast as "canvas", then it won't be used instead.

If the proposed accessibility APIs for "canvas" severely impact its performance, then they won't get used.

So it would be nice to see some experimental implementations, or at least theoretical discussions, that address these critical feature and performance questions.

Benjamin Hawkes-Lewis
Received on Sunday, 3 October 2010 17:35:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:28 UTC