Re: Proposal: simple annotation semantics with aria-detailstype

 I think we need the full usecases and then work on the terms

some examples are the AUI proposals. such as aui-helptype , aui contexts and aui alternative tokens


you can look at  https://rawgit.com/w3c/personalization-semantics/master/semantics.html


and https://rawgit.com/w3c/personalization-semantics/new-format-for-help-module/help/index.html (early draft but the tokens are a good start)

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Thu, 17 May 2018 22:13:00 +0300 Aaron Leventhal<aleventhal@google.com> wrote ---- 

One wrinkle is if there are multiple detail ids.

We can address this in the spec in a couple of ways:
- specify that aria-detailstype goes on the target of the aria-details
- specify that aria-detailstype can be a space delimited set of tokens, each applying to one of the aria-details ids, in order


Aaron


On Thu, May 17, 2018 at 2:26 PM Aaron Leventhal <aleventhal@google.com> wrote:

People on the W3C call today weren't too sure about using the role on the target of aria-details, in order to specify the type of annotation. Here's an alternate proposal:


Use aria-details + optional aria-detailstype on the same element with one of the following values:
assessing, classifying, commenting, describing (default), editing, highlighting, identifying, linking, moderating, questioning, replying, tagging
These values are imported from web annotations motivation vocabulary, but ARIA can eventually add additional types such as "breakpoint" for web-based code editors.


This is still very simple to implement in browsers, AAM's and AT's. It also doesn't lead to an expansion of roles, and is more self-describing than using the role, which probably seems like ARIA black magic that only a few would know about.


Do people like it?



Aaron