The autofocus issue

[andyearnshaw]

I know a lot of appeals for this problem have gone unheeded in #6629. I'm hoping to start a reasoned discussion about it, as I believe the current warning is actually harmful for a11y in 2026.

Background

The Svelte compiler will warn you if you include the autofocus attribute on any element.

<input autofocus>
<!--   ^ "autofocus bad" (not actual warning message) -->

One exception is when the element is a descendant of a <dialog> element, thanks to #16341:

<dialog>
  <input autofocus> <!-- ok! -->
</dialog>

Unfortunately, this doesn't work for component composition:

<MyStyledDialog>
  <MyCustomInput /> <!-- MyCustomInput.svelte will get the warning if it applies autofocus -->
</MyStyledDialog>

Descendents of elements with the popover attribute will always display the warning.

Svelte's weird relationship with autofocus

Svelte actually includes some logic to call element.focus() on mount:

/**
 * @param {HTMLElement} dom
 * @param {boolean} value
 * @returns {void}
 */
export function autofocus(dom, value) {
	if (value) {
		const body = document.body;
		dom.autofocus = true;

		queue_micro_task(() => {
			if (document.activeElement === body) {
				dom.focus();
			}
		});
	}
}

So, Svelte's position on autofocus is flawed: on the one hand, it tells you not to use it and, on the other hand, it helps you if use it. My first suggestion would be to deprecate this logic and remove it in Svelte 6. Here's why:

1. It's not needed for the valid autofocus use cases: top-layer components (currently popovers and dialogs) will handle autofocus correctly
2. It's extremely easy to implement this logic in an $effect() rune
3. Svelte should not encourage the use of autofocus on non-top-layer elements

The warning

My personal preference is that the warning would go away. Dialogs and popovers with interactive content absolutely should have an element with autofocus. It would actually be better if Svelte could warn when this isn't the case (but I know that would be quite complicated to implement). I also think that, as a developer, I should not receive—and have to go out of my way to disable—warnings for what is essentially a good practice.

If it helps, <dialog> attained universal browser support in 2022, popover in 2024. There are options for progressive enhancement implementations of these. It no longer makes sense to flatly discourage all uses of autofocus.

If the warning is here to stay, then I think the documentation should be updated to tell the developer to disable the warning and use autofocus on descendants of <dialog> or <xyz popover>. It should not tell them they are doing something wrong for their legitimate use cases.

[brunnerh]

Dialogs and popovers with interactive content absolutely should have an element with autofocus. It would actually be better if Svelte could warn when this isn't the case

Not really. You only need it if you want to change the element that should receive focus, dialogs already automatically focus the first interactive element.

The piece of JS is required for pages that are created on the client since autofocus will not have an effect otherwise.

That certain warnings are prone to false positives with component nesting is an old issue. If I remember correctly it used to happen a lot with label/input relationships until it was disabled for labels that contain components (i.e. assuming that the component probably contains the relevant input). But since this is the other way around, with the warning being on the inside, the warning cannot be suppressed conditionally while keeping component analysis isolated.

Some of these warning just need to be suppressed manually.

[andyearnshaw]

Not really. You only need it if you want to change the element that should receive focus, dialogs already automatically focus the first interactive element.

This is not true for popovers, though. And changing the autofocus element could be quite common in dialogs, for instance where you have an X button to close in the dialog header but you want to focus the first form element instead.

The piece of JS is required for pages that are created on the client since autofocus will not have an effect otherwise.

But we're telling devs that using autofocus for this is bad. So the piece of JS is not really required, because it's essentially a footgun that you're handing to developers. It's not required for dialogs or popovers and, as I said before, it's easy enough to implement with $effect.

Some of these warning just need to be suppressed manually.

I just think that forcing developers to use comment directives to mark legitimite code has a pretty bad smell to it. I would do it in TypeScript or ESLint only as an absolute last resort.

Would you at least agree that the warning message is incorrect? Currently, it doesn't give the developer the correct advice about usage.

[brunnerh]

Yes, the message could be better and point out legitimate use cases and when a false positive might be triggered that can be ignored.