- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Fri, 14 Jan 2011 08:02:38 +0000
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: public-canvas-api@w3.org, franko@microsoft.com, david.bolter@gmail.com, Charles Pritchard <chuck@jumis.com>, public-html-a11y@w3.org
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:04:13 UTC