SVG-AAM / Core AAM: Consider explicit language regarding objects with presentational role and ARIA attributes

[joanmarie]

In the SVG-AAM's 5.1.1 Excluding Elements from the Accessibility Tree there is the following note text:

The other factors for excluding elements, as described in the Core Accessibility API Mappings, are as follows:

• If the first mappable role provided by the author is none or presentation, the element must not be exposed.

[...]

Consult the original document [CORE-AAM] for the normative text.

One should, of course, consult the CORE-AAM as the good note states. But a reader of the above text couldn't be blamed all that severely if they read the above note text and concluded that given

<rect role="none" aria-label="Am I Here?" x="1" y="1" width="10"' height="10"/>

there should be no accessible object.

If one consults the CORE-AAM for the normative text, 5.1.1 Excluding Elements from the Accessibility Tree, they would find something quite similar:

The following elements are not exposed via the accessibility API and user agents MUST NOT include them in the accessibility tree:

• Elements with none or presentation as the first mappable role in the role attribute string, according to the rules for the none and the presentation role defined in Accessible Rich Internet Applications (WAI-ARIA) 1.0 [WAI-ARIA].

So unless the ARIA spec defines a rule for none/presentation that says otherwise, it would seem that the rect element in the example above does indeed need to be excluded.

There's a lot of text in the ARIA spec regarding the presentation role, but for the question at hand this statement seems to be the most relevant:

For any element with an explicit or inherited role of presentation, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties. However, the user agent MUST always expose global WAI-ARIA states and properties to accessibility APIs, even if an element has an explicit or inherited role of presentation.

(emphasis added)

The aria-label attribute is global. So then the rect element in the example above would need to be exposed after all (right?).

I mention all of this for a couple of reasons:

1. By adding explicit language in the SVG-AAM regarding objects with presentational role and a valid value for aria-label, implementors would not have to do all of the work above I just did. ;) Plus it would be clear and eliminate lingering doubts (e.g. an implementor might think, "A shape element whose role has been explicitly set to none is surely decorative and useless with respect to accessibility.")
2. The work-in-progress tests in the wiki include shapes with role="none" and an aria-label, along with expected results of NOAC. If the those tests expectations are indeed correct, they seem to be in potential conflict with the text I quote above.

[fredesch]

Joanie,

We intend that any element with a role none or role presentation be omitted
from the accessibility tree. This should overrule everything else - even
aria-label, aria-labeledby and aria-description. For elements with role
none we are not automatically excluding the children of the element from
the accessibility tree.

In SVG, there are lots of times when a group is used for adding style
information but the group does not have semantic meaning and we need the
role none and role presentation to prevent the group from being added to
the accessibility tree. It is imperative that an author know role none is
the magic hammer which absolutely keeps an element, but not necessarily
their children out of the accessibility tree. Even if they perviously
showed the element or use the element in a name or description calculation
of another element - with the magic hammer - role none / role presentation,
that object will not appear in the accessibility tree.

We have a wiki page with testable statements - which we will use to
generate the test files (via a perl script). I wrote the testable
statements, but they haven't been vetted yet. If you find a statement you
disagree with please let us know. Section 1.4 and 1.5 are about role none
and role presentation respectively.

 Regards,                                                 

Fred Esch                                                 

Watson, IBM, W3C
Accessibility

IBM Watson Watson Release Management and Quality

