Re: Solution to grammar, spelling, and

On 1/14/2011 12:02 AM, Benjamin Hawkes-Lewis wrote:
> 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?
It may be that "aria-selection" is a better title for it, I don't know. 
It's a start of a discussion.

Directionality would be inherited by the language / direction attributes.
You can always insert xml "dir" and "lang" attributes.

The anchor would be the empty <mark></mark>.
>> and in fact puts more control in the hands of cloud-based offerings
> What additional control does it provide?
A standard method of serializing selected ranges.

Consider Google's spreadsheet offering, where the current
cursor position of all members is shown on the screen. It's certainly handy,
but it's not something spec'd anywhere.


>> 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.
It may be a little easier than using DOM Ranges, from a programmers 
perspective,
but that's debatable.
> New markup seems unnecessary for this use-case since authors can
> roundtrip arbitrary data in HTML, including selection information.
They can send arbitrary data, certainly, and use microformats.

At present, there isn't one for selection. It seems there ought to be.
The examples we've been discussing are an attempt at making one.
> 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?
You've got a good point about an option role vs a hypertext role. I'm 
still exploring that myself.
> 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?
All good points.

This is an exploration, and your feedback is very much appreciated.


-Charles

Received on Friday, 14 January 2011 20:53:57 UTC