W3C home > Mailing lists > Public > public-html-a11y@w3.org > December 2010

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

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 10 Dec 2010 15:50:30 -0600
To: public-canvas-api@w3.org
Cc: public-html-a11y@w3.org
Message-ID: <OF50FA7B53.925DF384-ON862577F5.0077585E-862577F5.0077FBCA@us.ibm.com>

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

Received on Friday, 10 December 2010 21:51:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:49 UTC