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

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

From: Charles Pritchard <chuck@jumis.com>
Date: Sat, 11 Dec 2010 14:06:32 -0800
Message-ID: <4D03F5E8.4030803@jumis.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
CC: public-canvas-api@w3.org, public-html-a11y@w3.org
On 12/10/2010 1:50 PM, Richard Schwerdtfeger 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>.
> Rich

When discussing <spelling> / <grammar> tags, I was unaware that the use 
case is covered by aria-invalid="[spelling|grammar]".
Bug reports can be filed with vendors who have not yet supported those 

aria-selected seems to work for caret position, and aria-describedby to 
reference path data.

I don't understand what you mean about "[not] impacting contenteditable 

Let me know if these are an appropriate use of ARIA:

<rect id="caretRect">...</rect>
<div contenteditable aria-multiselectable>
<mark aria-selected>selected tex<mark aria-selected 

<label id="lbl">example entry</label>
<input id="entry" aria-selected tabindex=".." type="text" 
aria-labelledby="lbl" aria-describedby="focusPath">
<path id="focusPath">...</path>
<img aria-describedby="entry" src="poster.png" alt="static fallback">

I've tried to maintain data (ranges, focus areas) and allow the fallback 
content to work in a static setting.
I have not tested these examples, they're just meant to further the 
Received on Saturday, 11 December 2010 22:07:03 UTC

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