Re: Solution to grammar, spelling, and

Rich Schwerdtfeger
CTO Accessibility Software Group

public-canvas-api-request@w3.org wrote on 01/16/2011 04:41:44 AM:

> From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
> To: Charles Pritchard <chuck@jumis.com>
> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, public-canvas-
> api@w3.org, franko@microsoft.com, david.bolter@gmail.com, public-
> html-a11y@w3.org
> Date: 01/16/2011 04:49 AM
> Subject: Re: Solution to grammar, spelling, and
> Sent by: public-canvas-api-request@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.
>

aria-selected makes no claims as to who selected something. However, I
think all of us
would be just has happy to have <selection> and <caret> elements in HTML
vs.
<mark aria-selected="true">... </mark>

We were just trying to minimize the impact to the spec by adding yet
another set of elements to a spec that is already loaded with them.
Browsers are already implementing aria-invalid="grammar" and
aria-invalid="spelling". Also, a collapsed <mark> is not much different
than an a collapsed selection in the script apis.


> 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.
>
Our problem with this approach is that HTML WG members refused to expand
the APIs on contenteditable sections for spelling and grammar because they
were concerned about security and privacy issues related to
contenteditable. We are offering an alternative.

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