Re: Microsoft's ARIA annotations proposal

Thanks so much for the clarifications and ARIA specific proposal, Aaron.

A slight change might bring the two annotation world-views into very close
alignment: instead of inventing new "comment", "reply" and similar roles /
motivations, instead re-use the motivations defined by the Web Annotation
work as the values of the ARIA properties. It would then be very easy to
programmatically extract the very simple, embedded ARIA annotations and
express them as Web Annotations for management and creation outside of the
web page, and conversely embed content from a distributed web annotation
based platform into content. Without the re-use of the motivations, it
would be difficult to keep the two taxonomies in sync as they potentially
evolve separately.

There has also been a great deal of interest from the schema.org folks in
ensuring that JSON-LD 1.1 can reference content in the including web page
in an unambiguous way. Combined with the existing Web Annotation model
features, this would fulfill the needs expressed, as I understand them.

Thoughts?

Rob


On Fri, May 11, 2018 at 11:26 AM, Aaron Leventhal <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> 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>
>> 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>
>>> 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 <charlesl@benetech.org>
>>>> Twitter: @CLaPierreA11Y
>>>> Skype: charles_lapierre
>>>> Phone: 650-600-3301 <(650)%20600-3301>
>>>>
>>>> On May 11, 2018, at 9:50 AM, Robert Sanderson <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> 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 <(201)%20748-6884>
>>>>>
>>>>> tsiegman@wiley.com
>>>>>
>>>>>
>>>>>
>>>>> *From:* Aaron Leventhal [mailto:aleventhal@google.com]
>>>>> *Sent:* Friday, May 11, 2018 10:36 AM
>>>>> *To:* ARIA Working Group <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 forend
>>>>> 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
>>
>> Advancing the mission of digital accessibility and inclusion
>>
>


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