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

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

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

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

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

<canvas>
<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">
</canvas>

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