Re: Microsoft's ARIA annotations proposal

The DIAGRAM Center and DAISY have used aria-details pointing to html summary/details and to doc-footnotes in a extended image description test book that we will be testing with over 50 volunteers on various reading systems and AT/Platform combinations the results of which will go into epubtest.org<http://epubtest.org>.  We are putting the final touches on the book itself and once that is done I will share this test book with you all to see how are are using the various techniques to see which work best with existing reading systems and what we can promote to publishers now.  Using annotations for extended image descriptions would be an ideal solution assuming it is easy for everyone to use without a lot of complicated steps to get to/from the associated content.


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



On May 11, 2018, at 11:26 AM, Aaron Leventhal <aleventhal@google.com<mailto:aleventhal@google.com>> wrote:

I've attached my alternate proposal. In a nutshell, it proposes to:

- Use aria-details to link to in-page visible annotations. The linked to object can contain a semantic role that would be useful for Braille display views, e.g. if the screen reader wants to put something like *ct wherever a comment exists, or *ft for a footnote.
- Utilize DPub roles on the annotation element where useful, e.g. role="doc-footnote"
- Add a couple of new roles, "comment-section" (perhaps inheriting from complementary or tree view since it can have replies to replies etc.) and "comment".
- Until new roles are added, utilize the multiple role fallback mechanism, e.g. role="x-comment-section complementary" and aria-roledescription="Comment section".

This would add no new markup other than a couple of useful roles, and thus require very few or no changes to browsers and platform APIs (yay!) thus saving potentially years waiting to get this done. We could begin putting the markup in and asking screen reader vendors to support right away.

Note that aria-details did not exist at the time of the Microsoft proposal.

Aaron


On Fri, May 11, 2018 at 2:04 PM John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote:
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[https://ssl.gstatic.com/bt/C3341AA7A1A076756462EE2E5CD71C11/1x/btw_ic_enter_full_screen_white_18dp.png]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
<Annotations proposal using existing markup.html>