W3C home > Mailing lists > Public > public-aria@w3.org > May 2018

Re: Proposal: simple annotation semantics with aria-detailstype

From: lisa.seeman <lisa.seeman@zoho.com>
Date: Thu, 24 May 2018 13:59:10 +0300
To: "Alexander Surkov" <surkov.alexander@gmail.com>
Cc: "Aaron Leventhal" <aleventhal@google.com>, "James Nurthen" <nurthen@adobe.com>, "ARIA Working Group" <public-aria@w3.org>
Message-Id: <16391cb9be4.105131028244799.4054851459809612902@zoho.com>
This is very similar to that we are proposing for personlization for help and helpType (with helpType being on the help information)



But I still think this is too overloaded. It is much more useful to have separate attributes for separate things. 



for example: aui-help and aui-helpType



In the personlization task force we started with  one item for aria-context. We ran into implementation problems as it was ambiguous and use agents did not know how to handle the personlization. For example, help can be a call out box, a link to a help page or the page itself. Rather then having ridiculously long values we broke up the attribute name (now aui-destination, aui-field etc)



Having one attribute for a lot of things is a bit hard on implementations. we could have an base class of aria-details and derive the types we need from there



As there is a huge overlap with the peronalization task force should this be done as a joint effort? see  https://rawgit.com/w3c/personalization-semantics/master/semantics.html



please look again at the personlization modules. this is exactly the kine of use case we are talking about and having two solutions makes no sense. 




All the best



Lisa Seeman



LinkedIn, Twitter








---- On Wed, 23 May 2018 20:46:13 +0300 Alexander Surkov &lt;surkov.alexander@gmail.com&gt; wrote ----




Nevertheless, multiple aria-details relations of different types seems like a valid use case with me. It might nice to have some syntax to annotate relations, for example, something like, aria-details="ID1:type ID2:type".



On Thu, May 17, 2018 at 4:57 PM, Aaron Leventhal &lt;aleventhal@google.com&gt; wrote:






James, thanks! How did I miss that :) Certainly makes that problem easy.



Aaron




On Thu, May 17, 2018 at 4:32 PM James Nurthen &lt;nurthen@adobe.com&gt; wrote:

Aria-details only allows a single id reference.

 

James Nurthen  |  Accessibility Engineer  |  Adobe  |  p. 415.832.2734  |  c. 415.987.1918  |  nurthen@adobe.com

 


 

 

From: Aaron Leventhal &lt;aleventhal@google.com&gt;
 Date: Thursday, May 17, 2018 at 12:14 PM
 To: ARIA Working Group &lt;public-aria@w3.org&gt;
 Subject: Re: Proposal: simple annotation semantics with aria-detailstype
 Resent-From: &lt;public-aria@w3.org&gt;
 Resent-Date: Thursday, May 17, 2018 at 12:13 PM



 


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 &lt;aleventhal@google.com&gt; 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
Received on Thursday, 24 May 2018 10:59:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 24 May 2018 10:59:49 UTC