For a modal dialog, how should a design-system spec choose the initially focused element, and when may closing focus something other than the trigger?

middleshould knowfreq 48%

answer

depends on the content's size and shape
long text: start of content
irreversible action: least destructive
trigger deleted: next logical element

basics

~20 s

Initial focus depends on content: usually the first focusable element, a static title for long or structured content, the least destructive action for irreversible steps. On close, focus returns to the trigger unless it is gone or the workflow continues elsewhere.

solid answer

~50 s

The WAI-ARIA Authoring Practices say focus moves into the dialog on open, generally to the first focusable element, but the right target depends on the content. If the dialog holds several paragraphs, a list or a table, focus a static element at the start, such as the title, so the user can read it in order and nothing scrolls out of view. If the dialog is the last step of something hard to undo, like removing a prescription, it may be advisable to focus the least destructive action. If it only informs or continues, focus the most-used button, such as Continue. On close, focus returns to the element that opened the dialog, with two exceptions: the trigger no longer exists, so focus goes to the next logical element; or the workflow's next step is clearly elsewhere and re-opening is unlikely.

The WAI-ARIA Authoring Practices say focus moves into the dialog on open, *generally* to the first focusable element, but the right target depends on the content. If the dialog holds several paragraphs, a list or a table, focus a static element at the start, such as the title, so the user can read it in order and nothing scrolls out of view. If the dialog is the last step of something hard to undo, like removing a prescription, it may be advisable to focus the least destructive action. If it only informs or continues, focus the most-used button, such as Continue. On close, focus returns to the element that opened the dialog, with two exceptions: the trigger no longer exists, so focus goes to the next logical element; or the workflow's next step is clearly elsewhere and re-opening is unlikely.

code

pseudocode · 13 lines

pseudocode

function initialFocus(dialog):
    if dialog.contentIsLongOrStructured:
        return dialog.titleOrFirstStaticText
    if dialog.completesIrreversibleAction:
        return dialog.leastDestructiveAction
    if dialog.onlyInformsOrContinues:
        return dialog.mostUsedAction
    return dialog.firstFocusableElement

function returnFocus(dialog):
    if dialog.trigger.stillExists and not dialog.workflowContinuesElsewhere:
        return dialog.trigger
    return dialog.nextLogicalElement

go deeper

for a junior

Remember that focus moves into a modal dialog when it opens and goes back to what opened it when it closes.

for a middle

Explain how the APG picks initial focus by content — long or structured text, irreversible steps, informational dialogs — and the two exceptions to returning focus to the trigger.

for a senior

Show you would catch lost-focus bugs, such as a delete dialog whose trigger vanishes, and put fallback targets into the component's default behaviour.

for a principal

Discuss how much of this a shared component can decide by default versus what only the product team knows about its content, and how the spec makes the override explicit.

Why a spec has to decide this

When a modal dialog opens, keyboard and screen-reader users experience it through wherever focus lands. The first thing a screen reader announces, the first thing the Enter key activates, and whether the dialog's opening text is still on screen all follow from that one choice. Leaving it to each implementer produces dialogs that open on the corner close button in one product, on the destructive action in another, and on nothing at all in a third. A design-system dialog spec should therefore state the initial-focus rule per dialog variant, and the return-focus rule for when it closes.

The initial-focus rules from the Authoring Practices

The WAI-ARIA Authoring Practices (APG) dialog pattern says only that focus moves to an element inside the dialog when it opens, and that it is generally the first focusable element. It then lists cases where another target is more appropriate:

Structured content — if the dialog holds lists, tables or multiple paragraphs that would be hard to follow as one unbroken announcement, focus a static element at the start of the content so assistive-technology users can navigate the structure in order.
Long content — if focusing the first interactive control would scroll the beginning of the content out of view, focus a static element at the top, such as the dialog title or first paragraph.
Irreversible final step — if the dialog completes something not easily reversed, such as deleting data or completing a financial transaction, it may be advisable to focus the least destructive action.
Information or continue — if the dialog only informs or moves the process on, it may be advisable to focus the most frequently used control, such as OK or Continue.

The APG also strongly recommends that every dialog's tab sequence include a visible close or cancel control, so there is always an obvious way out.

Applying them in a refill app

Dialog in a pharmacy refill app	Sensible initial focus	Why
Medication warnings, several paragraphs, then Acknowledge	the dialog title	the user must read the warnings in order
Remove this prescription from auto-refill?	Keep prescription (the cancel action)	removal stops future refills and is hard to undo
Refill submitted, ready Thursday	Done	informational; the likely next action is to close
Edit delivery note, one text field	the text field	the first control is the task

The return-focus rule and its exceptions

When the dialog closes, focus returns to the element that opened it, so the user continues from where they were. The APG names two situations where another target is better:

The invoking element no longer exists. Confirming 'Remove prescription' deletes the list row whose button opened the dialog. Focus must go to another element that makes sense in the workflow — the next row, or the list heading if the list is now empty — never be dropped to the start of the screen.
The workflow makes another element more logical, when it is very unlikely the user needs to re-open the dialog immediately and the task completed in the dialog leads directly into a next step. The APG's example is an Add Rows dialog that, on close, focuses the first cell of the first new row.

Focus that is simply lost when a dialog closes is one of the most common failures in audits: a keyboard user presses Tab and restarts from the top of a long screen, and a screen-reader user hears nothing that tells them where they are.