From: Joanmarie notifications@github.com
To: w3c/aria aria@noreply.github.com
Date: 01/08/2016 03:23 PM
Subject: [aria] SVG-AAM: Consider explicit language regarding objects
with presentational role and aria-label (#136)

In the SVG-AAM's 5.1.1 Excluding Elements from the Accessibility Tree there
is the following note text:

  The other factors for excluding elements, as described in the Core
  Accessibility API Mappings, are as follows:
        If the first mappable role provided by the author is none or
        presentation, the element must not be exposed.


  [...]


  Consult the original document [CORE-AAM] for the normative text.

One should, of course, consult the CORE-AAM as the good note states. But a
reader of the above text couldn't be blamed all that severely if they read
the above note text and concluded that given

<rect role="none" aria-label="Am I Here?" x="1" y="1" width="10"'
height="10"/>

there should be no accessible object.

If one consults the CORE-AAM for the normative text, 5.1.1 Excluding
Elements from the Accessibility Tree, they would find something quite
similar:

  The following elements are not exposed via the accessibility API and
  user agents MUST NOT include them in the accessibility tree:
        Elements with none or presentation as the first mappable role
        in the role attribute string, according to the rules for the
        none and the presentation role defined in Accessible Rich
        Internet Applications (WAI-ARIA) 1.0 [WAI-ARIA].

So unless the ARIA spec defines a rule for none/presentation that says
otherwise, it would seem that the rect element in the example above does
indeed need to be excluded.

There's a lot of text in the ARIA spec regarding the presentation role, but
for the question at hand this statement seems to be the most relevant:

  For any element with an explicit or inherited role of presentation,
  user agents MUST ignore any non-global, role-specific WAI-ARIA states
  and properties. However, the user agent MUST always expose global
  WAI-ARIA states and properties to accessibility APIs, even if an
  element has an explicit or inherited role of presentation.

(emphasis added)

The aria-label attribute is global. So then the rect element in the example
above would need to be exposed after all (right?).

I mention all of this for a couple of reasons:

1. By adding explicit language in the SVG-AAM regarding objects with
   presentational role and a valid value for aria-label, implementors
   would not have to do all of the work above I just did. ;) Plus it
   would be clear and eliminate lingering doubts (e.g. an implementor
   might think, "A shape element whose role has been explicitly set to
   none is surely decorative and useless with respect to
   accessibility.")
2. The work-in-progress tests in the wiki include shapes with
   role="none" and an aria-label, along with expected results of NOAC.
   If the those tests expectations are indeed correct, they seem to be
   in potential conflict with the text I quote above.

—
Reply to this email directly or view it on GitHub.

[joanmarie]

@fredesch: Thanks for the explanation!

Your statement:

It is imperative that an author know role none is the magic hammer which absolutely keeps an element, but not necessarily their children out of the accessibility tree.

Only serves to reinforce what I state in the issue title, namely that explicit language is called for.

[klown]

@fredesch,

It is imperative that an author know role none is the magic hammer which absolutely keeps an
element, but not necessarily their children out of the accessibility tree.

Two things: First, what @joanmarie has uncovered in her research is that the ARIA spec appears to contradict this, since, as she quoted, it does say (paraphrase) that even if role="presentation" or "none", if the element also has a global ARIA property, that property MUST be exposed. What is unclear is how said exposure is accomplished. It might mean that the presentation role is ignored, and an accessible is created. Or, it might mean that the global properties are exposed on an existing accessible, possibly the parent accessible. At the very least, something needs to be added to the ARIA specification of presentation/none to clear this up.

Secondly, the magic hammer is not absolute when it comes to events. Although this is somewhat unrelated to the issue at hand, if the element has a @tabindex on it, or an @id that designates it as a potential active descendant, or has a click handler, or other event handler, then the element can cause accessible events. Accessible events have a source accessible object associated with them (X just gained focus, X was just selected, X's value just changed, etc.). In that case, the presentation/none role is ignored as an author error since the browse can't help but emit the events.

[fredesch]

Joseph,

I hope Amelia or Rich jumps in on what is supposed to happen with events.
In SVG we may put an event handler on an object that is not visible to a
sighted user (transparent paint, no border) because it gives the mouse
using sighted user a bigger area to click on. Likewise CSS can add hover
events to a transparent, no border - non visible to a sighted user object,
again to provide a bigger area to get a tool tip response from.

We may not want focus on the larger non visible to a sighed user object and
we may not want the larger non visible to a sighted user object in the
accessibility tree, rather we want the real small, correctly
labeled/described/relationshipped object in the accessibility tree. SVG is
all about visual presentation and we need to provide an understandable way
for authors to enable AT support at the same time they are improving
behavior for folks with older shaky hands with less precise motor skills.
We need magic hammers like role none to work. Otherwise authors will
reasonably give up on trying to get that darn diagram accessible.

 Regards,                                                 

Fred Esch                                                 

Watson, IBM, W3C
Accessibility

IBM Watson Watson Release Management and Quality

From: Joseph Scheuhammer notifications@github.com
To: w3c/aria aria@noreply.github.com
Cc: Fred Esch/Arlington/IBM@IBMUS
Date: 01/11/2016 10:52 AM
Subject: Re: [aria] SVG-AAM: Consider explicit language regarding
objects with presentational role and aria-label (#136)

@fredesch,

  It is imperative that an author know role none is the magic hammer
  which absolutely keeps an
  element, but not necessarily their children out of the accessibility
  tree.

Two things: First, what @joanmarie has uncovered in her research is that
the ARIA spec appears to contradict this, since, as she quoted, it does say
(paraphrase) that even if role="presentation" or "none", if the element
also has a global ARIA property, that property MUST be exposed. What is
unclear is how said exposure is accomplished. It might mean that the
presentation role is ignored, and an accessible is created. Or, it might
mean that the global properties are exposed on an existing accessible,
possibly the parent accessible. At the very least, something needs to be
added to the specification of presentation/none to clear this up.

Secondly, the magic hammer is not absolute when it comes to events.
Although this is somewhat unrelated to the issue at hand, if the element
has a @tabindex on it, or an @id that designates it as a potential active
descendant, or has a click handler, or other event handler, then the
element can cause accessible events. Accessible events have a source
accessible object associated with them (X just gained focus, X was just
selected, X's value just changed, etc.). In that case, the
presentation/none role is ignored as an author error since the browse can't
help but emit the events.

—
Reply to this email directly or view it on GitHub.

[joanmarie]

So... There seem to be a number of issues (some bigger than others).

@fredesch: Do you agree that the magic-hammer behavior you need for SVG accessibility is not 100% clear from the text in the SVG AAM? If so, perhaps it would make sense to remedy that specific problem within the SVG AAM, namely:

1. Add normative text stating what user agents MUST (or MUST NOT) do regarding SVG elements with role="{presentation,none}".
2. Remove the current, and non-normative, text that is there and which I quote in the opening report of this issue.

That won't fix everything being discussed here, but I think it will get us closer to the goal of implementors knowing what is expected when they encounter an SVG element with a presentational role and an aria-label AKA the magic hammer.

[fredesch]

Joanie,

We will discuss issues you and Joseph raise at the next SVG A11Y TK
meeting.
Issue: Does an empty title or description nullify title/description
presence when deciding whether to add an object to the accessibility
tree? Git Issue #134
Issue: Does role none/presentation always exclude an element from
inclusion in the accessibility tree? Things that appear to conflict:
action listeners, presence of global aria properties. If role
none/presentation always exclude an element from inclusion in the
accessibility tree, we need normative text stating so. Git Issue #136
Issue: tspan element - should it be treated like a span and by default
not appear in the accessibility tree? Part of Git Issue #133

The testable statements in the wiki are not yet vetted, but feel free to
review the testable statements in the wiki and see if they raise any
issues.

 Regards,                                                 

Fred Esch                                                 

Watson, IBM, W3C
Accessibility

IBM Watson Watson Release Management and Quality

From: Joanmarie notifications@github.com
To: w3c/aria aria@noreply.github.com
Cc: Fred Esch/Arlington/IBM@IBMUS
Date: 01/11/2016 01:15 PM
Subject: Re: [aria] SVG-AAM: Consider explicit language regarding
objects with presentational role and aria-label (#136)

So... There seem to be a number of issues (some bigger than others).

@fredesch: Do you agree that the magic-hammer behavior you need for SVG
accessibility is not 100% clear from the text in the SVG AAM? If so,
perhaps it would make sense to remedy that specific problem within the SVG
AAM, namely:

1. Add normative text stating what user agents MUST (or MUST NOT) do
   regarding SVG elements with role="{presentation,none}".
2. Remove the current, and non-normative text that is currently there
   and which I quote in the opening report of this issue.

That won't fix everything being discussed here, but I think it will get us
closer to the goal of implementors knowing what is expected when they
encounter an SVG element with a presentational role and an aria-label AKA
the magic hammer.

—
Reply to this email directly or view it on GitHub.

[joanmarie]

@fredesch:

The testable statements in the wiki are not yet vetted, but feel free to review the testable statements in the wiki and see if they raise any issues.

How do you think I'm finding the issues I'm raising? ;) ;)

While I fully realize your statements are not vetted and are subject to change, they are extremely handy. :) I've made several local WebKit "Layout Tests" with the assertions there. These automated tests run in a couple of seconds and tell me what all is failing. From there, I debug WebKit and either fix the bug (locally at the moment) or start reading your spec and opening issues like this one. :)

Once your group has consensus and I have proposed fixes for everything, I'll open a bug upstream (in the WebKit issue tracker) and ping you.

[richschwer]

So, fred, ARIA has error handling whereas if you have, on an element, aria-label="foo" and role="none" that is an error condition and it appears in the tree because must decide in or out. In this case we believe the label but ignore the role. However, there is is a situation in SVG where certain elements must be never be mapped and we need to define these exceptions like . We need to allude to that in the spec. We need to create an issue for this. and we need an issue tracker for the SVG-AAM.

[richschwer]

See: https://www.w3.org/WAI/ARIA/track/issues/1003

[joanmarie]

I also opened an issue in tracker to deal with the ARIA spec side of things. Because right now, if SVG's AAM adds text for the magic hammer (fine with me), it will be in direct conflict with the spec (not so fine). So we should add some brief text to the spec saying something which boils down to "check the AAM for the host language for any exceptions" (but properly worded).

EDIT: https://www.w3.org/WAI/ARIA/track/issues/1004

[fredesch]

SVG a11y task force wants the golden hammer. Consensus is authors need a easy to understand way to exclude stuff from the accessibility tree and role none/role presentation is the clear way. If an author includes an aria property like aria-label which would normally include the element in the accessibility tree and set role none, then we consider that an error condition - as there is no way to resolve what the author really wants.

[AmeliaBR]

We really need a change in Core AAM.

As I currently read it, the "exclude" behavior takes precedence over the "include" behavior because the first sentence of Section 5.1.2, Including Elements is

If not already excluded from the accessibility tree per the rules above in Excluding Elements in the Accessibility Tree,

The excluding-elements rules say exclude if the role is presentation or none, so that takes precedence over the must-include for elements with a global WAI-ARIA attribute.

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'll be updating the SVG-AAM with this interpretation in mind.

[AmeliaBR]

From Joseph Scheuhammer (@klown) on the mailing list:

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 . 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 .
   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".

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" .

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.

[AmeliaBR]

[Copying over some more mailing list discussion so we have it all in one thread for reference]

---

From @fredesch on 4 March 2016:

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.

---

From myself later on 4 March 2016:

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, 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

[AmeliaBR]

See also follow-up emails from Joseph and Fred on 7 March 2016.

[AmeliaBR]

Cleaning up old issues.

The section "Presentational Roles Conflict Resolution" in ARIA 1.1 sums up the definitive rules that resulted from this discussion. That section is referenced from the "Excluding Elements from the Accessibility Tree " section in CORE-AAM.

The "Excluding Elements from the Accessibility Tree" needs to be updated to reference it directly in the informative note (the normative text is a reference to CORE-AAM), but I currently have an editor's note on that point:

Links to CORE-AAM and ARIA 1.1 will need to be updated after clarifications with respect to these points have been pushed to the master versions of those specifications.

So I think the Editor's note is enough to make sure it doesn't get forgotten; I'll clean it up next time I do some edits.