Add definition for Focusable - #39

I think this is vague enough that it covers the variety of things that user agents actually count as being focusable.

Loosely, I think the definition will need to cover the following:

1. An element that would trigger a native platform "focus" event/notification based on the action of a user (e.g. clicking or tabbing to it)

2. An element that is only script-focusable should be exposed to the accessibility API at such a time when it is focused and triggers a native system focus event/notification. IOW, the above hidden, non-tabbable link would not be "focusable" but if an author script ever focused it, it would become "focusable" at the time.

3. Element is not disabled (e.g. via @disabled), possibly a moot point since these are generally readonly and non-focusable.

4. Element is not inert (e.g. via @inert)... This portion of the ARIA edit should probably be spun off into another issue until the HTML @inert PR is merged and the feature is implemented in multiple engines.

Those 2 aria-hidden="true" tabindex="-1" examples are definitely weird.
https://carmacleod.github.io/playground/focusable-test.html

Chrome puts them in the a11y tree and says they're focusable.
Firefox doesn't put them in the a11y tree at all.
Safari lists them under ignored (hidden) and they're in the tab order??? They say "focused" after you tab to them. Not sure what's going on there.

Looping in @alice because she was going to research the reasons for a recent change to the HTML spec that mentions expected behavior of tabindex="-1"

Context for Alice, this new term "focusable" is being added to ARIA with the intention of simplify the text required for the "tree inclusion" portion of the ARIA spec. E.g. ~"among other things, content should be included if it's 'focusable'"

It is worth noting for this discussion that the terminology section in ARIA is informative not normative.

@cookiecrook, some random thoughts:

Is the HTML definition of focusable area helpful here? It mentions "tabindex non-null", and "not inert" and "not disabled" (do we need to also consider not aria-disabled?). That definition also mentions several other focusable things, like shapes in an image map, UA-provided subwidgets of an element, etc, and includes this lovely "catch-all" phrase:

Any other element or part of an element determined by the user agent to be a focusable area, especially to aid with accessibility or to better match platform conventions.

We may not need to wait before including "not inert" in our definition of focusable, because the current definition of the concept of inertness is probably close enough.

I wonder if your point 2 about only including script-focusable elements in the tree on focus might belong over in w3c/aria#1100 so that this definition of focusable can be used in other places in the ARIA spec? I also wonder if point 2 is more of a "user agents MAY", given the inconsistent behavior I noted in the previous comment?

Is the HTML definition of focusable area helpful here? It mentions "tabindex non-null", and "not inert" and "not disabled"

I've had a chance to review and I agree that cross-referencing the HTML definition is probably best.

do we need to also consider not aria-disabled?

I don't think aria-disabled affects focus, so no.

I wonder if your point 2 about only including script-focusable elements in the tree on focus might belong over in w3c/aria#1100

Okay. Will unpack this one over there.

Clarifying: rather than making a new copy of the focusable definition in the ARIA spec, I think the ARIA definition should link to the HTML definition. I think that's what you intended, but I wanted to be clear.

Closing this in favor of w3c/aria#1936