Frontend UI Interviews: Build Accessible Components Under Time

In a UI interview, the fastest way to impress is to ship a small thing that works and then level it up. Think in this order: MVP → keyboard support → sensible styles → basic errors. Keep progress visible and narrate your steps so the interviewer can follow your thinking.

The prompt (typical)

Most UI rounds start with a small, self-contained widget. Common asks:

• Modal dialog with confirm / cancel
• Dropdown that supports keyboard navigation
• Autocomplete with a filtered list and selection
• Tabs that switch content panels

We’ll use a compact Confirm Dialog as the running example. Your goal is the same for any prompt: get a working MVP first, then add keyboard support, reasonable styles, and basic error handling.

Markup first: the minimum skeleton

<button id="openBtn">Delete file…</button>
<div id="dialog" role="dialog" aria-modal="true" aria-labelledby="dlgTitle" hidden>
  <div class="overlay"></div>
  <div class="panel" role="document">
    <h2 id="dlgTitle">Delete this file?</h2>
    <p id="dlgDesc">This action cannot be undone.</p>
    <div class="actions">
      <button id="cancelBtn">Cancel</button>
      <button id="confirmBtn">Delete</button>
    </div>
  </div>
</div>

Styles: readable, not pixel-perfect

#dialog[hidden] {
  display: none;
}

#dialog .overlay {
  position: fixed;
  inset: 0;
  background: rgba(0,0,0,.5);
}

#dialog .panel {
  position: fixed;
  top: 10%;
  left: 50%;
  transform: translateX(-50%);
  width: min(520px, 90%);
  background: #0f1218;
  border: 1px solid rgba(255,255,255,.12);
  border-radius: 12px;
  padding: 16px;
}

#dialog .actions {
  display: flex;
  gap: 8px;
  justify-content: flex-end;
}

:focus-visible {
  outline: 2px solid #60a5fa;
  outline-offset: 2px;
}

@media (prefers-reduced-motion: reduce) {
  * { animation-duration:.01ms !important; transition-duration:.01ms !important; }
}

State & interactions: keep it tiny

const dialog = document.getElementById('dialog') as HTMLElement;
const openBtn = document.getElementById('openBtn') as HTMLButtonElement;
const cancelBtn = document.getElementById('cancelBtn') as HTMLButtonElement;
const confirmBtn = document.getElementById('confirmBtn') as HTMLButtonElement;

let lastFocus: HTMLElement | null = null;

function open() {
  lastFocus = document.activeElement as HTMLElement;
  dialog.hidden = false;
  confirmBtn.focus(); // send focus into dialog
}

function close() {
  dialog.hidden = true;
  lastFocus?.focus(); // restore focus
}

openBtn.addEventListener('click', open);
cancelBtn.addEventListener('click', close);
confirmBtn.addEventListener('click', () => {
  // pretend to delete...
  close();
});

// Close on Escape
document.addEventListener('keydown', (e) => {
  if (!dialog.hidden && e.key === 'Escape') close();
});

Accessibility checklist (fast)

Accessibility isn’t extra credit in UI interviews — it’s correctness. Here’s a quick list you can run through in under a minute:

• Semantics: Always label your dialog with role="dialog", aria-modal="true", and a clear title via aria-labelledby. This tells assistive tech what the UI is.
• Focus: When the dialog opens, send focus inside (usually the primary button). On close, restore focus to wherever the user was. Hint: interviewers love seeing you save lastFocus.
• Keyboard: Escape should close. Tab and Shift+Tab should cycle through the dialog controls. If asked, add a simple focus trap.
• Visible focus: Don’t remove outlines. If styling, use :focus-visible so keyboard users keep a clear highlight.

📌 Mentioning these out loud in the interview shows maturity — you think beyond “does it work for me” and into “does it work for everyone”.

Performance & polish (optional)

Once your core UI works, polish is where you can stand out — but only if you have time left. Think of these as quick wins, not mandatory steps:

• Avoid layout trashing. Batch DOM reads and writes instead of mixing them, and never animate width or left (causes reflows). ✅ Animate transform or opacity instead — smoother and cheaper.
• Respect user settings. Wrap animations in @media (prefers-reduced-motion: reduce). This shows empathy and signals you know accessibility extends to motion too.
• Keep helpers tiny. Only extract utility functions if duplication actually appears. Premature abstraction wastes precious interview minutes.
• Visual clarity over perfection. Basic spacing, readable text, and visible focus outlines matter more than pixel-perfect alignment. Interviewers notice usability first.

💡 Tip: Mentioning “I’d optimize animations with transform” or “I’d add @media (prefers-reduced-motion: reduce)” often gets bonus points, even if you don’t have time to implement it fully.

Debug checklist (when things go weird)

Bugs under a timer feel 10× worse. What interviewers care about isn’t whether you avoid every mistake — it’s whether you can spot, explain, and fix issues without spiraling. Use this quick checklist:

• Log state changes: Check if hidden is actually flipping and which element currently has focus. Simple console.log beats guessing.
• Verify selectors & targets: A wrong ID or missing class can sink you. Use closest() to confirm you’re grabbing the right element.
• Test edge paths: What happens if you press Escape before the dialog is open, or click outside the overlay? Show you think about odd cases.
• Talk it out: Narrate your steps: “I expect this state to be true, but it’s false — so my next step is to log the click handler.” Even if you don’t fix it instantly, interviewers will see structured thinking.

🔑 Rule of thumb: debug out loud. Silence feels like being stuck, but walking through your reasoning shows control — and often earns hints.

Practice prompts (30–45 min each)

Drill these in the coding practice area: start with a working MVP, then add keyboard and a11y. Narrate what you’re doing.

Remember

Ship first, then improve. A small, working dialog with keyboard support beats a half-written “perfect” solution every time. Keep progress visible, talk through trade-offs, and you’ll score higher than most candidates.