FW: ARIA annotations open issues

Forwarding for Chris.  Please reply all so that he stays on the thread.

From: Christopher Gallello <cgallell@microsoft.com<mailto:cgallell@microsoft.com>>
Date: Wednesday, May 7, 2014 at 10:10 AM
To: "public-pfwg@w3.org<mailto:public-pfwg@w3.org>" <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>
Subject: ARIA annotations open issues

Hi all,

Thank you for all of your great input on the annotations work on Monday. It's great to get this feedback as we continue to improve this proposal into a draft. Below are recommendations made during the phone call that differ from the current proposal document<http://www.w3.org/2014/04/annotation/submissions/Microsoft_Position_Paper_on_Annotations.pdf>. Please jump in and add your thoughts inline or additional recommendations so we can move forward with a resolution for each issue/recommendation. Also please add any recommendations/open issues that I may have missed.

Thanks,
Chris

Localized roles instead of aria-annotationtype
Rather than creating a new construct, we should leverage the localized role work that is currently under development. For annotations, we would use role="annotation" and allow the developer to specify a localized annotation type if desired.

Tokenized list for aria-annotationtype
Rather than using a localized string, use a tokenized list for aria-annotationtype. This as a few benefits:

*         Allows for multiple annotations on a single element. For example, aria-annotationtype="comment additionalnote" can be identified if comment and additionalnote are known annotations, whereas aria-annotationtype="Comment Additional Note" might be comprehended as three separate annotations if they are localized strings.

*         Allows ATs to build verbosity switches at the individual annotation type level so that users can customize their experience. In the case of localized strings, ATs would not be able to reliably build switches for different annotation types.

One of the limitations of a tokenized list is the future proofing. We never know what kind of annotations we'll want to create in the future. To account for this, a recommendation was made to allow for vendor prefixed tags, similar to aria-invalid.
Place aria-annotationtype on the annotation, not the annotated element
aria-annotationtype (or localized role if we decide to go that route) should be placed on the annotation, so that it is marked up with the appropriate role

Remove aria-annotationfor
Similar to aria-flowto, annotations do not need two way references. Rather than keeping aria-annotationfor, we should make it easier for web developers to implement annotations by keeping aria-annotatedby. It would be up to the browser/AT to establish the two way relationship based on the value in aria-annotatedby.

The Internet Explorer team has expressed some concerns for this in the past, and they were forced to create ms-aria-flowfrom<http://msdn.microsoft.com/en-us/library/windows/apps/hh969157.aspx>. I will follow up on what their exact concerns were to see if those concerns apply to this scenario (meeting with them on Thursday). Firefox was able to implement aria-flowto just fine.
Accounting for annotations that aren't in the DOM
For a variety of reasons, there will be times when annotations aren't loaded into the DOM, but users should still be able to understand that elements are annotated.

Action to load annotations
There should be a way for the screen reader to ask the website to load the annotation if hidden through some new protocol. IndieUI is one possible option here.

Invalid ID reference
In the proposal, aria-annotationfor and aria-annotatedby should have a value of an ID reference list. However, if an ID being referenced is not being loaded in the DOM, HTML validators will fail because the reference cannot be found. One solution to this is to keep the annotation in the DOM at all times, but hide it from the screen reader using aria-hidden.  Alternatively, it would be good to have a way to indicate that the ID reference will be
Overlapping annotations
Rather than using nested spans to account for overlapping annotations, we should use aria-annotationtype as a list of tokens and aria-annotationfor as an ID reference list to allow for multiple annotations and annotation types on a single span. For example:

<span aria-annotationtype="comment" aria-annotationfor="comment1" id="commented">
The big brown duck
</span>
<spanaria-annotationtype="comment reference" aria-annotationfor="comment1 reference1" id="overlapping">
lazily jumped
</span>
<span aria-annotationtype="reference" id="referenced">>
over the dog
</span>


The screen reader should be able to connect the dots that there are two sibling elements that both contain a reference to the same annotation element, and thus read it out as one annotation (so despite there being three spans in the example above, the screen reader exposes two annotations to the user). This approach requires aria-annotationtype to be a tokenized list rather than a localized string.

One issue with this approach is that the screen reader is not able to determine which
Spelling
Instead of using aria-annotationtype="spelling", aria-invalid="spelling" should be used. Currently, the ARIA 1.0 recommendation lists aria-invalid<http://www.w3.org/TR/wai-aria/states_and_properties#aria-invalid> as being a state that should be used on form fields. This should be generalized in the future to be extensible to other element types and supported within contenteditables. ATs may also need a push to announce aria-invalid on other content types or within contenteditables.