Focusing on load interrupts a screen reader’s document order

What it is

Putting focus into a field as soon as the page opens makes a screen reader start speaking from that field; the title, the lead, and an error summary ahead of it are skipped. That is load-time autofocus interruption. Sighted users may want to type at once; people who depend on document order lose the opening of “what page is this.” The issue is speak-order at arrival, not whether a dialog should take focus, and not a jump mid-typing.

Why it happens

A screen reader treats DOM order as a story: document title, then heading, then lead, then the first control. autofocus or a load-time focus() drops the insertion point into the middle of the story; virtual cursor and browse mode are pulled into edit mode, and earlier nodes might as well not have happened. A keyboard user who still wants the instructions must Shift+Tab backward, and many implementations keep those instructions out of the focus order, so there is nothing to climb to. The cost is small when the page is one slot everyone knows to fill; it is large on settings, on an application with a long lead, and on a refresh that just showed errors—error text often sits before the slot, focus is already in the slot, the error is never heard.

Studying it

Open the same page with and without load autofocus under a screen reader; record whether document title, heading, lead, and first field are spoken, and in what order. Factors: autofocus versus delayed scripted focus, placement of an error summary. Outcomes: whether the page’s purpose can be restated before the task starts, whether errors are heard. A sighted control group measures “can the first key type immediately”—a different outcome; do not let that speed advantage veto the order loss. A refresh that carries server errors is a required condition.

Where it stops holding

A true single-field tool (a popped find bar, a login page that is only a password) often should autofocus; there is almost no prior prose to interrupt. A single-page-app route change is not a full load and still performs the same focus drop; treat it as the same interruption. The browser chrome and extensions may also grab focus on load; author autofocus will fight them. Cutting autofocus is not “never focus”; a dialog opening is a different rule.

Applying it

• Do not use autofocus or an immediate focus() on load of an ordinary multi-field page.
• Let the screen reader start at the document and main heading; send focus to a page-top error summary when an immediate correction is needed, not into a slot.
• Treat load focus as an exception only on single-field, purpose-obvious tool pages.
• Verify by opening the page with a screen reader and listening to the start before any key. If title and lead are skipped and speech goes straight to “edit text,” load focus is interrupting order. Repeat with a server-error refresh.

Related

• Within the group: E2.22.2 Autofocus fits a single, obvious primary field · E2.22.3 A dialog should take focus on open and return it on close · E2.22.4 A focus jump nobody asked for interrupts typing in progress
• Adjacent: E2.01 Single-line text fields · E4.10 Modal dialogs
• Search terms: load-time autofocus interruption · screen reader order · autofocus