ISSUE-708: The phrase "If not already excluded from the accessibility tree per the rules above" implies that the listed conditions do not override. Is that correct?

Section 5.1.2: Condition on including elements in the accessibility tree is ambiguous

The phrase "If not already excluded from the accessibility tree per the rules above" implies that the listed conditions do not override. Is that correct?

State:
CLOSED
Product:
ARIA 1.1 Core Mapping Specification
Raised by:
Joseph Scheuhammer
Opened on:
2015-03-31
Description:
The first sentence in the section on including elements in the accessibility tree begins [1]:
"If not already excluded from the accessibility tree per the rules above in Excluding Elements in the Accessibility Tree, user agents MUST ..."

It then goes on to list criteria for including elements in the accessibility tree.

That wording implies that an element that has already been excluded won't be included even if it satisfies one or more of the criteria.

One of the criteria is if the element is focusable. Another is if the element can cause an accessibility event. Surely, if either of those is true, the element *must* be in the accessibility tree. That is, these criteria are an override of the exclusion rules.

Suggested rewording:
"The following conditions override the rules above in Excluding Elements in the Accessibility Tree. Even if excluded by those rules, user agents MUST ...

[1] http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#include_elements
Related Actions Items:
Related emails:
No related emails

Related notes:

I read through this more closely, and I now think this wording is correct. Even if it is focusable, etc., an element that is display:none or role=presentation must not be included in the tree. Display:none is used to remove markup that is not part of the current state of the page. role=presenation is intended to remove the semantics of the element.

Cynthia Shelly, 22 Jun 2015, 23:44:09

I agree with you about display:none. The same can be said about CSS visibility:hidden, and html5's @hidden.

Nowever, if an author puts a @tabindex on a element with role="presenatation", that element will be focusable, and will generate focus events in both the DOM and the AAPI. If the author goes further, and adds an @onclick handler, the element will react to mouse clicks:
<span role="presentation" tabindex="0" onclick="alert('hi!')> ...

I think that element should be exposed in the a11y tree.

The same cannot be said about display:none and visibility:hidden. Even if @tabindex or @onclick is added, there is nothing rendered visually to place focus upon, nor to accept mouse clicks. In a sense, the CSS wins over @tabindex and @onclick in these cases:
<span style="display:none" tabindex="0" onclick="alert('hi!')>

So: the re-wording I'm suggesting has to take all these cases into account.

Joseph Scheuhammer, 6 Jul 2015, 18:39:27

Regarding my last comment, here is a test file that shows what happens with an element that has tabdinex="0" and one of:
1. display:none
2. visibility:hidden
3. role="presentation"

The first two are not focusable. That third one is.

http://clown.idrc.ocad.ca/Fluid/aria/VisibilityHiddenFocusable.html

Joseph Scheuhammer, 7 Jul 2015, 18:00:32

Closing, as all associated actions are closed.

Joseph Scheuhammer, 3 Apr 2017, 18:52:37

Display change log ATOM feed


Joanmarie Diggs <jdiggs@igalia.com>, James Nurthen <nurthen@adobe.com>, Chairs, Michael Cooper <cooper@w3.org>, Ruoxi Ran <ran@w3.org>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: index.php,v 1.326 2018/10/13 17:29:51 vivien Exp $