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

On 12/12/2010 4:50 AM, Benjamin Hawkes-Lewis wrote:
> On Sat, Dec 11, 2010 at 10:06 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> 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>
>     * The meaning of "aria-selected" is undefined when used on elements
> without role "gridcell", "option", "row", or "tab".
>
> http://www.w3.org/TR/2010/WD-wai-aria-20100916/complete#aria-selected
>
> http://www.w3.org/TR/2010/WD-wai-aria-20100916/complete#propcharacteristic_usedinrole
Other ideas?

>     * What allows a "rect" element as a direct child of "canvas"? Don't
> you need an "svg" element in between?
Yes.
> http://dev.w3.org/html5/spec/the-map-element.html#svg-0
>
>     * What is the text of the "rect", that it would provide "additional
> detail that some users might need" for the inner mark?
  setCaretSelectionRect

>     * What's the utility of using "mark" and "rect" here rather than
> just manipulating the canvas rendering and the DOM selection API in
> sync? How would "mark" and "rect" interact with the native
> contenteditable selection? What would CSS ::selected and
> window.getSelection() apply to?
They provide for a standard method of state serialization, of getSelection.

They can be used within the scripting environment, to create selection 
ranges on page load,
and to save selection rages, on page unload.

I didn't intend that CSS / window selection would trigger DOM changes:
the same situation applies [somewhat] for aria-invalid="spelling|grammar".
There would a lot of unnecessary DOM updates if they were synchronized.


> https://developer.mozilla.org/en/DOM/window.getSelection
>
> http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html
>
> http://lists.w3.org/Archives/Public/www-style/2010Sep/0003.html
>
>> <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>
>      * Again, I think you're missing an "svg" element.
Agreed.
>      * Again, the meaning of "aria-selected" is undefined when used on
> elements without role "gridcell", "option", "row", or "tab".
Yup.
>      * "aria-labelledby" would be redundant if you used the normal
> "for" attribute.
Were there multiple label for=".." elements pointing to the same item, 
I'd need
decide which one is going to be my 'primary' label.

Further, formElement.labels[n] is not yet widely implemented: this is 
easier to script.

Sure, it'd be redundant, but it's not in this example, it's just abnormal.

>      * What is the text of "path" that would provide "additional detail
> that some users might need" for the "input"?
The example needs work, it's currently strained in an effort to show 
fallback mechanisms.
The idea is to show an SVG or an IMG as "clickable" fallback content.

I did not add an area tag, nor did I nest the svg for fallback; the 
example is incomplete.


The img tag might contain several "text strings" the user can choose from,
allowing them to enter text to the input box.  The svg example would be 
more complex,
and fall into the img example.

>      * Can you explain what this markup is supposed to mean? It seems
> to be a text input followed by an image with some alternate text.
> What's the path doing there? Why is the path describing a text input?
drawFocusRing

Received on Sunday, 12 December 2010 19:44:12 UTC