Feature request: the ability to turn off the error altogether about focus-trap HOT 6 CLOSED

@jamesplease Glad this library is useful for you!

How about adding a try-catch around the initialization? That seems to me as good as setting an option.

One question about your use case: If the dropdown is empty, where do you want focus to go?

from focus-trap.

How about adding a try-catch around the initialization? That seems to me as good as setting an option.

I'm using the React bindings, so it's not clear to me where I would add that try-catch. Would it be best if I forked that library and added the try-catch myself?

One question about your use case: If the dropdown is empty, where do you want focus to go?

Good question! Because there are no elements that the user can activate, I am thinking that it follows that nothing be focused, and for tabbing to do nothing.

To close the dropdown, users can either hit Escape or Enter on their keyboard, or click outside of it. Then, after it is closed, I am manually returning the focus to the previously-focused item after the FocusTrap'd element is closed.

Maybe that's a little odd, though. Perhaps I'll propose a change to the UX where the dropdown is disabled when there are no items, and the explanation for the disabled state is provided in a tooltip on hover. For now, that explanation for the empty list is provided when the dropdown opens up.

from focus-trap.

Because there are no elements that the user can activate, I am thinking that it follows that nothing be focused, and for tabbing to do nothing.

I'm not sure that nothing be focused is a good user experience to aim for. That leaves the keyboard user stranded in outer space, right? So I guess I'm still not convinced that it's a good idea to create a focus trap without a focusable element — still think that's probably an error that should be recognized as such.

from focus-trap.

I'm not sure that nothing be focused is a good user experience to aim for.

I agree that it's questionable 🙂

That leaves the keyboard user stranded in outer space, right?

In my particular situation, it doesn't. From my earlier comment:

"To close the dropdown, users can either hit Escape or Enter on their keyboard"

still think that's probably an error that should be recognized as such.

Perhaps. My bar of throwing errors is pretty high, and even higher for React components, where the developer can sometimes effectively lose all control over being able to try/catch it altogether, as in the case of the Focus Trap react wrapper.

It is interesting, because in my particular situation the dropdown represents dynamic processes, and the options available to the user may come and go depending on what is happening elsewhere (the options available are kept in sync with the server). So it is possible that you could open a dropdown with 3 options, but then, if you sit there long enough, it drops to 0.

Perhaps the UX to go with here does two things:

1. Lets the user know that there are no actions to take
2. Provides a button to close the dropdown, and that is what takes the focus

from focus-trap.

Perhaps the UX to go with here

Yeah, I think that this error represents an accessibility problem to be addressed rather than avoided. Every time this request has come up so far that seems to have been the case.

from focus-trap.

Whats interesting to me is that native selects behave pretty similarly to the UX I first described in this issue.

To reproduce, create a native select without any options, and open it. Click Tab and observe that it is trapped, but it behaves as if nothing is selected (although it is likely the select itself that is focused). Note: I only tested this in Safari on macOS.

Anyway, it is pretty clear to me that unmounting a React app (or a section of a React app) due to focus is never a good idea, so if you’re not open to any PRs to make adjustments I’ll go ahead and create a fork that’s more safe to use in React apps.

Thanks for the good discussion @davidtheclark !

from focus-trap.