[Modal] focus-wrapping feature prevents user from using stacked modal

What package(s) are you using?

• carbon-components
• carbon-components-react

Detailed description

focusTrap previously allowed users to opt out of this feature and effectively manage their own focus. When upgrading to carbon-components v10.10.3, a minor version from previous, this prop was both deprecated and the functionality was removed. This breaks the contract of semantic versioning and, as a result of consuming this change, breaks applications relying on this functionality.

This change also produces a bug where secondary modals (eg. Confirmation or error dialogs) are unable to receive focus once trapped.

Is this issue related to a specific component?

Modal

What did you expect to happen? What happened instead? What would you like to see changed?

I expect existing API to only be removed on major version changes and deprecation warning to happen before features are removed completely.

What version of the Carbon Design System are you using?

10.10.3

What offering/product do you work on? Any pressing ship or release dates we should be aware of?

This effects a few products in IoT org.

[joshblack]

Just to chime in with the comments above, definitely agreed that we want to make the barrier to using components from Carbon as minimal as possible. To this goal, we try to introduce components and aspects of the IBM Design Language in the smallest slices that we can while still providing consolidated entry points for convenience.

For the Design Language, this manifests itself with individual packages for color, type, layout, etc. These all get rolled up into elements and also get initialized in carbon-components. This helps teams who can only use aspects of the DL, but not all of it, to still stay connected to the ecosystem.

Similarly, for components, we try to slice this with styles and behavior. We definitely recognize that behavior may not align 1:1 with what we can implement or support, but are happy to provide the building blocks which we use to provide the behavior for these components.

An example of this could be DataTable where we provide functionality for sorting, filtering, selection, etc. out-of-the-box. However, teams can choose not to use DataTable directly and can use the associated presentational components for constructing their own DataTable component that works for their use-case.

In both cases, we try and present the smallest units we can offer that we use ourselves to build up components. Sometimes this ideal falls apart though and we try and rectify it. The hope is that folks can interop at any particular meaningful stage and I hope we can find a similar solution for Modal in this case that doesn’t block any particular use-case from being satisfied 👍

Based on the above, it seems like providing appropriate presentational components that don’t manage focus explicitly would be sufficient?

[aagonzales]

What would be the guidance for doing things conditionally in modals. For instance, you open a modal to send some data to a server. You hit submit, the application runs some validations that may or may not require the user to perform additional actions (eg. "Doesn’t match formatting rules, proceed?). You want the user to be able to confirm his decision or go back to the modal form and change some things.

If your task required a modal for confirmation then that first modal should be its own page and not a modal itself. One modal should never trigger another modal. It is a bad ux pattern.

Sometimes these scenarios occur because of legacy design and I’m not sure what the solution should be for that. But if this is a new design or a redesign then the scenario should be re-designed without nesting modals.

Modal task should be clear and simple enough that you don’t need an extra confirmation to complete the task.

We recommend that any validation in a modal be done inline for this reason. See docs https://www.carbondesignsystem.com/components/modal/usage#validation https://www.carbondesignsystem.com/components/modal/usage#loading https://www.carbondesignsystem.com/patterns/dialog-pattern#when-not-to-use