W3C home > Mailing lists > Public > public-aria@w3.org > May 2018

Re: Microsoft's ARIA annotations proposal

From: Aaron Leventhal <aleventhal@google.com>
Date: Mon, 14 May 2018 13:18:35 -0400
Message-ID: <CA+1LECS5DyrML08QhzpHipEbHX86+dSk5W5fpP6xM4vRtrdPBw@mail.gmail.com>
To: "Schnabel, Stefan" <stefan.schnabel@sap.com>
Cc: John Foliot <john.foliot@deque.com>, ARIA Working Group <public-aria@w3.org>, W3C PF - DPUB Joint Task Force <public-dpub-aria@w3.org>, DPUB mailing list <public-digipub-ig@w3.org>
I checked with Robert Sanderson offline about what he'd like to see
regarding reusing the annotations spec motivations vocabulary
<https://www.w3.org/TR/annotation-vocab/#named-individuals>. The idea is to
use the existing motivations, which are: assessing, classifying,
commenting, describing, editing, highlighting, identifying, linking,
moderating, questioning, replying, tagging.

So, example ARIA markup might be:
<p>Here is some <span aria-details="comment-thread-1"
aria-detailsmotive="commenting">commented text</span></p>
Alternatively, in order to avoid adding yet another new ARIA property, we
use a prefixed role on the target annotation, like this:
<p>Here is some <span aria-details="comment-thread-1">commented
<div id="comment-thread-1" role="annotation-commenting">Comment 1...</div>

A second benefit of using the role attribute for the annotation type is
that users could navigate by annotation type, e.g. discover comments first,
and follow the reverse relation back to the text.
A third benefit of using the role attribute is that we do not have to deal
with the additional complexity of specifying multiple motives when there
are multiple details (aria-details is a space-separated list of ids).

This would not cover all of the code editing use cases requested by
Microsoft, e.g. conditional breakpoints. However, we do have the
flexibility of dealing with those separately.

As far as the use cases Microsoft pointed out about spelling and grammar
errors, those are already covered by aria-invalid="spelling" | "grammar" --
no additional annotation markup is necessary.

This is all food for thought. I look forward to discussing it further.


On Sun, May 13, 2018 at 4:58 AM Schnabel, Stefan <stefan.schnabel@sap.com>

> I highly second that proposal. Expecting MS to support it in UIA for Win
> 10 Fall release 2018 ;)
> - Stefan
> Von meinem iPad gesendet
> Am 11.05.2018 um 17:37 schrieb John Foliot <john.foliot@deque.com>:
> +1 to Aaron, and I suspect that the folks over in dPub WG would be
> interested and supportive of this as well.
> JF
> On Fri, May 11, 2018 at 9:35 AM, Aaron Leventhal <aleventhal@google.com>
> wrote:
>> Hello, I was reading the ARIA annotations issue
>> <https://github.com/w3c/aria/issues/749> and the linked Microsoft
>> Position Paper on Annotations
>> <https://www.w3.org/2014/04/annotation/submissions/Microsoft_Position_Paper_on_Annotations.pdf>.
>> All I can say is, yes, we need this. With perhaps a few minor tweaks, the
>> proposal is already pretty solid. It would solve a lot of real problems in
>> group document editors. This would be very helpful for end users.
>> I'd like to see annotations sooner than the 1.4 time frame, and look
>> forward to implementing in Chrome, and working with platform API specs and
>> AT vendors as well.
>> I propose we get this on the agenda for an upcoming meeting.
>> Thank you,
>> Aaron
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
> Advancing the mission of digital accessibility and inclusion
Received on Monday, 14 May 2018 17:19:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 14 May 2018 17:19:15 UTC