SC 4.1.2 Level A WCAG 2.0

Name, Role, Value

Every UI component must expose a name, a role, and — where applicable — a value and state, programmatically. Without this, screen readers, voice control, and switch devices cannot identify or operate the control.

What it asks

Every interactive thing on the page — buttons, links, form fields, tabs, sliders, custom widgets — must expose three pieces of information to assistive technology:

Name — what is this control called? (“Submit”, “Close dialog”, “Volume”)
Role — what kind of control is it? (button, link, checkbox, tab, slider)
Value / state — for components that have one: is it pressed, expanded, checked, selected? What’s the current value?

The exposure has to be programmatic — set in the DOM, not painted on with CSS. Screen readers, braille displays, voice-control software, and switch scanners all read the accessibility tree, not pixels.

How to meet it

Use the native HTML element whenever one exists. <button> ships with the right role, focus, keyboard handling, and an accessible name from its text content — for free.
For icon-only buttons, add aria-label (or visually hidden text). <button aria-label="Close">×</button>.
For form inputs, associate a <label for> with the input’s id. Or wrap the input inside the <label>. Placeholder text is not a label.
When you must build a custom widget out of <div> and <span>, add role="…", manage tabindex, handle Enter and Space, and reflect state with aria-pressed, aria-expanded, aria-checked, aria-selected, aria-valuenow.
Run the rendered page through the browser’s accessibility-tree inspector (Chrome DevTools → Elements → Accessibility) and read each control: every one should announce as name + role + state.

Common failures

<div onclick="…"> styled as a button — no role, no keyboard, no name. Screen readers skip it. Voice control cannot say “click Save.”
<div role="button"> with no tabindex="0", no Enter/Space handler — looks accessible, isn’t.
Icon-only buttons (<button><svg /></button>) with no aria-label, aria-labelledby, or visually hidden text. Announced as a bare “button.”
Custom dropdowns built with <div> and JavaScript, missing role="combobox", aria-expanded, aria-controls, and the listbox/option roles underneath.
Toggle buttons (mute, favorite, follow) that change state visually but never update aria-pressed. Sighted users see the change; screen-reader users hear no difference.
Form inputs with a visual label sitting next to them but no for/id link or wrapping <label>.
Custom checkboxes drawn with <svg> and a hidden native input that never reflects :checked to the visible UI — the screen-reader and visual states drift apart.

Why it matters

This is the most cited SC in the spec. Almost every “this site is unusable with a screen reader” complaint resolves to a 4.1.2 failure somewhere — usually a <div> masquerading as a button, or an icon button with no name. It is also where the cost of building custom widgets shows up: every native HTML control already passes 4.1.2; every hand-rolled <div> widget has to earn it line by line. The fastest 4.1.2 audit is to tab through the page with a screen reader on and listen — anything that announces as “blank” or just “button” is a finding.