Re: Solution to grammar, spelling, and

On Fri, Jan 7, 2011 at 12:28 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> As for selected content we simply do apply aria-selected="true" to any
> content:
>
> <mark aria-selected="true"> ... </div>
>
> The modification would be to make aria-selected an ARIA global attribute and
> address the accessibility API mapping for it. This is very straight forward.
>
> For a caret we simply have a collapsed section:
>
> <mark aria-selected="true"></mark>
>
> This is all very clean,

Is it? Seems fairly crufty as markup for a selection to me. How do you
indicate the selection anchor and direction? How do you indicate
multiple ranges?

> requires minimal impact to the existing browser implementations

How does it interact with the real cursor, selection and existing
selection APIs?

Is it supposed to supplant mapping the real cursor and selection to
accessibility APIs? Is the idea authors will keep them in sync? What
happens when they fail?

> and in fact puts more control in the hands of cloud-based offerings

What additional control does it provide?

> where they are not limited to what the browser is doing for them
> in contenteditable sections.

What limitations inside contenteditable? What limitations outside
contenteditable?

The only utility proposed for this markup so far is serialization.

New markup seems unnecessary for this use-case since authors can
roundtrip arbitrary data in HTML, including selection information.

The proposed markup seems insufficient for the use-case since it can't
describe all the relevant characteristics of a selection like
direction.

The overloading of "aria-selection" to indicate cursor selection as
well as widget state might be confusing to authors. It would be better
to mint a new element or attribute. What happens if authors sometimes
use "mark" as a distinct selectable item within a widget rather than
just an arbitrary cursor selection that could be expanded/contracted?
How are accessibility API consumers supposed to distinguish these two
cases?

Finally the proposed markup might produce confusing user interfaces.
What happens if implementations highlight "mark" elements as suggested
by the spec, or provide navigation between "mark" instances?

--
Benjamin Hawkes-Lewis

Received on Friday, 14 January 2011 08:03:12 UTC