Accessibility Basics for Frontend Interviews

30‑second interview answer

Web accessibility means building interfaces usable by everyone, including keyboard-only and screen-reader users. The basics: semantic HTML, keyboard navigation, visible focus states, correct labels, and minimal ARIA (only where necessary). If it works with keyboard and screen reader, it’s usually accessible.

---

The 5 essentials interviewers expect

1. Keyboard

• Everything interactive must be reachable via Tab
• Enter/Space activates controls

2. Focus states

• Focus must be visible (don’t remove outlines without a replacement)

3. Semantics

• Use button, a, label, headings, landmarks

4. Labels & names

• Inputs need labels
• Buttons need accessible names

5. Contrast

• Text should have sufficient contrast

---

Common a11y mistakes

• Click handlers on <div>s
• Missing <label for>
• Placeholder used as label
• No focus ring
• Bad ARIA (“aria-label” everywhere without semantics)

---

ARIA quick primer (safe interview stance)

• Use ARIA when you build custom components.
• Keep ARIA states accurate:
  • aria-expanded
  • aria-controls
  • aria-selected

Don’t use ARIA to pretend a div is a button unless you implement full keyboard behavior.

---

Practical checklist: dropdown menu

If you build a dropdown:

• focus goes to trigger button
• opening moves focus into menu (or keeps on trigger, but keyboard works)
• Escape closes
• Up/Down navigates items

---

Mini Q&A

Q1: Fastest a11y improvement?

• Semantic HTML + focus styles.

Q2: Why is placeholder not a label?

• It disappears, not read consistently, harms usability.

Q3: What’s your ARIA philosophy?

• Native first; ARIA for gaps.

---

Summary checklist

• Everything works with keyboard.
• Focus is visible.
• Labels exist.
• Contrast is OK.
• ARIA used only when needed.