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

The reason I ordered it in this way was because we don't want to over-ride
aria-hidden if we don't have to.

An author should be able to temporarily exclude a section of the document
with aria-hidden if it cannot be focused by user input, even if it could be
focused by script (i.e., if it has a negative tabindex value).  The
aria-hidden value (or host language hiding) will only be ignored if the
*user* could stumble upon the element in the tab order.

However, it is not quite as complicated as Fred fears.  A negative tabindex
value will always make an element "focusable but not in the current tab
order", regardless of whether or not it is normally focusable by default.
So yes, you need to test the value, but the impact of the value does not
depend on the element.

In other words, certain elements (focusable based on host language
semantics) are treated as if they have a default tabindex="0".  However, an
author-supplied tabindex value takes precedence.

Any user agent that is implementing this will already have the rules for
whether something is focusable or not and whether it is in the current tab
order or not.

For authors, we would of course strongly encourage them to never use
aria-hidden on an element without also excluding it from the current tab
order (by giving any normally-focusable child elements tabindex="-1").  The
order of precedence only handles what to do in the case of a conflict.



> One undesirable aspect for authors of the steps Amelia has - is the last
> part of step 4 *(**OR is focusable but not in the current tab order
> (e.g., a tabindex="-1")*is not in step 2. I can see making the* presence*
> of a tabindex a factor in inclusion in the accessibility tree, but not the
> *value* of the tabindex. As it is, it sounds like some elements will be
> always be included in the accessibility tree regardless of tabindex
> *value* and others will be included/excluded based on the *value* of a
> tabindex. If this is true, is there a table that explains which category an
> element falls in? Having rule 3 between 2 and 4 makes things even less
> predictable for authors.
>
>
>