- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sun, 16 Jan 2011 10:41:44 +0000
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, public-canvas-api@w3.org, franko@microsoft.com, david.bolter@gmail.com, public-html-a11y@w3.org
On Fri, Jan 14, 2011 at 8:54 PM, Charles Pritchard <chuck@jumis.com> wrote: >> 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, Yeah, also the use of an element plus an attribute rather than an element, the bizarre aria- prefix, the fact that the attribute isn't a normal HTML boolean attribute, the fact that the same markup is being used to mean both a selection and a cursor … If you want "clean", how about native <selection> and <caret> in HTML mapping to role="selection" and role="caret" in ARIA? > It's a start of a discussion. It would be great if these discussions started with clearly stated use-cases and case studies of existing practice rather than diving straight into markup proposals. :( e.g. it would have been useful to consider the Google Spreadsheets example at the beginning, since the proposed markup doesn't seem to tackle that example at all. > Directionality would be inherited by the language / direction attributes. > You can always insert xml "dir" and "lang" attributes. That's script direction, not selection direction, which is the direction (forwards or backwards) in which selection is expanded from the initial anchor. Compare the ongoing discussion about standardizing the existing selection API's direction features: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029814.html > The anchor would be the empty <mark></mark>. Would: The cat sat <mark aria-selected="true">on the mat<mark aria-selected="true"></mark></mark> and was <mark aria-selected="true">very happy</mark>. imply a discontinuous selection with "very happy" selected, followed by "on the mat", with the cursor just after "mat"? >>> 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. What additional control does that provide? What information does it give to AT that AT *cannot* already get? What functionality does it provide to authors that authors *cannot* already access? > 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. Are you talking about indicating the cursor and selection of contributors other than the user during collaborative editing? I don't understand how this requires serialization. By "serializing" do you just mean putting information in the DOM tree or are you talking about round-tripping in markup? I think it's a plausible application for the "mark" element, but I don't see how "aria-selected" fits in at all. "aria-selected" is supposed to indicate the user's selection not other users' selections and I haven't seen anything in the proposal so far to differentiate the two. It's also unclear to me how other users' cursor operations should be mapped to system accessibility APIs, and even more importantly whether simply reporting cursor operations would be useful to the end user. I suspect that the actual functionality of visually indicating other contributors' cursor and selection is to highlight areas of the document subject to change to minimize the chance of conflicts. It's critical that new features solve actual end-user problems rather than their shadows. There might be more direct ways to solve those problems that would provide better usability than the proposed markup. Even if it is provably useful and practical to report others' cursor and selection operations, it's not obvious why this is best done by declaratively by altering the document's structure rather than programmatically with new DOM APIs. There's not much of a scriptless use-case here, since cursor and selection operations are too time-sensitive to be useful to report without JS. >> 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. Before you debate it, can you explain how the proposed feature even avoids developers having to use DOM ranges? If aria-selection were not magically synced with manual or programmatic selection by the browser altering the DOM (because doing so would seem to break the ARIA conformance rule: "WAI-ARIA processing by the user agent MUST NOT interfere with the normal operation of the built-in features of the host language"), then developers will need to use DOM ranges in order to determine where to place the "mark" elements. In which case, "mark" is multiplying interface rather than adding functionality. DOM ranges are how developers deal with carets and selection today. Methods on nodes interacting with ranges, rather than distinct nodes in the accessibility tree, are how system accessibility APIs like Microsoft UI Automation, the Apple Accessibility API, and AT-SPI deal with carets and selection today. So I think the onus is on you to prove that moving away from this common model would be workable and beneficial. >> 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. No. The proposals add to core vocabularies (HTML/ARIA), not metadata vocabularies. Nobody's stopping anyone creating a non-core vocabulary that can be pulled in via HTML's metadata features. -- Benjamin Hawkes-Lewis
Received on Sunday, 16 January 2011 10:43:19 UTC