Focus Announcement and Context

Screen readers typically announce a focused control using its accessible name, role, current state, and relevant context. Good frontend accessibility ensures that this information is available programmatically without requiring users to infer it visually.

When keyboard focus moves to a control, a screen reader exposes information derived from the accessibility tree. A useful announcement generally identifies what the element is, what it is called, and important state such as `checked`, `expanded`, `disabled`, or selected status.

Context matters when the control's meaning is not obvious from its own name. For example, a button named `Delete` may need surrounding context such as the item being deleted, while a group of radio buttons should expose the group relationship and the currently selected option. Semantic HTML often provides these relationships automatically.

Accessible names should be concise and specific. Native elements such as `<button>`, `<input>`, `<select>`, and `<a>` usually provide reliable roles and interaction semantics, whereas custom widgets require careful use of ARIA roles, states, properties, and relationships.

Dynamic interfaces also need to preserve useful focus context. When content changes or a dialog opens, focus should move deliberately when appropriate, and the newly focused element should have an accurate accessible name and state. Avoid forcing focus changes merely to make a visual update noticeable; use mechanisms such as live regions when the information is an announcement rather than a new interaction target.

Key points

• Focus announcements depend on the accessibility tree, not just visible text.
• Use semantic HTML to provide reliable roles and states whenever possible.
• Give interactive controls specific, concise accessible names.
• Expose relationships and surrounding context when the control's meaning depends on them.
• Manage focus deliberately after dialogs, navigation, and other major UI changes.

Interview questions

How would you debug a confusing screen-reader announcement?

First inspect the browser's accessibility tree to determine the element's computed role, accessible name, state, and relationships. Then check the DOM for labeling, nesting, and ARIA attributes, while testing actual keyboard focus order. I would reproduce the issue with a representative screen reader and browser combination because announcement wording can vary. I would prefer correcting the underlying semantics over adding announcement-specific text as a workaround.

What information does a screen reader generally need to announce when a control receives focus?

The control should expose an accessible name and an appropriate role, along with important current state. Depending on the widget, that can include whether it is checked, expanded, selected, disabled, or has a value. Relevant grouping or descriptive context may also be exposed. Native HTML is often the simplest way to provide these semantics.

How would you make several Delete buttons understandable to a screen-reader user?

Each button should have an accessible name that identifies the item it acts on, such as `Delete report Q3`. The visual UI can still display only `Delete` if the additional identifying text is provided accessibly. Another approach is to structure each item so its heading and action have a clear semantic relationship. The key is that the focused button should not be indistinguishable from every other Delete button.

When should you move focus after a dynamic UI change?

Move focus when the user's interaction has logically transitioned to a new interaction context, such as opening a modal dialog. Do not move focus simply because some background content changed. For informational updates that do not require interaction, a live region may be more appropriate. After moving focus, the destination should have a meaningful name, role, and state.

Why is semantic HTML important for focus announcements?

Semantic elements carry standardized roles, states, keyboard behavior, and relationships that assistive technologies can interpret through the accessibility tree. A native button, for example, already communicates that it is a button and supports expected interaction behavior. A custom clickable `div` requires developers to reproduce much more behavior and semantics correctly. ARIA can supplement semantics, but it does not automatically supply the full interaction model of a native control.