RE: Microsoft's ARIA annotations proposal

I think Aaron’s proposals are developing in the right direction, and I would support the more expansive list of annotation types drawn from the Web Annotation work.

I can immediately think of use cases for “highlighting”, for example, in educational applications, where something more than attribute (e.g., font) changes is desirable to cue an assistive technology, and ultimately the user, to highlighting that is essential to understanding the content.

From: Aaron Leventhal <>
Sent: Monday, May 14, 2018 1:19 PM
To: Schnabel, Stefan <>
Cc: John Foliot <>; ARIA Working Group <>; W3C PF - DPUB Joint Task Force <>; DPUB mailing list <>
Subject: Re: Microsoft's ARIA annotations proposal

I checked with Robert Sanderson offline about what he'd like to see regarding reusing the annotations spec motivations vocabulary<>. 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 text</span></p>
<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 <<>> wrote:
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 <<>>:
+1 to Aaron, and I suspect that the folks over in dPub WG would be interested and supportive of this as well.


On Fri, May 11, 2018 at 9:35 AM, Aaron Leventhal <<>> wrote:
Hello, I was reading the ARIA annotations issue<> and the linked Microsoft Position Paper on Annotations<>.

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,

John Foliot
Principal Accessibility Strategist
Deque Systems Inc.<>

Advancing the mission of digital accessibility and inclusion


This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.


Received on Monday, 14 May 2018 17:34:45 UTC