Name, role, value
The identity, type, and current state a control exposes so assistive technology can understand and operate it.
See it
What it is
Name, role, value is the information assistive technology needs to understand and operate a control. The name identifies it ('Email alerts'), the role says what kind of thing it is ('switch'), and its state, properties, or value say what is true now ('on', 'expanded', '50 percent'). WCAG 4.1.2 also requires changes to that information to be available to assistive technology.
Native HTML exposes most of this automatically. A labeled checkbox already has a checkbox role and checked state; a select exposes its chosen option. Reach for ARIA when building a widget with no suitable native element, and mirror each real state change with properties such as aria-expanded, aria-selected, aria-checked, or aria-valuenow.
Gotcha: ARIA can only report behavior, not create it. A div with role='button' is still missing keyboard handling, and a custom switch whose aria-checked value never updates lies to the accessibility tree. Prefer the native control, then test the computed name, role, and state while operating it.
Ask AI for it
Audit every interactive element against WCAG 4.1.2 Name, Role, Value in the Chrome DevTools accessibility tree. Replace custom controls with native button, input, select, and details elements wherever they match the behavior. For each remaining custom widget, provide an accessible name and the correct ARIA role, expose its live state with properties such as aria-expanded, aria-selected, aria-checked, or aria-valuenow, and update those properties in the same event that changes the visual state. Add the keyboard behavior required by that widget's WAI-ARIA Authoring Practices pattern. Return a table showing name, role, state or value, and how each change is exposed through accessibility APIs.