Re: Fw: Action 92: Accessible Rich Text editing for <canvas> proposed alternative to native contenteditable APIs

On Fri, Dec 10, 2010 at 9:50 PM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> On the call I was asked to float a proposal to look at and evaluate. Here is
> a rough high level proposal.
> It is essential for ah author to be able to access caret location, selection
> information, spelling errors, and grammatical errors detected in a canvas
> application in such a way that they may be exposed to platform accessibility
> services via the <canvas> shadow DOM and synchronized with the visual
> rendering on a canvas rendering of that shadow DOM. Currently:
>
> - Caret and selection can be detected from contenteditable areas and from
> input controls
> - spelling and grammatical errors can not
>
> This results is an incomplete one to one mapping between the shadow DOM and
> what is rendered on the canvas.
>
> I would like to propose introducing the following HTML elements to the
> <canvas> shadow DOM that would allow the author to specify their own
> <caret>, <selection>, <grammar>, <spelling> tag ranges. This information can
> be used by the shadow DOM to support platform accessibility API services and
> be use to bind a canvas rendering of this information to information in the
> shadow DOM. This allows for a cloud based offering to completely manage rich
> text editing without impacting contenteditable sections in the browser and
> exposing similar information through scripting APIs. It will be the task of
> the author to handle the canvas display mapping. This approach is not unlike
> the use of <font> elements in earlier versions of HTML but is limited to
> <canvas>.

I don't understand how the proposal helps.

Given that the bounds of the selection and the position of the caret
within contenteditable are already available to and modifiable by
script, such that authors can manually update the canvas accordingly,
how would new "caret" and "selection" elements help synchronize with
the visual display in canvas?

User agents do not currently expose spelling/grammar errors detected
by the UA to script, but authors can use the "spellcheck" attribute to
disable such platform services and substitute their own checking, e.g.
based on a webservice.

Spelling and grammar errors in contenteditable detectable by the web
application can already be enclosed with the "mark" element decorated
with the "aria-invalid" attribute.

http://dev.w3.org/html5/spec/text-level-semantics.html#the-mark-element

http://www.w3.org/TR/2009/WD-wai-aria-20091215/complete#aria-invalid

Authors can manually update the canvas rendering to mimic spelling and
grammar errors identified in this way.

"spelling" and "grammar" elements could provide an HTML-native
analogue to "aria-invalid" but how would they provide new abilities to
synchronise canvas and the sub-DOM?

--
Benjamin Hawkes-Lewis

Received on Saturday, 11 December 2010 14:35:44 UTC