# Restoring Focus After Async Validation

An asynchronous check — “is this username taken?”, “is this address deliverable?” — can finish after the user has already moved on. What should happen to focus then? If the code focuses the field it checked, the user is yanked back mid-sentence in another field; if it does nothing, a screen reader user may never learn the check failed; if the component re-renders while waiting, focus can vanish entirely. This recipe sets clear rules: an async result never moves focus while the user is typing elsewhere, it is announced politely and attached to its field with aria-describedby, focus is moved only as part of a submit that the user initiated, and focus is restored deliberately after any re-render that destroys the focused element. Submission still goes through reportValidity() from the Constraint Validation API, which handles the focus move when the user is ready for it.

# When Focus After Async Validation Needs Care

Any form with a check that takes longer than a keystroke runs into this:

• On-blur availability or lookup checks, which complete after focus is already in the next field.
• Submit-time async checks, where the submit handler must wait before calling reportValidity().
• Framework re-renders during pending states, which replace inputs and drop focus.
• Background revalidation — a draft checked every few seconds — which must never move focus at all.

The check mechanics — debouncing and cancelling stale requests — are covered in cancelling stale requests with AbortController. This page is only about focus and announcement once results arrive. The general rules for focus after failure are in managing focus after validation failure.

# Minimal Working Focus-Safe Async Validation

const form = document.querySelector<HTMLFormElement>("#signup")!;
const live = document.querySelector<HTMLElement>("#form-live")!;          // role="status"
const pending = new Map<HTMLInputElement, Promise<void>>();

function announce(text: string): void {
  live.textContent = "";
  requestAnimationFrame(() => (live.textContent = text));
}

function showFieldError(field: HTMLInputElement, message: string): void {
  field.setCustomValidity(message);
  field.setAttribute("aria-invalid", String(Boolean(message)));
  const out = document.getElementById(`${field.id}-err`)!;
  out.textContent = message;
  out.hidden = !message;
}

async function checkUsername(field: HTMLInputElement, signal: AbortSignal): Promise<void> {
  const res = await fetch(`/api/usernames/available?u=${encodeURIComponent(field.value)}`, { signal });
  const { available } = await res.json();
  const message = available ? "" : "That username is taken. Try adding a number or your initials.";
  showFieldError(field, message);

  // Rule 1: never move focus because a background check finished.
  // Rule 2: if the user is elsewhere, tell them — politely — which field has a problem.
  if (!available && document.activeElement !== field) {
    announce(`Username: ${message}`);
  }
}

const username = form.querySelector<HTMLInputElement>("#username")!;
let controller: AbortController | undefined;
username.addEventListener("blur", () => {
  controller?.abort();
  controller = new AbortController();
  pending.set(username, checkUsername(username, controller.signal).catch(() => {}));
});

// Rule 3: focus moves only when the user asks for it — on submit — after pending checks settle.
form.addEventListener("submit", async (event) => {
  event.preventDefault();
  const button = event.submitter as HTMLButtonElement | null;
  button?.setAttribute("aria-disabled", "true");
  await Promise.all(pending.values());               // wait for in-flight checks
  button?.removeAttribute("aria-disabled");
  if (form.reportValidity()) form.submit();          // focuses the first invalid field, including async ones
});

The result of the check is placed on the field (custom validity, message, aria-invalid) but focus is left wherever the user is. If they are still on the field, the message is read as part of its description the next time they explore it, and the visible message appears next to it. If they have moved on, a single polite announcement names the field so they know to go back. When they submit, reportValidity() takes them there.

# Focus Rule Reference

# Verification Steps

• Type a taken username, tab to the email field and keep typing: focus stays in email; a screen reader announces the username problem once.
• Return to the username field: its message is read as part of the field’s description.
• Type a taken username and press Enter immediately: the submit waits for the check, then focus moves to the username field.
• Trigger a re-render during the pending state: focus remains on the same logical field.
• Slow the network to 3 s: no focus jumps occur while typing in other fields.

import { test, expect } from "@playwright/test";

test("async failure does not steal focus from another field", async ({ page }) => {
  await page.route("**/api/usernames/available*", async (r) => {
    await new Promise((res) => setTimeout(res, 800));
    await r.fulfill({ contentType: "application/json", body: JSON.stringify({ available: false }) });
  });
  await page.goto("/signup");
  await page.getByLabel("Username").fill("ada");
  await page.getByLabel("Email address").focus();
  await page.keyboard.type("ada@example.com");
  await expect(page.locator("#username-err")).toHaveText(/taken/);
  await expect(page.getByLabel("Email address")).toBeFocused();
  await expect(page.getByRole("status")).toContainText("Username:");
});

# Edge Cases and Failure Modes

Focusing the field in the callback. field.focus() inside the check’s .then() is the classic bug. It interrupts whatever the user is doing, and on mobile it reopens the keyboard for a different field. Remove it; focus belongs to submit.

Re-renders that drop focus. Frameworks that render a spinner in place of an input, or re-key a component while a check is pending, destroy the focused element and focus falls to the body. Keep the input mounted during pending states (show the spinner beside it), or record the focused element’s id before the update and restore it after.

const focusedId = document.activeElement?.id;
await rerender();
if (focusedId && !document.activeElement?.id) document.getElementById(focusedId)?.focus({ preventScroll: true });

Announcing every result. A success announcement for every field that passed an async check becomes noise. Announce failures when the user is elsewhere; announce successes only when they answer a question the user is waiting on, such as availability.

Submitting while checks are pending. Without awaiting pending checks, reportValidity() runs before the result lands and the form submits a taken username. Await them, and set a “Checking…” custom validity while pending so a submit cannot slip through.

# Pending States That Keep Focus Stable

While a check runs, the field needs a pending indicator — a spinner or “Checking…” text — and how that indicator is added decides whether focus survives. Add it beside the input, in the status element referenced by aria-describedby, never by swapping the input for a loading component. Set aria-busy="true" on the field’s wrapper rather than on the input itself, and keep the input enabled; disabling a focused input during a check blurs it, which on mobile closes the keyboard and on desktop drops keyboard users back to the page. When the result arrives, clear the pending text and aria-busy in the same update that writes the verdict, so assistive technology never reports “busy” and “invalid” at the same time.

# Focus Management in Framework Components

In React, Vue and Angular, the rules are the same but the failure mode is more common, because async state changes trigger renders. Keep the rules explicit in the component: store the async result in state, render the message from it, and do not call .focus() in the effect that reacts to the result. Call focus only in the submit handler, after awaiting the pending validations the form library tracks — React Hook Form’s handleSubmit awaits async validators before calling setFocus-driven error focusing via shouldFocusError; VeeValidate and Angular Reactive Forms similarly expose a pending state to await. Verify with a slow network in development; focus bugs in async flows are nearly invisible on a fast connection. The library-specific async validation guides are React Hook Form async field validation and Angular async validator with HTTP checks.

# Related Guides

• Focus Management & Keyboard Navigation — the overall focus rules.
• Managing Focus After Validation Failure — focus on submit.
• Implementing Async Email Availability Checks — the checks whose results this handles.
• Asserting aria-live Announcements in Playwright — testing the announcement.

← Back to Focus Management & Keyboard Navigation