Focus management is the accessibility thing everyone forgets

There's a version of an accessible interface that passes every automated check, uses the right ARIA roles, has correct contrast ratios, and is still completely unusable with a keyboard.

Focus management is how you get there.

Automated accessibility checkers look at the DOM snapshot. They can tell you if an element has the right role, if an image has alt text, if color values meet contrast thresholds. They can't tell you where focus goes after a modal closes, whether a form error is reachable by Tab navigation, or whether the focus order on a dynamically updated page makes any sense.

What goes wrong in dynamic interfaces

Static pages have manageable focus problems. Tab order follows the DOM, skip nav links handle the navigation, and there aren't many ways for focus to land somewhere unexpected.

Dynamic interfaces are different. Elements appear and disappear. Panels open and close. Content loads asynchronously. Errors surface in response to user actions. Every one of those state changes is an opportunity for focus to land somewhere useless.

The most common failure: a modal opens and focus stays on the element that triggered it. The user presses Tab and moves to whatever comes after the trigger in the DOM. Usually not inside the modal. They're interacting with content behind an overlay they can't see.

The second most common: a modal closes and focus goes to the top of the page. The user was somewhere in the middle of a workflow and has now lost their place entirely.

The third: a form error appears after submission and focus stays on the submit button. Screen reader users have no indication that anything happened. They can't find the error without tabbing through every field.

What correct focus management looks like

When a modal opens, focus moves to the first interactive element inside it or to the modal container itself. Tab is trapped inside the modal while it's open. When it closes, focus returns to the element that opened it.

When an inline error appears, focus either moves to the error message or the error message is associated with the field via aria-describedby so it reads automatically when the user reaches the field.

When content loads asynchronously, like search results populating or a confirmation message appearing, the focus decision depends on context. If the user triggered the load and expects new content, consider moving focus to it. If the content loads in the background, use aria-live to announce it without moving focus.

Getting this into your process

Focus management decisions don't exist in a design file. You can annotate the intended behavior, but the annotation has to be explicit: "when this modal opens, focus moves to the close button," not "handles focus appropriately."

The gap is usually that focus behavior isn't specified at all. Engineers make reasonable assumptions. The assumptions sometimes match what a keyboard user needs and sometimes don't. A focused annotation on a handful of interaction patterns (modals, drawers, error states, async loading) closes most of the distance.

That annotation is design work. It belongs in the component spec, not as an afterthought in a handoff comment.