Also https://www.w3.org/WAI/ARIA/track/issues/670

See Response from Doug Schepers to me reqarding the formation of an Annotation Working Group pertaining to remote annoation requirements:
http://lists.w3.org/Archives/Public/public-digipub-ig/2014Jul/0030.html

https://www.w3.org/WAI/ARIA/track/actions/1454

dd aria-hasannotation attribute with values: comment, footnote, endnote, reference, insertion, deletion, modification, true, false, more where aria-hasannotation has only one value at a time

https://www.w3.org/WAI/ARIA/track/actions/1455

Add aria-annotatedby where it takes idrefs as a value and must only be applied when that same element has aria-hasannotation

https://www.w3.org/WAI/ARIA/track/actions/1456

The TR for web annotations, including commenting and highlighting:
https://www.w3.org/TR/annotation-model/

I've put an updated draft proposal on the Wiki:
https://github.com/w3c/aria/wiki/ARIA-annotations-draft-proposal
This draft incorporates comments from the F2F in Lyon.

The J Paul Getty Trust would formally object to this unless it is at least aligned with existing W3C standards for Annotation.

Hi @azaroth42. Thanks for your review and feedback. Could you please let us know what specifically you find is not in alignment and/or what you find objectionable? The ARIA Working Group would find this information helpful before proceeding. Thanks!!

I'm still catching up with the markup specifics, but one thing that would move this closer to matching the Web Annotation spec would be to change the "annotation types" listed in the draft proposal on the Wiki to match the motivations (aka purposes) listed in the Web Annotation spec.

Any missing ones could be added by this group with help from @azaroth42, myself, @iherman, @tcole3, or others who understand the format well.

Our concerns are identical to @BigBlueHat, above.

Hi @BigBlueHat and @azaroth42, thanks for the feedback.

I actually started out with the motivations linked above and even used the same wording, e.g. with "ing" at the end of each. Personally I was fine with it, but my original reviewers found it awkward to use the "ing" at the end of each, e.g. aria-annotation="commenting" or role="annotation-commenting".

It was suggested to me that we did not need to exactly duplicate the motivations, and that we just be able to map from the motivations linked above to the ARIA annotations. What do you think?

Also, I'm not really sure we really want all of of the motivations. For example, "highlighting" doesn't really necessarily contain in-page content to link to. It might be more suitable to use role="mark" or something like that. Would it be alright if we started with a subset of the motivations?

Another question I have is about footnotes, endnotes etc. What motivation would you use for that one? The DPUB roles for this are doc-footnote and doc-endnote. Therefore we decided we would like to use the role attribute in order to avoid duplication or conflicting markup.

One of the things the Web Annotation (and Open Annotation before it) works hard to do is avoid creating "annotation types" preferring, instead, a more generic and flexible model centered around targets and bodies (see the intro for more).

The danger of typing annotations it that you end up creating narrow data models specific to things which are often nearly (or sometimes exactly) identical...but with different names.

The motivation/purpose labeling system is intended to avoid restricting the data model while still giving hints about the purpose and intent expressed in the annotation. The underlying data model remains the same regardless.

This has the advantage that tools can focus on finding/selecting/presenting "targets" and displaying or linking to their "bodies" (text, images, other web pages) in relation to them.

The result is that annotation users and developers aren't forced to determine if something is a suggestion, or a comment, or a comment that's making a suggestion and describing the presence of another comment. 😁

In the end, this intention informed the choice of gerunds for motivations, so that you can have a single annotation that's "editing commenting questioning" and contains individual bodies for "tagging" and "identifying" and "editing". The data model for the target(s) and the bodies would be consistent regardless. The motivations and purposes would be used to signal different intended uses and experiences for the annotations (or the links/highlights which reference them--depending on your planned use).

The core argument being that consistent data model will scale better over time--especially when it essentially boils down to pointing at things and "talking" about them...whatever one's motivation. 😄

We don't have much of a data model, pretty much this is just a pointer somewhere else in the page with a type. But for a screen reader user, being able to navigate among all of the comments, and not get any footnotes, or vice-versa, is very useful

@BigBlueHat @azaroth42 Can you help us understand what would be satisfactory? Please keep in mind we've determined we only require a type and a pointer to visible same-page content. We're optimizing for something different than you are, it looks like.

• Do you feel we need to keep the "ing"?
• Is it important for you that ARIA support all of the motivations?

I would say ...

• At a minimum, provide a mapping from the ARIA terms to the equivalent Annotation terms, and am happy to help with that if there are any questions.
• Preferably, simply use the Annotation terms directly, given that they are a normative list, thus keeping the "-ing" form.
• Preferably also allow any of the Annotation terms rather than pre-judging which to include.
• As a nice to have, allow URIs as well as the strings for extensibility.

@aleventhal this is really interesting. I think it's great that you are working on accessible annotations, and this could have significant impact. I'm curious about the choice to superclass to structure. What are you expecting the UX to be? Are you relying on exposure of details, label, etc? Something I have been thinking about since working on DPUB-ARIA is what information is actually being covneyed to the user and/or UA if the API is really just looking at the superclass.

A word of caution from DPUB-ARIA - I have been hearing that although there is great support from the Accessibility APIs, there has not been much uptake from AT.

What are you expecting the UX to be? Are you relying on exposure of details, label, etc?

Knowing the expected or assumed UX for any of these would be helpful. Maybe this is already done somewhere I/we've not seen? (sorry...still playing catch-up here.)

Also, keeping the ing or not is less important than making sure that the two annotation systems can be intertwined successfully, easily, and clearly. The ing approach does seem to make them more clearly mixable: "commenting replying."

