Clarify how "otherwise interactive" relates to overriding the none/presentation role

[cookiecrook]

From a WebKit discussion with @twilco, the following markup results in the element being presentational, even though it has a click handler. The behavior is identical in Safari, Firefox, and Chrome.

<div role="none" onclick="alert('Hello world');">Test</div>

However, the ARIA spec in §9.3 states (emphasis mine):

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

It seems reasonable that the implementations are wrong here, and the click handler would make this count as "otherwise interactive."

Discussion points for the working group:

• Does the group agree that the none/presentation role should be ignored here? As an example, this change would mean that the div would then be conveyed as a generic "clickable" in VoiceOver. E.g. "Test, clickable" not "Test, button"
• What other events or handlers besides focus and activation (click, etc) should denote an element as "interactive" in the context of overriding the none/presentation role?
• Event delegation on the body is a common pattern that should be excepted from this change (or every element could count as interactive)...
• It's possible that event delegation on any non-body ancestor element (e.g. main or some other widget container element) should also be excepted, but we don't see this pattern used as often as body delegation, so the impact may be minimal either way.

[aleventhal]

I think I might disagree. Here's a case where I think it's reasonable. The click handler might be on an ancestor just for authoring reasons.

<div role="none" onclick="foo()">
   <div role="button>button 1</div>
   <div role="button>button 2</div>
   <div role="button>button 3</div>
</div>

[aleventhal]

Another case might be where the author has the same functionality available on a nearby widget, and doesn't want to expose it in the tree twice (e.g. there's a separate thumbnail and caption that you can click on).

[cookiecrook]

The click handler might be on an ancestor [with interactive descendants] just for authoring reasons.

The thing that make that example valid is that the element contains some descendants with known "interactive" roles like button. Maybe we can account for this delegation-to-descendant case by limiting it to where there are no focusable or interactive contents? Only text nodes or other "static" contents?

[cookiecrook]

Another case might be where the author has the same functionality available on a nearby widget, and doesn't want to expose it in the tree twice (e.g. there's a separate thumbnail and caption that you can click on).

Yeah, that's a good example.

[aleventhal]

The thing that make that example valid is that the element contains some descendants with known "interactive" roles like button. Maybe we can account for this delegation-to-descendant case by limiting it to where there are no focusable or interactive contents? Only text nodes or other "static" contents?

That seems like a potentially expensive computation.

[cookiecrook]

So maybe we just do this on leaf nodes and ignore any delegation of the delegation contexts? Your duplicate widget example could still get exposed, but aria-hidden would be the better path to purposefully hide it than role=none

[JAWS-test]

I think "or otherwise interactive" should be removed from the specification because it is not possible for the browsers to recognise whether the event handlers are relevant to the role and operation of the respective element. On many pages, the screen reader then outputs "clickable" or "mouseover" for each text element because corresponding event handlers are used on the body. Each element needs a correct role and errors in the web page design cannot always be corrected sensibly by the browsers.

[aleventhal]

I think using role="none" is on an element with an onclick is a valuable technique. If the author is using ARIA, we should lean toward trusting them on this one. It allows them to have element(s) elsewhere that are in the AX tree and handle the interaction. There could be many reasons why the role="none" element is the wrong one to present as interactive to the user.

[cookiecrook]

Summarizing again from this morning's call (minutes), though discussion ended early again.

I've been convinced by @aleventhal that we should not override the role on any container element where the event handler may be used for event delegation to descendant leaf nodes. Author usage is too ambiguous to override the role.

I think @aleventhal has been convinced that role=none is not a reasonable way to "hide" an element in the duplicate action case. There, the expectation is that the author should use aria-hidden=true not role=none…

So we're back to leaf nodes only... such as the following contrived examples:

<img role="none" onclick="alert('Hello world');">
<div role="none" onclick="alert('Hello world');">Test</div>
<h1 role="none" onclick="alert('Hello world');">Test</h1>

Someone (I think @jnurthen but maybe @mcking65) mentioned that it should not fall back to the native role, but fall back to the generic role. I agree.

@jnurthen also mentioned that this related to @jcsteh's point in Issue ?? that title on image is a form of interactivity. So these examples may also be worth considering as "otherwise interactive."

