Frontend accessibility basics — what every interview expects you to know

Three layers of accessibility, in priority order:

1. Semantic HTML. Use the right element. <button> is keyboard-operable, focusable, and announces as "button" to a screen reader for free. <div onClick> requires re-implementing all of that and almost always misses something.

2. ARIA — only as needed. ARIA describes widgets that HTML can't (combobox, tabs, dialog). The first rule of ARIA is: don't use ARIA. The second is: if you must, follow the WAI-ARIA Authoring Practices patterns exactly. A wrong role is worse than none.

3. Keyboard + focus. Every interactive element must be reachable with Tab and operable with Enter/Space (and Esc / arrows where appropriate). Visible focus indicators are required (don't outline: none without an alternative). Manage focus on route change and modal open/close.

Other essentials:

• Labels. Every input has a <label> (clickable target) or aria-label.
• Color contrast. ≥ 4.5:1 for body text, 3:1 for large text and UI.
• Don't rely on color alone — pair status with icons / text.
• alt on every image; empty alt="" for decorative.
• Live regions (aria-live="polite") for async updates so screen readers announce them.

Test with: a keyboard only, VoiceOver / NVDA, axe-core (CI), Lighthouse. Lived experience on assistive tech beats any audit tool.