The ideal situation would be for groups like hypothes.is and Apache Annotator to easily express Web Annotations into accessibly annotations as well as easily extract HTML-based annotations into Web Annotations--i.e. shortening the distance between the two would helpfully mean more tooling for everyone.

@azaroth42

• At a minimum, provide a mapping from the ARIA terms to the equivalent Annotation terms, and am happy to help with that if there are any questions.

Isn't the other direction the more important one?

• Preferably, simply use the Annotation terms directly, given that they are a normative list, thus keeping the "-ing" form.

I'll bring it up at the next ARIA WG meeting. I'm fine with it, but when I proposed it originally, others didn't feel it fit with ARIA stylistically. If it helps move things forward it could be practical, but I don't think having ing or not should be a blocker as long as there is a mapping.

• Preferably also allow any of the Annotation terms rather than pre-judging which to include.

Question: what would the linked in-page content for a "highlighting" annotation?

My thoughts: I'll bring this up at the next ARIA WG meeting as well. However, for ARIA, we are specifically talking about something that links to in-page content. Basically, the user may want to navigate from comment to comment, or from commented text to commented text, as well as back and forth between the annotated content and the annotation. This UX doesn't make sense unless there is linked is in-page content.

• As a nice to have, allow URIs as well as the strings for extensibility.

I don't see how we could do this with the way screen readers, ARIA and accessibility APIs work today. Perhaps in the future if/when accessibility develops an extensibility mechanism.

@TzviyaSiegman

@aleventhal this is really interesting. I think it's great that you are working on accessible annotations, and this could have significant impact.

Thank you, hope so!

I'm curious about the choice to superclass to structure.
As the user navigates into or out of a structure, it's expected that they will be informed that they are now entering the structure or leaving it. Also, there should be a keystroke for navigating to the previous/next annotation of a certain type. This is similar to "article" but we thought it would be confusing to inherit from that. In a sense, the superclass doesn't really matter. To me the abstract roles give us a sense of order, and perhaps help with the validation model, and that's about it.

What are you expecting the UX to be?

Specifics are obviously up to the individual AT, but the general idea is:

• Announcements as user enters/leaves annotated content or an annotation
• Ability to navigate between annotations of a certain type, or annotated content with annotations of a certain type
• Ability to navigate back and forth between the current annotated content and its annotation

Are you relying on exposure of details, label, etc?

We're relying on the exposure of details, and something that describes essentially the type of details linked to. At the last ARIA WG we decided it would be better to use role, so that for footnotes, endnotes, etc. where there is already a DPUB role we could just use that and avoid redundant/conflicting markup situations.

Something I have been thinking about since working on DPUB-ARIA is what information is actually being conveyed to the user and/or UA if the API is really just looking at the superclass.

The AT can get the role as a string. We'll be working with different screen reader vendors to support whatever we come up with.

A word of caution from DPUB-ARIA - I have been hearing that although there is great support from the Accessibility APIs, there has not been much uptake from AT.

At Google we care about support for at least some of the DPUB-ARIA stuff. We'll be using it in Google Docs and asking screen reader vendors to support through our relationships.

@BigBlueHat

What are you expecting the UX to be? Are you relying on exposure of details, label, etc?
Knowing the expected or assumed UX for any of these would be helpful.

I answered this one above.

Maybe this is already done somewhere I/we've not seen? (sorry...still playing catch-up here.)

There is some support for this kind of thing in screen reader support for Microsoft Word.

Also, keeping the ing or not is less important than making sure that the two annotation systems can be intertwined successfully, easily, and clearly. The ing approach does seem to make them more clearly mixable: "commenting replying."

I see the usefulness in going from W3C annotations to ARIA, but not so much the other way around. Do you agree? Or what would be the use case or going from ARIA to W3C annotations?

The ideal situation would be for groups like hypothes.is and Apache Annotator to easily express Web Annotations into accessibly annotations as well as easily extract HTML-based annotations into Web Annotations--i.e. shortening the distance between the two would helpfully mean more tooling for everyone.

I don't really see the second one happening. If we need way to express annotations in web content and going back to the rich web annotations model, I don't think ARIA is the right choice. We call ARIA semantics but it really is more of a presentation layer for ATs. The accessibility model today doesn't even handle IRIs.

Perhaps using the same term, "annotations", is confusing things, and what we really want to do in ARIA is describe what aria-details was used for. Keeping things to these 2 properties really helps with documentation and more consistent adoption. And it's a requirement for accessibility right now to keep everything to same-page links. This is really for screen reader and perhaps magnifier support, and we really only make stuff that a sighted user would also get on the page accessible.

Reopening, because the annotations-aria proposal is deprecated. It was going to create a separate specification. The new proposal is to add markup to core ARIA and summarized here in this combo explainer/proposal:
https://github.com/aleventhal/aria-annotations/blob/master/README.md

Please put feedback for the new proposal in issue #1109

This is now landed in Chrome Canary (Chrome 81).

I filed some follow-up issues:
AOM - WICG/aom#157
Firefox - https://bugzilla.mozilla.org/show_bug.cgi?id=1608883

Updated existing WebKit bug - https://bugs.webkit.org/show_bug.cgi?id=165842

CORE-AAM doesn't need any changes, it already says there could be multiple elements.

@aleventhal requested public comment.

No concerns re: ARIA Annotations from Apple Accessibility Engineering. I'll stop short of a formal "Intent to Implement," but it's an area of interest that we hope to implement at some point in the future. Congrats on shipping it in Chrome and Firefox.

I think this can be closed as resolved.