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:
ACTION-1608 on Cynthia Shelly to Bring up issue-708 with the html-a11y taskforce. - due 2015-06-30, closedACTION-1681 on Joseph Scheuhammer to Propose new wording, as an editorial change only to clarify the inclusion rules in section 5.1.2 - due 2017-03-14, closed- 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:09I 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.
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
Closing, as all associated actions are closed.
Display change log
