Make a complex component accessible by design

WHAT THIS TESTS The interviewer is probing whether you treat accessibility as a first-class design problem for custom widgets, where no semantic HTML element exists to lean on. Complex visualizations and drag-and-drop are exactly where naive ARIA fails.

A GOOD ANSWER COVERS Begin with the user goal, not the visuals: what must a keyboard-only or screen reader user actually accomplish. Define a keyboard interaction model explicitly: how focus enters the widget, which keys operate it (arrow keys to move between data points or list items, Enter to activate, Space to pick up a draggable, Escape to cancel), and how focus exits. Specify a logical focus order and visible focus indicators. Map the widget to an ARIA Authoring Practices pattern where one exists, assigning roles, states, and properties, and decide what the screen reader announces on focus and on change, including live-region updates for dynamic results. For drag-and-drop, provide a keyboard-operable alternative such as cut and paste semantics or a move-to menu, because pointer dragging is inaccessible alone.

COMMON WRONG ANSWERS Adding ARIA roles to a finished visual without defining behavior. Assuming a screen reader will narrate a canvas chart. Offering no non-pointer way to reorder items. Over-applying ARIA so it conflicts with native semantics.

LIKELY FOLLOW-UPS How do you make a canvas or SVG chart accessible, for example with a hidden data table. How do you announce live updates without spamming the user. How do you test with an actual screen reader. How do you handle focus management after a drop.

ONE CONCRETE EXAMPLE For a Kanban drag-and-drop board, you document that Space picks up a card, arrow keys move it between columns and positions, Enter drops it, and Escape cancels. A live region announces moved card to In Progress, position two of five. You hand engineers a spec table listing each role, key binding, ARIA state, and the exact announcement string.