Conflicting inclusion/exclusion criteria for elements in the accessibility tree (Was: Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group)

I have to agree with Joseph's concerns.

This isn't a matter of whether author's should be able to mark
presentational elements as presentation.  It's a question of how user
agents and ATs should behave when the information provided by the author is
inconsistent.  In that case, I would always argue for the user agent to
serve the user, presenting as much information as possible.

Interactive elements need to be in the accessibility tree.  If not,
assistive technologies cannot effectively work as enhancements to the
underlying browser interface, with input and output working independently
from the DOM.  If an author places role="none"/"presentation" on an
interactive element, that would be an author error and a robust approach
would be to treat it as role unknown.

The behavior should be the same when an element is given ARIA attributes
but either explicitly or by default has a role of none.  Treat it as a
generic object, unknown role or no specific role, but ensure that the
information that *was* provided is available to the user.  It can still be
reported as an authoring error in a validation tool, but we need a useful
behavior for user agents.

The examples Fred provided, of wanting to have grouping elements that
are transparent to assistive tech, are never something you would want to
toggle on or off by changing a role.  (And roles should never be used to
toggle state, anyway.)  I can see no good reason why someone would provide
aria-label or other ARIA attributes on an element that should be ignored.
The logical assumption is that the author did not understand the normal
impact of role="none".

aria-hidden, in contrast, *can* be toggled.  It therefore makes sense that
aria-hidden should take precedence over aria-label: an author should not
have to remove all the ARIA attributes in order to temporarily hide some
content.  However, if the author does not also take care to ensure that the
element cannot receive keyboard focus, we still have an inconsistent state
that the user agent needs to respond to: If the allegedly hidden content
receives focus, the user needs to know where they are.

So I would suggest the following series of priorities for the Core-AAM
guidelines on whether to include an element in the accessibility tree:

   1. If element is not rendered (and therefore cannot receive focus)
   EXCLUDE
   2. Else, if element is in the current active tab order,
   OR is identified as the aria-activedescendent of another element that is
   in the current tab order, INCLUDE
   3. Else, if element has aria-hidden="true" (on self or ancestor),
   OR is hidden according to the host language semantics and does not have
   aria-hidden="false" to override, EXCLUDE
   4. Else, if element has other global ARIA attributes,
   OR a computed role (by default or as set by the author) other than
   none/presentation,
   OR is referenced by an ARIA relationship of another (rendered and not
   hidden) element,
   OR is focusable but not in the current tab order (e.g., a
   tabindex="-1"), INCLUDE
   5. Else, if element has an author-supplied role of none/presentation,
   EXCLUDE
   6. Otherwise, INCLUDE or EXCLUDE according to host language semantics

Host languages and/or their mapping specs would therefore need to clearly
define:

   - Which elements are not rendered at all (and are therefore also neither
   perceivable nor interactive, and cannot be "revealed" with
   aria-hidden="false")
   - Which elements are in the current active tab order (factoring in
   features such as "inert" subtrees in HTML 5.1), and which other elements
   are focusable
   - Which elements are hidden (not perceivable/interactive and should be
   treated as aria-hidden unless specifically over-ridden)
   - Default roles for each element type
   - Any language-specific rules for including or excluding elements (for
   many SVG elements, this would be whether or not they have an associated
   <title> or <desc>; for HTML, it would include things like <img alt="" />)


A final sticky issue, however, is what to do about other events.  Unlike
keyboard focus, there isn't always a clear association between an event and
the semantically relevant element.  Event listeners can be added once to a
parent element to collect events from many child elements; without
examining the script, you don't know whether the action distinguishes
between the individual element targets.  The ARIA event mapping guide
requires accessibility API events to be fired for changes to text content,
but that doesn't mean every span needs to watch for text mutations: these
can be reported by the nearest ancestor element that is included in the
accessibility tree.

The inclusion criteria "Elements that may fire an accessibility API event"
is therefore problematic.  Whether or not an element may fire an
accessibility API event depends on whether or not it is included in the
accessibility tree.  Looking through the accessibility API event list [1],
I think most of the events would either be covered by the test for a valid
role, or could be safely bubbled up to the nearest ancestor in the
accessibility tree. I would therefore remove that inclusion criteria
altogether.


I'm going to be cleaning up other parts of the SVG-AAM this weekend, but
I'll have to hold off making too many changes on these sections until there
is a group resolution on how to proceed for the Core-AAM.

~Amelia

[1]: https://www.w3.org/TR/wai-aria-implementation/#mapping_events






On 4 March 2016 at 10:43, Fred Esch <fesch@us.ibm.com> wrote:

