Guidelines for complex widget with nested interactions

[gaurav5430]

HTML does not allow nested interactive elements.
I have seen a similar discussion here, which discusses how nested interactive roles are a problem for screenreader users.

I would like to understand how to go about creating a widget which has nested interactive elements. Since semantic HTML can't be used to create these nested interactions, how would we expose the correct ARIA roles so that it is still screenreader and keyboard friendly.

Some examples:

The above image shows a widget used by gmail. The widget is interactive as a whole, but once you hover on it, an overflow menu is also available which is also interactive.

The overflow menu is created using a div, the trigger for this overflow menu has aria-popup.
The widget is created using a div, which passes on the keyboard interactions to the underlying link, and once the focus is on this widget, user can press tab to focus the overflow menu.

I would like to understand if there are some guidelines for nested interactivity in ARIA, with or without a dependency on semantic HTML.

Is it fine to have nested interactive elements as long as it is valid HTML/valid aria structure?
so button inside button or role="button" inside role="button" wouldn't be allowed, but if we just replace it with div inside div (and take care of the keyboard interactions) it would be fine ?

If nested interactions are not a problem as such, any pointers to why they are not allowed in HTML?

[scottaohara]

but if we just replace it with div inside div (and take care of the keyboard interactions) it would be fine ?

It would not be fine. Steve Faulkner answered this question in the original issue where you referenced.

While it visually could look like a single control, it could very easily be two adjacent controls in the DOM, rather than nesting interactive elements within each other.

[gaurav5430]

While it visually could look like a single control, it could very easily be two adjacent controls in the DOM, rather than nesting interactive elements within each other.

in the above discussed case for gmail, yes, but what about something like this:

In this case, the card is clickable as a whole and there is a secondary CTA inside the card. This can easily be changed to have the primary and secondary CTA inside the card, but from usability perspective that might reduce the tap area for the primary CTA.

Are you suggesting these types of UX patterns are invalid and should be converted to linear side-by-side interactions? If yes, why is this invalid? It seems like something which should be allowed, so just wanted to understand if it is about not allowing nested interactions at all, or not allowing nested interactions using the existing semantics available.

[scottaohara]

There are still ways to do that without having to actually nest controls.
Give https://inclusive-components.design/cards a read

[jnurthen]

Closing this.