deprecate focusTrapDisabled property

[Elijbet]

Description

Deprecate the focusTrapDisabled property.

Modal and Sheet add a scrim that makes it difficult to see where we are tabbing outside of these components. Removing the prop would help avoid this issue.

The prop was introduced for consistency, but there seems to be no clear reason why the focus-trap would need to be disabled on modal or sheet.

Related to: 6456

Which Component

modal, sheet

Resources

No response

[macandcheese]

Should we do the same for Sheet?

[Elijbet]

Should we do the same for Sheet?

Looks like it's the same visibility issue with the scrim, so yeah.

[driskull]

I think we should do the same for popover, and components that uses popover internally. Ideally, all of our components use focus trapping.

If we deprecate this property, we can rely on focus-trap (trapStack) to handle the stack for our "open" components. We could also use the escapeDeactivates property on focus-trap to handle closing the correct component when the escape key is pressed or alternatively we can use the stack to handle closing the correct component ourselves. Since our component stack is already a public config, it allows other component libraries to share the same stack.

cc @jcfranco

[driskull]

Actually, we still need focusTrapDisabled for popover because that component is used internally for the action-menu in cases where its using active-descendant and shouldn't receive focus. So there are still some internal use cases for disabling the focus trap.

Maybe we should keep this prop for any component that would be used inside another.

[geospatialem]

Spike needed to determine any refinements and considerations across components and the design system.

[Elijbet]

As per group discussion we won't be addressing focusTrapDisabled on modal, as it's up for deprecation.

It also makes sense to offer support for focusTrapDisabled for sheet, as the intent of the components could differ. At least until we can collect more concrete examples or use cases pro or against that approach.

@Kitty @franco @skye @aaron @driskull

Also shared here: fix(input-date-picker, modal, sheet): closes on escape when focusTrap is disabled #10578

Next steps:

• dialog with modal: no support for focusTrapDisabled

  • Technically we don't offer this in dialog currently so this is and once modal is removed we're good to go

• dialog: offer focusTrapDisabled depending on workflows

  • New attr/prop, not enabled by default

  • Example of where this is useful, a cookie page dialog that mentions cookie tracking, but the user can still interact with the page without acknowledgement/acceptance

• input-date-picker / input-time-picker: offer focusTrapDisabled depending on workflows

  • Not enabled by default

  • We already offer this, so no action needed if we agree on the approach

  • It could make sense depending on what the user is implementing in their UI/Ux

  • #10690 is a follow-up issue to determine next steps for input-date-picker and input-time-picker with regards to offering the ability to disable focusTrap.

[github-actions]

cc @geospatialem, @brittneytewks