> Joseph,
>
> For SVG it is imperative that an author be able to mark an element with
> the role none or presentation and know that the element will not appear in
> the accessibility tree. SVG is too messy to force authors and authoring
> tools to work through anything but the simplest rule.
>
> Case 1: A group element is only present in the SVG to pass along common
> attributes to their children. For instance you may group text elements for
> labeling items around a circle, by their anchor location. This group
> element has no semantic meaning. This is a common use for group elements as
> it makes the SVG smaller and makes it easier to edit reused styles. This
> group element should not be included in the accessibility tree.
>
> Case 2: A group element has semantic meaning and the parent/child
> relationship is significant. An example, would be a group element
> representing a *stack* in a *stacked* bar chart. The children of the
> *stack* group element are the individual bars that make up the stack and
> the *stack* group element may contain *stack* level information, for
> example the total value (height) of the *stack*. A good chart navigation
> tool would let a user visit the *stack* and the user could either visit
> the individual bars in the *stack* or move to another *stack*. Without
> using *stack* level objects in the accessibility tree the concept of a
> *stacked* chart would be lost. This group element should appear in the
> accessibility tree.
>
> Programmatically, both Case 1 and Case 2 group elements may look similar.
> Authoring tools (few developer hand edit SVG) need to provide a straight
> forward way to disallow elements from being in the accessibility tree.
> Authors need a straight forward way of to disallow elements from being in
> the accessibility tree. Without an author friendly way of identifying case
> 1 from case 2 the underlying concept of the graphic can be lost.
>
> The SVG accessibility task force decided that using a role of none or
> presentation was the golden hammer that developers and authoring tools need
> to exclude elements from the accessibility tree. Amelia is add the changes
> in. If we need to change the ARIA spec lets change it.
>
>
> Regards,
>
> Fred Esch
> Watson, IBM, W3C Accessibility
> [image: IBM Watson] Watson Release Management and Quality
>
> [image: Inactive hide details for Joseph Scheuhammer ---03/03/2016
> 10:57:00 AM---On 2016-03-02 10:07 PM, Amelia Bellamy-Royds wrote: >]Joseph
> Scheuhammer ---03/03/2016 10:57:00 AM---On 2016-03-02 10:07 PM, Amelia
> Bellamy-Royds wrote: >
>
> From: Joseph Scheuhammer <clown@alum.mit.edu>
> To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, Richard
> Schwerdtfeger <richschwer@gmail.com>
> Cc: ARIA Working Group <public-aria@w3.org>
> Date: 03/03/2016 10:57 AM
> Subject: Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group
> ------------------------------
>
>
>
> On 2016-03-02 10:07 PM, Amelia Bellamy-Royds wrote:
> >
> > /... That said/, I would like it to be more clear. I think the easiest
> > change would be to modify the bullet point (in section 5.1.2 of the
> > Core-AAM) that currently says:
> >
> >       * Elements that have a global WAI-ARIA attribute but do not have
> >         aria-hidden="true". (See Excluding Elements in the
> >         Accessibility Tree for additional guidance on aria-hidden.)
> >
> > To instead say
> >
> >       * Elements that have a global WAI-ARIA attribute but do not have
> >         aria-hidden="true" or a mapped role of presentation or none.
> >         (See Excluding Elements in the Accessibility Tree for
> >         additional guidance on aria-hidden and presentational roles.)
> >
>
> I don't believe that is consistent with the specification of the
> presentation role.  Either that, or the specification needs to change.
>
> I filed ISSUE-708 about this in Mar 2015 [1].  There have been
> discussions at the AAPI teleconferences, and we have been approaching
> agreement on changes to the core-aam inclusion rules. Here's a summary:
>
> 1. Using role="presentation" on an element that is interactive is an
> author error, and the role will be ignored.  Here, "interactive" means
> any of (1) the element is focusable, or (2) can cause an AAPI event
> [2].  The reason that presentation is ignored in these cases is that the
> presentation role will stop neither a DOM event nor the corresponding
> AAPI event from occurring, and the event will have an associated
> source/target. That is, there will be an accessible object in the a11y
> tree as the target of the event.
>
> The ARIA specification for role="presentation" at least documents the
> focusable case:
> "If an element with a role of presentation is focusable, user agents
> MUST ignore the normal effect of the role and expose the element with
> implicit native semantics, in order to ensure that the element is both
> understandable and operable" [3].
>
> 2. Using role="presentation" in conjunction with a global aria property
> is also an author error.  The role says that the element has no meaning,
> whereas the aria-* says that it does.   In this case, the ARIA
> specification states:
> " ...the user agent MUST always expose global WAI-ARIAstates and
> properties to accessibility APIs, even if an element has an explicit or
> inherited role of presentation" [3].||||||
>
> In summary, the core-aam inclusion rules need changes, but those changes
> must be in accordance with the ARIA spec.  If it's necessary that there
> are cases where role="presentation" *always* excludes an element from
> the accessibility tree, then the ARIA specification *itself* must be
> modified.
>
>
> [1] https://www.w3.org/WAI/ARIA/track/issues/708
> [2]
>
> http://w3c.github.io/aria/core-aam/core-aam.html#mapping_events_state-change
> [3] http://w3c.github.io/aria/aria/aria.html#presentation
>
> On 2016-03-02 10:31 PM, Amelia Bellamy-Royds wrote:
> > If there's time, I'd appreciate the group taking a look at GitHub
> > Issue #136, on the interaction of role=none/presentation and other
> > global ARIA attributes. Joanmarie filed the issue when trying to
> > implement SVG-AAM, but it really stems from the Core mapping spec.
> >
> > https://github.com/w3c/aria/issues/136
> >
> > I'd like to confirm that the interpretation we're taking for SVG-AAM
> > matches how others think Core-AAM should be interpreted. And it would
> > be nice to get clarified language into both specs in time for
> > publication of the new drafts next week.
> >
> > ~Amelia
> >
>