Why is this an issue?

Automatically moving keyboard focus to an element when it is rendered or shown, before users have had a chance to get their bearings, can disorient or actively harm them:

Autofocusing a dialog element, an element with a popover attribute, an element with an ARIA dialog or alertdialog role, or any element inside one of these, does not raise this issue: moving focus into a freshly opened modal or popover is expected, and the dialog/popover element itself is a valid autofocus target when it should receive focus as soon as it opens.

Remove the attribute that autofocuses the element, and let the browser’s default focus behavior apply. If an element genuinely needs to receive focus in response to a user action, for example a form opened on demand, move it into a dialog element or a popover container instead of autofocusing it directly when it is rendered or shown.

This rule does not cover non-DOM elements, such as custom components: static analysis cannot tell whether an autoFocus prop on a custom component forwards it to a real DOM element, so this is a limitation of the analysis rather than a compliant pattern to rely on.

Code examples

Noncompliant code example

function SearchForm() {
  return <input autoFocus />;
}

Compliant solution

function SearchForm() {
  return <input />;
}

Autofocusing an element inside a dialog or a popover is compliant:

function SearchDialog() {
  return (
    <dialog>
      <input autoFocus />
    </dialog>
  );
}

Autofocusing the dialog or popover element itself is also compliant:

function SearchDialog() {
  return <dialog autoFocus>...</dialog>;
}

Autofocusing an element with an ARIA dialog or alertdialog role, or an element inside one, is compliant too:

function SearchOverlay() {
  return (
    <div role="dialog" aria-modal="true">
      <input autoFocus />
    </div>
  );
}

Resources

Documentation

Articles & blog posts