RFC: [ngx-inform] Priority system for modals

[IbenTesara]

Authors: @IbenTesara @DenisValcke
Package: ngx-inform
Posted: 25 september 2024
Status: Open

In version v18.2.0ngx-informwe added the ability to create WAI-ARIA/WCAG compliant modals. This modal system currently only allows one modal to be open at all times, as per the accessibility guidelines. When trying to open a new modal when a modal is currently visible, we log a warning in the console why a new modal isn't opened.

A possible issue we see here is that developers might not notice that a modal isn't opened and a warn can easily be missed. We therefor want to look if we want to keep this approach, or move to another approach.

Our initial questions

1. Do you like the current approach where only modal can be opened at a time and a second modal isn't opened? If so, why (not)?
2. Is there a need to be able to open multiple modals at once, in a way that is still WCAG compliant? If so, why (not)?
3. In our proposal below we are looking at a priority based system. Do you like this approach? If so, why (not)?
4. Do you have a different proposal than us?

Our proposal

One possible solution would be to introduce a priority system to the modal. If a newly opened modal has priority over the current opened modal, this modal becomes the active modal. The current modal is closed, and the modal with isPriority: true gets rendered instead.

Possible side-effects

As every modal creates an Observable which results in a subscription to handle the side effects, closing a prior active modal can have unwanted side-effects.

Possible solution

A possible solution to this problem could be to instead introduce a number-based priority system in which modals are put in a queue based on the priority they have. An additional component could be provided to visualize that there are multiple modals waiting in the queue

Our questions

1. If we work with a single priority system, what happens to the closed modal? Is there need for a specific action to be emitted so potential side-effects can be avoided?
2. If we work with a queue based priority system, is a component to visualize the remaining modals required?
3. If we work with a queue based priority system, do we close the current modal and reopen it later if a higher priority modal gets opened, or do we stay with a FIFO principal for the initial modal opened, with the rest of the modals being part of the proposed queue system?

[IbenTesara]

My personal take:

Is there a need to be able to open multiple modals at once, in a way that is still WCAG compliant? If so, why (not)?

Although I personally don't see a specific use-case in which I would need it, I could see the use of it.

In our proposal below we are looking at a priority based system. Do you like this approach? If so, why (not)?

Yes, but only when we used queue based approach, as to avoid possible side effects.

If we work with a queue based priority system, is a component to visualize the remaining modals required?

I do think a visualization component should be provided in terms of configuration on application level. If modals are queued, the end user should know that once they close a modal, another modal will open.

If we work with a queue based priority system, do we close the current modal and reopen it later if a higher priority modal gets opened, or do we stay with a FIFO principal for the initial modal opened, with the rest of the modals being part of the proposed queue system?

Not only to avoid possible side effects, but also from a user experience I think the existing modal should always be kept open, regardless of whether a more high-priority modal is triggered. Once more modals are triggered, the highest-priority modal should be opened first afterwards.