Card 1 of 20
Front. Modal Entry. A modal contains several paragraphs and a destructive action. Where should initial focus go?
These cards are original study material. They are not questions from a named employer or a live hiring loop.
All 20 cards in this deck
1.Modal Entry
A modal contains several paragraphs and a destructive action. Where should initial focus go?
Choose a meaningful starting point, often a heading or introductory element that can receive programmatic focus, rather than automatically focusing the destructive action. Preserve readable content order.
2.Modal Exit
Where should focus return after a modal closes if its opening button was deleted by the action?
Move it to a logical surviving location in the workflow, such as the next item or list heading. Returning focus to a removed node leaves keyboard users without a useful position.
3.Modal Semantics
Why does adding aria-modal=true not make a custom dialog modal?
ARIA communicates semantics; it does not implement focus containment, background inertness, or dismissal. Implement and test those behaviors or use suitable native dialog functionality.
4.Tabs Latency
When is manual activation preferable to automatically activating a tab as arrow keys move focus?
When loading a panel has noticeable latency. Let arrows move focus and Enter or Space activate, so users can navigate the tab list without repeatedly waiting for content.
5.Roving Focus
Why does a composite tab list commonly expose only one tab in the page's Tab sequence?
Tab enters or leaves the widget, while arrow keys navigate its items. Roving tabindex implements this distinction; every item being tabbable makes page navigation unnecessarily long.
6.Button Link
Should a control that opens a local settings dialog be a link or a button?
Use a button because it performs an action. Use a link with a real destination for navigation, preserving browser behaviors such as opening in a new tab.
7.Icon Name
How should an icon-only Delete button expose its purpose without announcing the icon twice?
Give the button an accessible name such as Delete invoice and hide a purely decorative icon from assistive technology. Verify the computed name in the accessibility tree.
8.Label Visible
Why should an accessible name include the control's visible label?
Speech-input users often refer to the words they see. A completely different aria-label can make the control difficult to operate and can override useful visible text.
9.Placeholder
Why is placeholder text an inadequate sole label for a form field?
It disappears after entry and may not provide a reliable persistent name or instruction. Associate a visible label and keep necessary format guidance available.
10.Error Association
What should connect an invalid field to its specific correction message?
A programmatic description relationship, such as aria-describedby, with an appropriate invalid state. State what failed and how to fix it; color alone is insufficient.
11.Error Summary
After a long form fails validation, how can a summary help keyboard and screen-reader users?
Provide a clear error summary with links to affected controls, and a deliberate announcement or focus strategy. Preserve entered values and keep field-level explanations available.
12.Async Status
A save finishes without moving focus. How can the result be announced?
Update an appropriate live status region with concise completion text. Avoid repeatedly announcing the whole page or moving focus away from the user's current task.
13.Aria Disabled
Does aria-disabled=true prevent a click handler or keyboard activation from running?
No. It exposes a state, but application code must enforce disabled behavior. Native disabled controls have different focus and interaction behavior; choose based on the intended workflow.
14.Aria Hidden Focus
Why is a focusable button inside aria-hidden=true content a serious mismatch?
Keyboard focus can reach a control removed from the accessibility tree. Remove the interactive subtree from interaction or manage visibility and focus consistently.
15.Focus Obscured
A sticky footer completely covers the focused submit button. What should the layout ensure?
The focused control must remain visible when reached by keyboard; adjust scrolling space, placement, or overlays. A visible focus outline elsewhere does not solve an obscured target.
16.Visual Order
Why can CSS visual reordering make a form confusing even when every control is keyboard accessible?
Tab and reading order generally follow DOM order. Keep a meaningful source order aligned with the visual task sequence rather than repairing it with positive tabindex values.
17.Virtualized Focus
What must a virtualized list do when scrolling would unmount the focused row?
Preserve or deliberately relocate focus and maintain usable navigation semantics. Test keyboard and screen-reader traversal; rendering fewer nodes must not silently strand the active item.
18.Zoom Reflow
What should be tested when a responsive form is zoomed substantially?
Readable reflow, reachable controls, no clipped instructions, and usable focus order. Check real zoom and narrow layouts; a desktop screenshot cannot establish accessibility.
19.Reduced Motion
How should a progress animation respond to a reduced-motion preference without losing useful status?
Reduce or remove nonessential motion while retaining text or another stable indication of progress and completion. The preference is not a reason to hide information.
20.Manual Check
Why does a clean automated accessibility scan not prove a custom combobox is accessible?
Tools cannot fully judge keyboard interaction, useful labels, focus recovery, or announcement timing. Exercise the full task with keyboard and representative screen-reader/browser combinations.