W3C home > Mailing lists > Public > public-canvas-api@w3.org > January to March 2011

Re: HTML 5 Canvas Accessibility Call on January 10

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 17 Jan 2011 18:55:48 -0800
Message-ID: <4D350134.2070205@jumis.com>
To: Frank Olivier <Frank.Olivier@microsoft.com>
CC: Richard Schwerdtfeger <schwer@us.ibm.com>, Shawn Warren <swarren@aisquared.com>, Tim Lalor <tlalor@aisquared.com>, "janina@rednote.net" <janina@rednote.net>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "david.bolter@gmail.com" <david.bolter@gmail.com>, Cynthia Shelly <cyns@microsoft.com>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "oedipus@hicom.net" <oedipus@hicom.net>
On 1/10/2011 7:15 AM, Frank Olivier wrote:
> At this point, the IE team does not think that text editing via canvas 
> is a problem that we should tackle for HTML5 due to the inherent 
> complexities of the problem and limited options to solve this 
> correctly. The best solution for HTML5 (via tooling, education, author 
> guidance) is to not fake text entry via canvas elements – much better 
> native mechanisms for text editing already exist in HTML5.

I've hit this e-mail a couple of times, sorry about that. There's 
another bit of information I need to run by you all:
The Canvas Spec, CRC2D, was moved into its own specification, apart from 
HTML5, I believe by request of Adobe.

I want to bring that up, in contrast to statements about the relevance 
of HTML5 in decision making on canvas accessibility.
HTML-A11Y is a facilitator of the discussion: we've heard other use cases.

I've produced a few libraries supporting a Canvas + JavaScript profile.
They fall within w3c standards, and are independent of HTML5 browsers.

I realize that by-and-large, the process is driven by browser vendors, 
and so HTML5 is assumed. That's fine,
but procedurally, I believe that Canvas Rendering Context 2D exists 
outside of the HTML5 standard.

In that light, the Caret interface being discussed is warranted, as a 
Canvas method.

I understand that caret is widely, commonly (though not exclusively) 
used for text editing, and in other cases,
text selection. I've put forward Google Books [scanned documents] as a 
use case where text selection and a caret would be quite helpful.

But that use case is about exposing caret control to the scripting 
environment, and could just as well apply to "window".

That's why I'm bringing up Canvas Rendering Context as a separate spec 
from HTML5;
because in that light, caret control should be exposed through the 
Canvas Context object,
regardless of any other places it may be exposed in the DOM.

Received on Tuesday, 18 January 2011 02:55:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:52 UTC