<!-- does the browser's tooltip overlay make these images "otherwise interactive"? -->
<img title="hello world" alt=""><!-- implicit role=none? b/c of alt="" -->
<img role="none" title="hello world" alt="">

[cookiecrook]

@JAWS-test wrote:

I think "or otherwise interactive" should be removed from the specification because it is not possible for the browsers to recognise whether the event handlers are relevant to the role and operation of the respective element.

I don't agree that's the case in all instances, but I'm open to being convinced otherwise.

On many pages, the screen reader then outputs "clickable" or "mouseover" for each text element because corresponding event handlers are used on the body.

This was already addressed in the initial issue description (third bullet). Events on the body are referred to as "event delegation" which we would explicitly ignore. Aaron further convinced me that event delegation on any ancestor is also too ambiguous to include, which was another question from the original description (fourth bullet).

[aleventhal]

Someone remind me the practical downside of saying event handlers aren't enough to override role="none", in terms of exposing a node. Just trust the author in those cases. Being something that's navigable with the keyboard though, that should be enough to override.

[cookiecrook]

@aleventhal wrote:

Someone remind me the practical downside of saying event handlers aren't enough to override role="none", in terms of exposing a node.

I don't see a practical downside to overriding role=none in examples like this:

<div role="none" onclick="alert('Hello world');">Test</div>

The downside to not overriding is that there's an interactive element that is not exposed to AT. Many authors still get this wrong, so if it's a 1) rendered leaf node, 2) has a click handler, and 3) isn't explicitly hidden with aria-hidden=true, I'm arguing the implementations should expose that generic clickable element to AT users.

Just trust the author in those cases. Being something that's navigable with the keyboard though, that should be
enough to override.

I'm not sure I understand. This makes it seem you mean the opposite of how I read your first sentence. Are you suggesting this issue be closed by removing the text "or otherwise interactive?"

If so, I don't agree. ARIA has always been fairly keyboard centric, but I don't think that's a reasonable way to infer "interactivity" anymore.

[aleventhal]

The downside to not overriding is that there's an interactive element that is not exposed to AT. Many authors still get this wrong,

Are we sure many authors are doing this specific thing -- an event handler with role="none", where usability would be hampered by obeying the role="none"? If I'm an author it seems intuitive that I can use role="none" to avoid having an extra announcement. I would not expect authors to go read and find out that in this one case role="none" won't work.

so if it's a 1) rendered leaf node, 2) has a click handler, and 3) isn't explicitly hidden with aria-hidden=true, I'm arguing the implementations should expose that generic clickable element to AT users

I think any rule here that hinges on leafiness loses some spec simplicity for little gain. To me, I don't think we can prove user benefit of having a rule like that. It feels like we're adding complexity. My thought is that we make things simpler for the authors and UA developers.

However, I don't really feel that strongly about it as this is all an edge case. What do others think?

Yes, I think it is worth looking into whether the "or otherwise interactive" clause nets any real user benefit.

[cookiecrook]

@aleventhal I'm interpreting your concern as:

1. It adds some bit of spec complexity.
2. It potentially adds implementation complexity (perhaps unnecessary perf impact?)
3. You're not convinced the contrived leaf node case is worth solving until we see it as a more common authoring problem.

Is that a fair summary of your concern Aaron? If so, the @JAWS-test suggestion to remove "or otherwise interactive" would solve your concern.

I'm worried about future modalities where "focusable" may not apply, but I could be convinced to ignore those concerns for now and address them later when they arise. I'll consult with others inside Apple. I'd also like to hear opinions from @joanmarie and @jcsteh if possible.

[aleventhal]

James that's fair. And I think also: 4. There are real cases where it would be fair to do this, and in fact authors might be doing it already

[cyns]

I'm ok with removing "otherwise interactive."

I think I remember where this came from.
<img alt="" onclick="foo()"> was (is?) fairly common because some authoring tools put alt="" on images by default to avoid validation errors. I've seen this in at least content management systems I've worked with.

We were concerned that the same would happen with role=presentation. I didn't, and won't, because missing role doesn't cause validation errors.