Debug Accessibility interaction model

BrokenSidePanel reproduces the keyboard failure mode (no role, no focus management). SidePanel fixes the contract: role=dialog, focus trap, Escape close, focus restore.

// Symptom: a "side panel" pattern is keyboard-broken. Mouse users can open,
// edit, and close it; keyboard users can open it but Tab cycles to the
// (visually hidden) page behind, Escape does nothing, and after closing,
// focus lands at the top of the document instead of the trigger.

// BROKEN version uses a div as a button, no role, no labelled relation,
// and no focus management. Mouse-only thinking.
function BrokenSidePanel({ open, onOpen, onClose }: {
  open: boolean;
  onOpen: () => void;
  onClose: () => void;
}) {
  return (
    <div>
      <div onClick={onOpen} className="trigger">Open settings</div>
      {open && (
        <div className="panel">
          <div onClick={onClose}>X</div>
          <p>Settings body</p>
          <button>Save</button>
        </div>
      )}
    </div>
  );
}

// FIXED version names the role, manages focus deterministically, traps Tab
// inside the dialog, restores focus on close, and labels the panel for
// screen readers. The exact same mouse path still works.
type SidePanelProps = {
  open: boolean;
  onClose: () => void;
};

export function SidePanel({ open, onClose }: SidePanelProps) {
  const dialogRef = React.useRef<HTMLDivElement | null>(null);
  const previousFocusRef = React.useRef<HTMLElement | null>(null);
  const titleId = React.useId();

  React.useEffect(() => {
    if (!open) return;
    previousFocusRef.current = document.activeElement as HTMLElement | null;
    const dialog = dialogRef.current;
    if (!dialog) return;

    const focusable = dialog.querySelectorAll<HTMLElement>(
      'a[href], button:not([disabled]), input:not([disabled]), [tabindex]:not([tabindex="-1"])'
    );
    (focusable[0] ?? dialog).focus();

    function onKey(event: KeyboardEvent) {
      if (event.key === 'Escape') {
        event.preventDefault();
        onClose();
      } else if (event.key === 'Tab') {
        if (focusable.length === 0) {
          event.preventDefault();
          dialog.focus();
          return;
        }
        const first = focusable[0];
        const last = focusable[focusable.length - 1];
        if (event.shiftKey && document.activeElement === first) {
          event.preventDefault();
          last.focus();
        } else if (!event.shiftKey && document.activeElement === last) {
          event.preventDefault();
          first.focus();
        }
      }
    }

    document.addEventListener('keydown', onKey);
    return () => {
      document.removeEventListener('keydown', onKey);
      previousFocusRef.current?.focus();
    };
  }, [open, onClose]);

  if (!open) return null;

  return (
    <div
      ref={dialogRef}
      role="dialog"
      aria-modal="true"
      aria-labelledby={titleId}
      tabIndex={-1}
    >
      <header>
        <h2 id={titleId}>Settings</h2>
        <button type="button" onClick={onClose} aria-label="Close settings">
          ×
        </button>
      </header>
      <p>Settings body</p>
      <button type="button">Save</button>
    </div>
  );
}

Convert the answer into observable behavior. In a mid-senior interview, say which behaviors are covered by unit tests, interaction tests, accessibility checks, and one browser smoke path.

import { describe, it, expect } from 'vitest';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

function Host() {
  const [open, setOpen] = React.useState(false);
  return (
    <>
      <button type="button" onClick={()=> setOpen(true)}>Open settings</button>
      <SidePanel open={open} onClose={()=> setOpen(false)} />
    </>
  );
}

describe('SidePanel a11y', ()=> {
  it('exposes role=dialog with aria-modal and an accessible name', async ()=> {
    const user= userEvent.setup();
    render(<Host />);
    await user.click(screen.getByRole('button', { name: /open settings/i }));
    const dialog = screen.getByRole('dialog', { name: /settings/i });
    expect(dialog).toHaveAttribute('aria-modal', 'true');
  });

  it('moves focus into the dialog and restores it on close', async () => {
    const user = userEvent.setup();
    render(<Host />);
    const opener = screen.getByRole('button', { name: /open settings/i });
    await user.click(opener);
    const close = screen.getByRole('button', { name: /close settings/i });
    expect(close).toHaveFocus();
    await user.keyboard('{Escape}');
    expect(opener).toHaveFocus();
  });

  it('Tab cycles inside the dialog, not to the dimmed page', async () => {
    const user = userEvent.setup();
    render(<Host />);
    await user.click(screen.getByRole('button', { name: /open settings/i }));
    await user.tab();
    expect(screen.getByRole('button', { name: /save/i })).toHaveFocus();
    await user.tab();
    // Wraps back to the close button, not to the host's Open settings.
    expect(screen.getByRole('button', { name: /close settings/i })).toHaveFocus();
  });
});

Shows whether you understand accessibility interaction model as an operating model, not as memorized trivia.

• Use one concrete browser or React-facing example.
• Name the failure mode a production user would notice.
• Keep the first answer under two minutes before expanding.

• Start with the rule: focus, names, descriptions, landmarks, and live regions.
• Tie the rule to ownership: what runs in render, what runs after paint, what is external state, and what must be cleaned up.
• Close with the smallest test, trace, or code review check that would catch the bug.

• A short interview answer is easier to follow, but a senior answer must still name the edge case.
• Framework vocabulary helps only after the browser or language rule is clear.

• Slow devices where timing bugs become visible.
• Repeated user actions before async work settles.
• Browser defaults that differ from custom component behavior.

• Unit-test the pure decision when possible.
• Use an interaction test for focus, keyboard, timing, or cleanup behavior.

• How would this change in a React component?
• What would you log or profile if this broke in production?