don't auto focus first element on x-trap

[samuelbirch]

Is there a way to stop the auto focus of the first element when using x-trap?

[SimoTod]

It's not possible at the moment but the plugin uses "focus trap" which does support it. If you have a valid use case, you can try to submit a PR.

[dfallman]

I'm having the same issue. I don't so much mind the first element being auto-focused, but when (in my case) I use it with Tailwind's focus: and focus-visible: (which is CSS' :focus-visible) it's triggering the focus-visible, not the focus, as if the focus has been set manually using the keyboard. Surely this can't be the right/expected behavior?

[james0r]

Same here. I've usually handled this by just focus-visible:tw-outline-none which isn't ideal for a11y. What approach are you using now?

[dfallman]

Same thing usually, or in cases where there are logical options to place focus (e.g if there’s an input field that makes sense to auto-focus) I’ll do that instead.

My problem is pretty much all my modals have a title top left and a close X button top right (which TBH I’m probably not the only one who has). If I put that in a normal flex box the X gets auto-selected as it’s the first focusable object. This isn’t always a problem but it is usually a bit visually awkward. So either I do what you say and sort of hide the focus (which isn’t at all ideal from an accessibility point of view) or — which I think is better — I position the X in the same place but use absolute positioning further down in the page’s hierarchy.

This makes it not be interpreted as the first focusable object, so it’s pretty handy if you have an input field that gets automatically focused.

I think this is (somewhat) better from an accessibility point of view as the X is still focusable and also visually so, but it does break the perhaps expected tabbing order, but hey.

[james0r]

Ya but if you move it down the list, whatever is now first will still take the outline right? For me it's usually the X too. Trapping mobile menus.

[dfallman]

Yes it’s the same, but it’s easier to hide in a visually pleasing way with an input field than an X button :)

[ekwoka]

I've mainly just made the X not be the first, but instead the last item in the modal.

[richcarni]

PR #3977

[ekwoka]

There is kind of an issue, in that without this focus, the next tab may go into the browser UI and not the website at all, or somewhere else entirely if you aren't using inert.

[richcarni]

In my testing (chrome), the tabbing behaves as I'd expect it to. After the focus trap, the first (keyboard) tab sets focus to the first tabbable element in the trap container

It does, however, break the flow of focus in terms of accessibility. For example, used to create a modal, if the modal is opened by clicking a button, focus doesn't transition from the button to an element inside the modal - at least not in a way that something like a screen reader can follow. Focus is trapped inside the modal, but a click or tab is necessary to see this

For my use case, in which I don't want the first input in my modal to automatically receive focus, I've decided a better solution is to use autofocus and tabindex="-1" attributes on the title element of my modal