Accessibility in React

The plain-language idea

A <div onClick={...}> styled to look exactly like a button is not a button to a screen reader or a keyboard user — it has no button role, isn't focusable by default, and doesn't respond to Enter/Space. Accessibility in React starts with the same rule as plain HTML: use the semantic element that already has the behavior you need, and only reach for ARIA attributes when no native element fits.

// ❌ looks like a button, isn't one to assistive tech or the keyboard
<div className="button" onClick={submit}>Submit</div>

// ✅ real button: focusable, keyboard-operable, correct role, for free
<button className="button" onClick={submit}>Submit</button>

Managing focus is a React-specific responsibility

When a modal opens, or a route changes, or an item is deleted from a list, focus doesn't move itself — if you don't explicitly move it, a keyboard/screen-reader user can be left with focus on an element that's no longer visible or meaningful.

useEffect(() => {
  if (isOpen) dialogRef.current?.focus();  // move focus into the modal on open
}, [isOpen]);

<div onClick={submit}>Submit</div> — looks like a button. Tab to it? A keyboard can't even reach it.

BackNext

What people usually miss

Watch out

• onClick alone excludes keyboard users if it's on a non-interactive element — a div with onClick needs role="button", tabIndex={0}, and a manual onKeyDown handler for Enter/Space to be genuinely keyboard-operable; a real <button> needs none of that.
• Conditionally rendered content needs an announcement, not just a visual change. A validation error that appears below a field should use aria-live (or role="alert") so a screen reader announces it — otherwise it's invisible to anyone not looking directly at that spot on screen.
• alt text and label association aren't optional extras — an <img> with no alt, or an <input> with no associated <label>, are two of the most common real accessibility failures, and both are one-line fixes.

Why this matters in interviews

"How would you make this custom dropdown accessible?" tests real, practical knowledge — keyboard operability, focus management, and ARIA roles — not abstract awareness that "accessibility matters."