Re: Microsoft's ARIA annotations proposal

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
>