Modal previous Focus

[arecesj]

Hey y'all,

Was wondering anyone here had extensive knowledge of using the useRef hook and the modal references? the issue Im coming across is:

• I set a ref for the Text Area component called textAreaRef. When I focus on that component w/ onFocus attribute for the Text Area, I check for a specific case. If that case is true, I trigger the modal (woo! This is great and expected behavior).
• However, when I click Cancel or the X for the modal and if I set textAreaRef.current.blur() to take the focus away from TextArea, the focus goes right back on it and triggers the modal again! (booo!)
• I also tried setting another element to focus but it seemed like the modal overwrote me :(

Please let me know if I'm making some incorrect assumptions here or if there's a more Pasty way of going about it. Thanks in advance for your time!

Juan

[gloriliale]

Hi @arecesj!

Thanks for your question. To make sure we're getting to the bottom of this behavior in particular, could you please send us a recreation of it in a CodeSandbox? That way we'll know we're looking at exactly what's going awry with the focusing. Many thanks!

[arecesj]

kachow! https://codesandbox.io/s/loving-snow-3rgou7?file=/src/index.tsx

[arecesj]

Some notes from our internal chat:

• I don't see this bug if in the codeSandbox the Modal is in the same file as the rest of the code, however, when abstracted, we start seeing an issue.
• Unfortunately, that's not the situation internally. I tried that internally and it didn't work :/ still the same issue

[gloriliale]

Hi @arecesj!

In the Codesandbox, it doesn't seem like there's anything that opens the modal- is there something missing or is there some way that it opens that I've missed?

I also realized that you said the bug manifests in the Codesandbox when the Modal is not in the same file as the rest of the code, but in this example it looks like it's not abstracted. Could you modify it so that it's in that non-working state?

Feel free to send the link to your source internally as well if it's not working to replicate it in Codesandbox!

[arecesj]

Hello @gloriliale! To trigger the behavior, click on the TextArea field. That will have the modal pop up (as it triggers the onFocus callback) then the Modal pops up. When I click cancel on the modal, the document.activeElement goes back to the TextArea even though I try to blur it with the reference (and the it pops up the modal again and starts the loop).

Sorry, maybe I misspoke by saying abstracted. I meant that I created a new component called DummyModal to show the behavior.

Here it is with the DummyModal made into its own component://codesandbox.io/s/loving-snow-3rgou7?file=/src/index.tsx

Let me know if you still can't see it!

[gloriliale]

@arecesj ah actually, could you elaborate more on what the user flow is for this? What's the context of this interaction, what's in the modal, where in their journey users are at this point, etc.

[gloriliale]

If you'd like @arecesj , we still have Office Hours slots open this week- that way you could give us a rundown on your flow. Sign up here!

[arecesj]

Hey @gloriliale - sounds good. I've added myself and @tiwong-ln2 to the office hours. Thanks so much!

[shleewhite]

Thank you for coming to office hours @arecesj!

Here is a summary of what we talked about:

This is actually intended behavior for the Modal component because it is really important for accessibility to not move the user's focus around the page without them explicitly asking to move focus.

There is a very strict rule for accessibility auditors that the user's focus cannot be automatically moved when they focus on a form element. This is because it is really jarring for the user to have to figure out where they are now and how to get back to what they were doing.

For modals, the way they are supposed to work is that there is a button that a user can choose to click which opens the modal and their focus goes to the first element inside. When they are done with the modal, they can close it and their focus returns to the button that opened it so they know exactly where they are and can continue what they are doing. If you want to read more, the ARIA Authoring Practices (who define how common UIs should work to be accessible) has great documentation: https://www.w3.org/WAI/ARIA/apg/patterns/dialogmodal/.

Currently, your UI is creating a focus trap where the modal opens when the user focuses the text area and when they close the modal it tries to refocus the text area because that is what opened it, but that instead causes the modal to open again.

For your use case, it would be much better if this validation happened when the user attempts to save the form. They would press save, get the modal about adding sample data, then have the opportunity to fix the issues, and then try to save again when they are ready.

Please let me know if you have any other questions!

[arecesj]

Thanks for having us and helping us out!