TrapFocus should only return focus if it is lost to the body

[egucciar]

TrapFocus assumes if focus is lost , to return it back to the modal. I think this action should only occur if the focus is lost to the body, because of the mutation observe intent is clearly to restore focus if the focused element de-rendered, not if we intentionally move focus elsewhere.

[blvdmitry]

Can you share more about the use case? Technically if we follow wcag - everything around the trapped area should be inert and not receive focus while it's trapped 🤔

[egucciar]

@blvdmitry the use case is I've opened another portal from your portal, so now I've moved focus there and intentionally manage it there.

[egucciar]

@blvdmitry you can also see the PR I raised i discuss the specific use case more.

[blvdmitry]

I assume that other component portal would trigger TrapFocus then as well and focus will be contained inside it? And TrapFocus already supports these chained calls so when your other portal is closed (similar to if you would open a dropdown inside a modal) – it would move the focus back to the previous portal

[egucciar]

@blvdmitry it doesn't work because your trap focus code has a mutation observer that forcibly moves the focus back to the popover if the active focus does not live within the root. Unless your mutation observer has some way of "sleeping" or knowing when its no longer in control, which is not obvious if you're just using a component rendering a portal.

[blvdmitry]

I think that's already happening too, where mutation observer checks if it gets called from the last trap focus instance

https://github.com/reshaped-ui/reshaped/blob/canary/packages/utilities/src/a11y/TrapFocus.ts#L140

[egucciar]

Okay @blvdmitry , I will rethink this approach then and will try to see how to hook into that directly.

[egucciar]

@blvdmitry Was chatting with some devs about this - is this kind of TrapFocus stacking system common? Where did you get the inspiration from? Also filed related issue #606 as a result of that conversation with the engineer.

[blvdmitry]

#606 makes sense, thank you

I don't think there is a specific standard for nested focus trapping but the regular focus trapping requirements apply here:

• if the focus is trapped and you trap it again - it should stay trapped in the new area until that area trap is released
• trapping focus should keep the focus within the trapped area

https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html

Example from there:

A web page implements modal dialogs. When the trigger button is activated, a dialog opens and focus is set within the dialog. As long as the dialog is open, all web page content outside the dialog becomes inert and cannot receive focus (though, depending on implementation, the focus cycle might still include user agent controls). When the dialog is dismissed, focus returns to the button or the element following the button.

[egucciar]

@blvdmitry the confusing part for us is why is the Select we invoke from the popover a "focus trap" if tabbing off defocuses it? Its confusing to have a "trap mode" that lets you just tab-out of it - is that really a trap then? makes me wonder, is the requirement to have the content-menu trap mode just for the ability to bail out of other trap modes like this? :)

[blvdmitry]

That's a good point. Since the beginning of Reshaped we've been using TrapFocus with different modes to keep focus management under the same utility. Technically all additional trap modes go beyond the spec but those are still expected behavior for components like DropdownMenu. I think it works for libraries like base-ui since instead of exposing TrapFocus, they just have components for each trap mode, so you could see Popover and Preview Card as separate components for example.

Previously we were talking about an abstract component with its own portal triggered from the trapped area. If I am to try reproduce this example, would that be a select inside a popover?