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

On Sun, Dec 12, 2010 at 7:43 PM, Charles Pritchard <chuck@jumis.com> wrote:
> Other ideas?

I'm really not clear what problem we're trying to solve that isn't
already solved by existing DOM APIs.

>>    * What is the text of the "rect", that it would provide "additional
>> detail that some users might need" for the inner mark?
>
>  setCaretSelectionRect

I don't follow. "aria-describedby" is supposed to refer to an element
containing some descriptive text.

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

What user problem are you solving by serializing text selection state?

If the user agent is not supposed to automatically sync selection and
markup indicating selection, what's the point of having dedicated
markup?

If you just want to snapshot selection state at a particular time, you
could extract state via the DOM APIs, serialize it to spans and data-*
attributes (or RDFa or microdata). To restore selection state, you
could adjust the selection via the DOM APIs according to what you read
out of the data-* attributes.

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

Browsers typically allow you to click on a correctly associated label
element to focus the field.

You don't get that sort of useful, expected accessibility behavior
with more generic ARIA semantics like "aria-labelledby".

>>     * 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 don't understand why SVG or "img" are required to communicate the
semantics in question.

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

Given we should avoid images of text (see WCAG 2.0 1.4.5), why would
you use an "img" rather than a "datalist"?

http://www.w3.org/TR/WCAG20/#visual-audio-contrast-text-presentation

http://dev.w3.org/html5/spec/the-button-element.html#the-datalist-element

> 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

Why do you need an SVG path for this?

Why not ditch the path and do:

<canvas>
  <label for="my-input">Entry:</label>
  <input id="my-input" list="my-list">
  <datalist id="my-list">
    <option>Option 1</option>
    <option>Option 2</option>
    <option>Option 3</option>
  </datalist>
</canvas>

then when the input element receives focus (captured via "focus"
event), sync the canvas with
yourCanvasContext.drawFocusRing(document.getElementById("my-input"),
x, y, w, h).

Why does it need to be more complicated than this?

--
Benjamin Hawkes-Lewis

Received on Monday, 13 December 2010 12:37:07 UTC