Discussion for v4 of react-modal

[diasbruno]

First, thanks for all the support through the years...reporting and answering issues, or submitting PRs. You guys are great.

I try my best to find time to help improve this package, but I can't do it alone...

I have a dream to finally release version 4 for react-modal, but I didn't have a good goal to invest time to push it forward.

The goals for v4:

1. Remove from the API everything that can disable accessibility

It would be better to have a more stable releases without breaking accessibility.

2. Fix the bogus default behavior related to hide the application.

The default is to apply the aria-hidden attribute to the document.body. But this hides everything

This will require the user to explicitly define the element(s), using its id or class or element, using Modal.setAppElement().

To normalize the API, Modal.setAppElement() and appElement={} must use arrays to keep the API simple.

3. Deprecate ariaHideApp

This is an unnecessary flag, this behavior can be archived by passing [] to Modal.setAppElement() and appElement={}. But it shouldn't be recommended.

4. Deprecate shouldFocusAfterRender={boolean}

The modal must always gain focus and trap (correctly).

5. Replace shouldReturnFocusAfterClose={boolean} with returnFocusTo={Element}

This can be an element that will gain focus after the modal is closed.

The default behavior is to return the focus to the element on document.activeElement before open the modal, but...in some browsers, this behavior is broken so we can't always trust it. So, the user can pass to this attribute an element that must receive the focus later.

6. Review all additional systems that react-modal uses (see helpers folder)

This package manages a lot of state (like open instances, styles classes added to external elements, focus system...)

---

With this goals in mind, the API will be less flexible to disable the features related to accessibility, which should not be a problem, but maybe some users will not see this a gain...So, I decided to start a discussion before moving forward with this...

I'll let this open until the end of Jun, and if the feedback is positive, I'll set up the project so everybody can participate!

Thanks,
Dias

[TusharShahi]

Point 5 gives the developer good control over choosing accessibility options and should help with browsers like Safari. But the default behaviour is definitely easier and in a way auto enables accessibility.

With the new approach, developers will have to take the responsibility of managing focus in all places. Might I suggest to keep the default behaviour as is, and only override it if the user has explicitly mentioned the prop. Since, in most browsers returning focus to activeElement will work, it will lead to less code for the users and they can choose to pass the element where they find the default functionality breaking.

[diasbruno]

@TusharShahi

Might I suggest to keep the default behaviour as is,...

Problem is that it will be required anyways, because of the browser issue (if I recall correctly this is an safari/iOS issue - not sure if it was already fixed or not).

I'd prefer this design, even if document.activeElement could be the default, because in order to do the right thing in all browsers the user will have to deal with it anyways...

<Modal returnFocusTo={document.activeElement} ... />

[TusharShahi]

@TusharShahi

Might I suggest to keep the default behaviour as is,...

Problem is that it will be required anyways, because of the browser issue (if I recall correctly this is an safari/iOS issue - not sure if it was already fixed or not).

I'd prefer this design, even if document.activeElement could be the default, because in order to do the right thing in all browsers the user will have to deal with it anyways...

<Modal returnFocusTo={document.activeElement} ... />

Ah, you are absolutely correct. This will be the ideal prop.
But, is the reason for this only the safari/ios issue? If yes, can we not fix it somehow?

[bvellacott]

Hi guys,

Sorry I'm late to the discussion, but can you let me know how these objectives relate this pr I created in your oppinion #876 ?

It's purpose is to provide a way to disable the focus- and tabtrap on a modal. The need stems from accessibility concerns in the applications our teams are developing and is also touched in this conversation #799.

[diasbruno]

But, is the reason for this only the safari/ios issue? If yes, can we not fix it somehow?

On safari/iOS when you click on a button, the browser don't register the button as document.activeElement. So, we'll have this blind spot if we default to activeElement.

Found it:
react-modal #389

[diasbruno]

@bvellacott In your case, you have a very particular UX problem and it's in conflict with the guidelines for accessibility on modals. It seems that react-modal is not best component that fits your needs. Sorry.

It's hard to get the accessibility right, on normal browsers and the accessible ones, so we are adding unnecessary complexity by allowing to disable those features.

We can accept #876, but you will be stuck on versions 4-.

[bvellacott]

@diasbruno understood - sounds like we'll have to go with that then.