Interactive components have accessible name, role, and value

Custom interactive components that lack accessible names, roles, or state expose AT users to components they cannot identify or operate. A screen reader encountering a nameless div with an onClick handler reads nothing useful; a toggle without aria-checked gives no feedback on state. WCAG 2.2 SC 4.1.2 (Name, Role, Value) is Level A — failures break keyboard and AT navigation entirely, affecting users of VoiceOver, NVDA, and JAWS, plus voice control users who activate elements by speaking their visible label.

Prefer native HTML elements that carry implicit semantics. When building custom components, always supply all three ARIA pillars — name, role, and state.

// Custom toggle — explicit role + name + live state
<div
  role="switch"
  aria-checked={isEnabled}
  aria-label="Enable email notifications"
  tabIndex={0}
  onClick={() => setIsEnabled(v => !v)}
  onKeyDown={(e) => {
    if (e.key === 'Enter' || e.key === ' ') setIsEnabled(v => !v)
  }}
/>

// Dropdown trigger — name from visible text + state
<button aria-haspopup="listbox" aria-expanded={isOpen}>
  Sort by
</button>

For every custom component in your codebase, verify it exposes name via aria-label or visible text, role via a semantic element or explicit role=, and relevant state via the matching aria-* attribute.