Accessibility Interview Talking Points

WCAG-minded talking points for FE interviews — focus, names, keyboard, ARIA, and how to answer a11y questions without buzzwords.

intermediate4 min readUpdated Aug 4, 2026

interview
accessibility-interview

Accessibility rounds are not a quiz on every ARIA role. Interviewers want proof you design keyboard-first, compute accessible names, and fix failures with a model — not “add aria-label everywhere.”

Pair this map with Keyboard accessibility checklist and WCAG POUR.

What interviewers score

Semantics first — native elements before ARIA
Focus — trap, restore, visible indicators
Names & states — how screen readers announce controls
Practical testing — keyboard path + one SR pass
Tradeoffs — custom widgets cost; when you pay it

Mental model (say this out loud)

POU R: Perceivable, Operable, Understandable, Robust. For UI interviews, map product bugs to those buckets:

Failure	POUR angle	Fix direction
Icon-only button, no name	Perceivable / Robust	Visible text or `aria-label` from purpose
Modal traps mouse only	Operable	Focus trap + Esc + restore
Error only in red border	Perceivable	Text + associate with field
Custom dropdown, no keyboard	Operable	Tab stop, arrows, typeahead
`div` button	Robust	Prefer `<button>`

Question table — core

Topic	Can you…	Learn
Accessibility tree	Explain vs DOM; what SR reads	Accessibility tree
Accessible name	Compute name from content / label / aria	Accessible names
Focus management	Open modal → focus first control → restore	Focus management
Focus visible	`:focus-visible` vs removing outlines	Focus-visible styles
Keyboard checklist	Tab order, no keyboard traps	Keyboard checklist
ARIA roles	When role is required; when harmful	ARIA roles overview
Labels / descriptions	`aria-labelledby` vs `aria-describedby`	ARIA labels
Live regions	Polite vs assertive; don’t spam	ARIA live regions

Prompt: “Build a modal.” Strong answer covers focus trap, Esc, backdrop click policy, return focus, and labelled dialog — see Accessible modals and Machine coding modal.

Patterns they love to probe

Pattern	Must-haves	Learn
Forms	Label association, error text, `aria-invalid`	Accessible forms
Tabs	Arrow keys, `aria-selected`, roving tabindex	Accessible tabs
Combobox	Expand/collapse, listbox, active option	Combobox pattern
Menus	Arrow nav, Escape closes	Menus
Tables	Headers, scope; don’t fake grids in divs	Accessible tables

Contrast, motion, touch

Topic	Can you…	Learn
Contrast	4.5:1 text intuition; large text rule	Color contrast
Color alone	Status not only red/green	Don’t rely on color alone
Reduced motion	Respect `prefers-reduced-motion`	Reduced motion
Touch targets	~44px class targets on mobile	Touch targets
Skip links	Bypass repeated chrome	Skip links

Testing angle (short answer)

Keyboard only through critical path
axe / automated — catch low-hanging fruit; know limits
One screen reader (VoiceOver / NVDA) on the hardest widget
CI — fail on new serious issues when team maturity allows

Automated tools miss focus order, name quality, and “does this make sense.”

Out-loud answers (steal the shape)

Q: When do you use ARIA?
“When HTML cannot express the control. ARIA does not add behavior — I still implement keyboard and focus. Prefer native button, dialog, details.”

Q: Why not outline: none?
“Users who tab need a visible focus ring. Use :focus-visible so mouse users stay clean without abandoning keyboard users.”

Q: How do you make a custom select accessible?
“Often I don’t — native select is better. If design forces custom: button + listbox, aria-expanded, active descendant or option focus, typeahead, and Escape.”

Footguns

Decorative icons announced as “image” — empty alt / aria-hidden
aria-label overriding visible label (mismatched SR vs sighted)
Positive tabindex reordering hell
Live region on every keystroke
Color contrast failing on placeholders and disabled-looking-but-clickable UI