Writing it into the spec

A dialog spec can express these rules as a small decision the component applies by default, with an override for the product team that knows the content:

a default (first focusable element),
a content-aware override (title or opening text for long or structured content),
a risk-aware override for confirmation variants (least destructive action),
a return target that defaults to the trigger and accepts a fallback when the trigger is removed.

Native mobile platforms follow the same model: when a modal alert or sheet appears, screen-reader focus moves into it, usually to its title, and when it is dismissed focus should land back on the control that opened it. The rule the spec writes down is platform-neutral; only the plumbing differs.

## Why a spec has to decide this When a **modal dialog** opens, keyboard and screen-reader users experience it through wherever focus lands. The first thing a screen reader announces, the first thing the Enter key activates, and whether the dialog's opening text is still on screen all follow from that one choice. Leaving it to each implementer produces dialogs that open on the corner close button in one product, on the destructive action in another, and on nothing at all in a third. A design-system dialog spec should therefore state the **initial-focus rule** per dialog variant, and the **return-focus rule** for when it closes. ## The initial-focus rules from the Authoring Practices The WAI-ARIA Authoring Practices (APG) dialog pattern says only that focus moves to an element inside the dialog when it opens, and that it is *generally* the first focusable element. It then lists cases where another target is more appropriate: - **Structured content** — if the dialog holds lists, tables or multiple paragraphs that would be hard to follow as one unbroken announcement, focus a static element at the start of the content so assistive-technology users can navigate the structure in order. - **Long content** — if focusing the first interactive control would scroll the beginning of the content out of view, focus a static element at the top, such as the dialog title or first paragraph. - **Irreversible final step** — if the dialog completes something not easily reversed, such as deleting data or completing a financial transaction, it *may be advisable* to focus the **least destructive** action. - **Information or continue** — if the dialog only informs or moves the process on, it may be advisable to focus the most frequently used control, such as OK or Continue. The APG also strongly recommends that every dialog's tab sequence include a **visible close or cancel control**, so there is always an obvious way out. ## Applying them in a refill app | Dialog in a pharmacy refill app | Sensible initial focus | Why | |---|---|---| | Medication warnings, several paragraphs, then Acknowledge | the dialog title | the user must read the warnings in order | | Remove this prescription from auto-refill? | Keep prescription (the cancel action) | removal stops future refills and is hard to undo | | Refill submitted, ready Thursday | Done | informational; the likely next action is to close | | Edit delivery note, one text field | the text field | the first control is the task | ## The return-focus rule and its exceptions When the dialog closes, focus returns to the element that opened it, so the user continues from where they were. The APG names two situations where another target is better: 1. **The invoking element no longer exists.** Confirming 'Remove prescription' deletes the list row whose button opened the dialog. Focus must go to another element that makes sense in the workflow — the next row, or the list heading if the list is now empty — never be dropped to the start of the screen. 2. **The workflow makes another element more logical**, when it is very unlikely the user needs to re-open the dialog immediately and the task completed in the dialog leads directly into a next step. The APG's example is an Add Rows dialog that, on close, focuses the first cell of the first new row. Focus that is simply lost when a dialog closes is one of the most common failures in audits: a keyboard user presses Tab and restarts from the top of a long screen, and a screen-reader user hears nothing that tells them where they are. ## Writing it into the spec A dialog spec can express these rules as a small decision the component applies by default, with an override for the product team that knows the content: - a **default** (first focusable element), - a **content-aware override** (title or opening text for long or structured content), - a **risk-aware override** for confirmation variants (least destructive action), - a **return target** that defaults to the trigger and accepts a fallback when the trigger is removed. Native mobile platforms follow the same model: when a modal alert or sheet appears, screen-reader focus moves into it, usually to its title, and when it is dismissed focus should land back on the control that opened it. The rule the spec writes down is platform-neutral; only the plumbing differs.

Why not always put initial focus on the close control in the dialog's corner?
It is visible and safe, but the screen reader then announces 'Close' before any content, and the user has to tab past it to reach the task every time. For a single-field dialog the field is the better target; for long text, the title is. The close control should be in the tab sequence, not automatically first.
What should happen to focus if the dialog closes because a background event removed its trigger, such as a refill list refreshing?
The same fallback as a user-initiated delete: move focus to the next logical element, such as the item that now occupies that position or the list heading. The spec should give the dialog a fallback target, because the trigger disappearing is a normal case, not an edge case.

saying these in an interview costs you the question

Initial focus should always go on the close control in the corner.
Focus can stay on the trigger; screen readers will find the dialog anyway.
An irreversible delete dialog should focus Delete so keyboard users confirm quickly.
When the trigger was deleted, returning focus to the top of the screen is fine.
Long dialogs should focus their first button even if the opening text scrolls away.

For a modal dialog, how should a design-system spec choose the initially focused element, and when may closing focus something other than the trigger?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Why a spec has to decide this

The initial-focus rules from the Authoring Practices

Applying them in a refill app

The return-focus rule and its exceptions

Writing it into the spec

▾common follow-ups2 questions

▾red flags5 flags

Why a spec has to decide this

The initial-focus rules from the Authoring Practices

Applying them in a refill app

The return-focus rule and its exceptions

Writing it into the spec

answer

go deeper