Re: FW: ARIA annotations open issues

To be clear, aria-invalid is not limited to form elements. It is already a
global aria attribute:
http://www.w3.org/TR/wai-aria/states_and_properties#global_states


It is currently used to successfully mark grammar and spelling errors. In
the FF implementation this results in text properties mapped through the
accessibility APIs. So, an AT can detect errors at the character level.
This works extremely well in JAWS. I should not that the same API mappings
occur when the firefox grammar and spell checkers are running. No ID
references are required for this particular annotation.

So, aria-invalid already meets your needs for part of what you are
proposing.

We should not have both annnotation for and by as the author could mess
this up. This was discussed at the meeting we had.

If the annotation being referenced is not in the DOM the container should
be at least even though it is hidden. We have introduced localized role
descriptions for specific elements. This would allow us to have us to have
multiple annotations of different types. It would require us to think about
platform accessibility API mappings.

I agree we should look to IndieUi to address loading of annotations.

Cheers,
Rich




Rich Schwerdtfeger



From: Cynthia Shelly <cyns@microsoft.com>
To: "public-pfwg@w3.org" <public-pfwg@w3.org>, Christopher Gallello
            <cgallell@microsoft.com>
Date: 05/08/2014 02:56 PM
Subject: FW: ARIA annotations open issues



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

From: Christopher Gallello <cgallell@microsoft.com>
Date: Wednesday, May 7, 2014 at 10:10 AM
To: "public-pfwg@w3.org" <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. 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. 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
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.