Re: Microsoft's ARIA annotations proposal

+1 to not adding additional ARIA attributes.

DPUB’s doc-noteref<https://www.w3.org/TR/dpub-aria-1.0/#doc-noteref> and doc-backlink<https://www.w3.org/TR/dpub-aria-1.0/#doc-backlink> seem to accommodate a single generic reference to an annotation (note), and then a link back to the reference in a very similar way to that proposal. There’s also doc-biblioref<https://www.w3.org/TR/dpub-aria-1.0/#doc-biblioentry> and doc-glossref<https://www.w3.org/TR/dpub-aria-1.0/#doc-glossref> for more specific types of annotations. This is actually exactly how I’ve been prototyping accessibility for annotations in our publications—both for annotations authored by the publisher (e.g., footnotes) and annotations authored by the user.

The downside to the DPUB roles compared to the Microsoft proposal is that they don’t accommodate multiple ids, and the examples are idiomatic of print publishing (e.g., footnotes, endnotes, superscripts, etc.). I would prefer a model that uses something like the annotation-model motivation and purpose<https://www.w3.org/TR/annotation-model/#motivation-and-purpose> semantics—whether it’s a footnote or endnote isn’t as useful to the user as whether it’s commenting or replying.

Evan


Evan Yamanishi
Accessibility Lead
Co-Director of the Norton Lab
W. W. Norton & Company


From: John Foliot <john.foliot@deque.com>
Date: Friday, May 11, 2018 at 2:05 PM
To: Aaron Leventhal <aleventhal@google.com>
Cc: Charles LaPierre <charlesl@benetech.org>, Robert Sanderson <azaroth42@gmail.com>, Tzviya - Hoboken Siegman <tsiegman@wiley.com>, ARIA Working Group <public-aria@w3.org>, public-personalization-tf <public-personalization-tf@w3.org>
Subject: Re: Microsoft's ARIA annotations proposal
Resent-From: <public-aria@w3.org>
Resent-Date: Friday, May 11, 2018 at 2:04 PM

Aaron wrote:

> Personally, I would prefer utilizing existing ARIA attributes or adding 1-2 new ones...

A HUGE +1.

I am increasingly concerned about the movement towards adding more and more ARIA attributes to an already long list that many, if not most, content authors are not fully aware of.

We sort of get away with this when it comes to accessible widgets, as most code libraries today have ARIA baked into the mix, and the majority of developers get their ARIA mark-up "for free" when they use those libraries. But the number of developers I know who can competently include sophisticated aria mark-up to their scripted widgets is but a small percentage of those that I know.

Yes, most mainstream devs will understand and use things like aria-labelledby [sic], but I would wonder aloud how many developers that attended Google IO this week could properly explain aria-owns or aria-flowto (my bet? less than 20%), and overloading the ARIA spec with attributes that will need to be hand-authored into the *content* (as opposed to the widgets) will continue to add a heavy lift on the authors, who traditionally will avoid complexity whenever they can. The Personalization Task Force (for example) is contemplating adding an additional 30+ new author-supplied attributes (as either aria-* attributes or aui-* attributes) that I fear will be routinely ignored due to author burden, so anything we can do to reduce that burden and re-use existing constructs gets a huge vote of support from me.

JF

On Fri, May 11, 2018 at 12:36 PM, Aaron Leventhal <aleventhal@google.com<mailto:aleventhal@google.com>> wrote:
Hi, thanks for linking into the Web Annotation Data Model spec.

Just to clarify, we're looking for ARIA or other markup to describe simple in-page annotations to a piece of text. In order to do this, we really only need two things: 1) to allow an element to point to the related annotation ids, and 2) be able to describe the type of the annotation.

We could look at utilizing the Web Annotation Data Model, but it seems to provide a lot more than what we need. For example, it allows hooking external sources of data, which we don't want. It utilizes a lot of structure, and has a markup model that does not match neatly to ARIA.

In the interests of not reinventing the wheel, and keeping things simple, I do have a alternate proposal that builds off Microsoft's ideas, but makes implementation easy by mostly leveraging existing markup and code. Personally, I would prefer utilizing existing ARIA attributes or adding 1-2 new ones or adding JSON parsing into the mix of how we expose editable content to screen readers.

This is just my 2 cents. It is all worthy of discussion and I don't mean to stomp on anyone's ideas if they really think the Web Annotation Data Model is the right way to handle things like comments and code editor breakpoints. I'd like to see an example of how it would work.

Let's get this on the agenda. I have a feeling we are closer than we think.

Aaron

On Fri, May 11, 2018 at 1:19 PM Charles LaPierre <charlesl@benetech.org<mailto:charlesl@benetech.org>> wrote:
Also just FYI there will be an iAnnotate<http://iannotate.org> Conference in San Francisco June 6&7.

Thanks
EOM


Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org<mailto:charlesl@benetech.org>
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301<tel:(650)%20600-3301>


On May 11, 2018, at 9:50 AM, Robert Sanderson <azaroth42@gmail.com<mailto:azaroth42@gmail.com>> wrote:


Dear all,

As former co-chair and editor of those specifications, I'm very happy to answer questions about the the Web Annotation work.  Reading the position paper from Microsoft, I don't see anything that cannot be accommodated. Microsoft even hosted one of the Annotation WG outreach events in Berlin, in 2016, for which we were and remain very grateful.

Kindest regards,

Rob Sanderson



On Fri, May 11, 2018 at 9:31 AM, Siegman, Tzviya - Hoboken <tsiegman@wiley.com<mailto:tsiegman@wiley.com>> wrote:
I just want to make sure this group is familiar with W3C’s Web Annotation Data Model https://www.w3.org/TR/annotation-model/. I’ve copied Rob Sanderson who helped author it.


Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884<tel:(201)%20748-6884>
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Aaron Leventhal [mailto:aleventhal@google.com<mailto:aleventhal@google.com>]
Sent: Friday, May 11, 2018 10:36 AM
To: ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Microsoft's ARIA annotations proposal

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







--
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049




--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion