What does focusable or otherwise interactive mean

[jnurthen]

Presentation role conflict resolution states:
"If an element is focusable, or otherwise interactive, user agents MUST ignore the presentation role and expose the element as described in the accessibility API mappings for presentational objects that remain in the accessibility tree, in order to ensure that the element is both understandable operable."

We need to know what platforms are actually doing here and (if they are in agreement) clarify the text to match reality. If they are not in agreement we can deal with that too.....

Q1 - So what does focusable actually mean?

• native focusable
• tabindex = 0
• tabindex > 0
• tabindex = -1

Q2 - Do any user agents actually do anything with the "otherwise interactive" part? If so what are they looking at

• click events
• keyup/down events
• pointer events
  If they are looking at these, how can that actually work taking into account event delegation.

So @aleventhal @cookiecrook @jcsteh what do chromium, webkit & gecko actually do here.

[JAWS-test]

Test results for JAWS (with IE 11, Chrome, Firefox): FreedomScientific/standards-support#256

[jnurthen]

@JAWS-test I'm not sure that helps answer the question above.

[JAWS-test]

@jnurthen: If I assume that JAWS is accessing the Accessibility API, the test results show how browsers currently interpret role=presentation. My test does not cover all of your questions, but some

[jnurthen]

The ones it covers I believe are clear as to what should be the result. I'd really like to hear from those implementing this in browsers as to how they are interpreting all of the points so we can clarify the language in the spec.

[jcsteh]

Q1 - So what does focusable actually mean?

* native focusable

* tabindex = 0

* tabindex > 0

* tabindex = -1

All of the above. In addition, in Firefox, a scrollable area (e.g. CSS overflow: auto where content overflows the box) becomes focusable to enable keyboard scrolling, so this also counts as focusable here.

Q2 - Do any user agents actually do anything with the "otherwise interactive" part? If so what are they looking at

Firefox doesn't look at events. However, presentation roles are ignored if Firefox thinks an element must be accessible, defined as:

1. The element is focusable; see above.
2. There is a title attribute. Perhaps this rule shouldn't apply for presentational roles; it wasn't added specifically for those.
3. The element has a global ARIA attribute.
4. The element is the target of an ARIA relation; e.g. some other element references this element in aria-labelledby, aria-describedby, aria-details, etc.

[carmacleod]

@jnurthen I'm happy to take this issue and add appropriate words to the still-waiting-for-review PR #852. Just have to decide what the appropriate words are. :)

In the waiting PR, the sentence that you quoted has been restructured using a bulleted list for clarity.
The pertinent lines are:

User agents MUST NOT expose host language elements having explicit or inherited presentational role in the accessibility tree, with these exceptions:

• If an element is focusable, or otherwise interactive, user agents MUST ignore the presentation role and expose the element, in order to ensure that the element is operable.

As an opening volley, based on @jcsteh's #1192 (comment), I suggest keeping the above bullet point intact, and linking the words "focusable" and "interactive" to the following definitions added to terms.html:

• Focusable
  An element is focusable if it is able to receive the input focus. Certain elements can be natively focusable as determined by the user agent based on platform conventions and the recommendation of the host language (examples in HTML are: anchor, link and area if they have an href; button, input, option, select and textarea if they are not disabled; browsing context containers like iframe; and other special cases like first summary element child of a details element, contenteditable elements, etc). Other elements can be made focusable by the author (e.g. in HTML, by setting the tabindex attribute to any valid integer value).

• Interactive (need help with this one. I'm not sure "interactive" is the right word if it doesn't include events. Jamie used the word "accessible", but I'm not sure we can co-opt that word for this...)
  For the purposes of this document, an element is considered interactive if it is focusable (link to above dfn), or if it has an HTML title attribute or global ARIA attribute, or if it is the target of an ARIA relation (link to Relationship dfn).

Some links in the HTML spec that could be used to reduce the number of words in these definitions:
https://html.spec.whatwg.org/multipage/interaction.html#focusable-area
https://html.spec.whatwg.org/multipage/interaction.html#tabindex-value
https://html.spec.whatwg.org/multipage/dom.html#interactive-content-2

[jnurthen]

Thanks @carmacleod
Lets wait until we hear from the other platforms before looking too closely. I imagine there are lots of similarities but at least a few differences too.

@aleventhal @cookiecrook can you please update with your platform's behaviour.

[cookiecrook]

Q2 - Do any user agents actually do anything with the "otherwise interactive" part?

Yes. See screen shot of WebKit Accessibility Inspector. The "Write" tab in this edit view exposes its ancestor #tab-container as the click listener.

To some degree, this corresponds to what VoiceOver calls "clickable." More on that below.

If so what are they looking at

• click events
• keyup/down events
• pointer events
• If they are looking at these, how can that actually work taking into account event delegation.

All of the above, plus touch start/end/move events and a few others IIRC.

WebKit ignores marking an element as clickable if event delegation is on the <body> element, because it resulted in too many false positives. About a decade ago, a lot of web applications started using body delegation causing VO to claim everything was clickable. Technically true, but too chatty and misleading for the user.

However, there are still cases where VO will announce something as clickable if both are true:

• it or one of its non-<body> ancestors has one of these events assigned.
• the element is navigable, but is not one of the roles commonly associated with "click" type actions.

For example, if a button, link, and static text are all inside a container that has a delegate listener, only the static text is announced as "clickable" b/c the user already knows that buttons and links are clickable.

The heuristics aren't perfect, but seem to be working reasonably well. I don't think they've changed in the 7 or 8 years since accounting for the body delegation pattern.

[pkra]

It would be good to address #1270 when resolving this.