[Bug]: Dialog: There are no focusable elements inside the <FocusTrap />

What package within Headless UI are you using?

@headlessui/react

What version of that package are you using?

1.0.0

What browser are you using?

Chrome

Reproduction repository

https://codesandbox.io/s/gallant-butterfly-wnxjb

Description

When there is no focusable element inside modal, it fails with error There are no focusable elements inside the <FocusTrap />. I don’t know if it’s a feature or a bug, but there isn’t said in the documentation that Dialog must include at least one focusable element and I totally see a use-case when there are modals without any focusable element. I think it at least should fail with warning instead of fatal error.

Anyways I would like to thank you for the great job you all are doing with the tailwind ecosystem, we really appreciate your work!

[Krystofee]

@adamwathan what you are saying is that “There should be at least one focusable element in the modal.” and I agree with that.

What I don’t agree with, is the way it’s enforced. You cannot throw an error because of accessibility reasons. By doing that, you are putting accessibility before reliability, which means that you will have fully accessible software which will crash all the time or not even boot. I believe software must be fully reliable before one start dealing with accessibility.

I don’t understand the reasons behind this decision, and it’s also because I haven’t seen any UI framework enforcing accessibility via throwing errors. And going even further, if I notice that some of the hundreds of dependencies in our project throws an exception, I just go to the project github and report a bug, because most of the time it’s a bug.

And even if it was intentional, it’s not documented and users will have to read through the code and will eventually create a Bug report like this one.

[cortopy]

I’d like to add another use case where forcing the existence of a focusable element on initial render is troublesome.

I have a Dialog wrapped by a Transition with very complex animations set dynamically for root and children. Also animations may or may not run depending on context.

This is leading to many errors due to the fact that Dialog may try to focus before it should (i.e.: animations are not done and not all elements are mounted yet). This is very painfully when developing the animations, since elements may get removed due to HMR

Like others have said, I think a warning should be enough. Even when React detects something dodgy, it warns the developer rather than throw, panic and make everything failed.

Not having a focusable element is bad for accessibility. In fact, I do know my Dialog is accessible because eventually (a matter of milliseconds) there will be a focusable element. But the Dialog component cannot know that, and a escape hatch would be nice to have