If your website has buttons, forms, menus, dropdowns, or interactive components, WCAG 4.1.2 applies to you.
In this WCAG Fix It guide, we’re breaking down one of the most technical-sounding, yet critically important accessibility requirements: ensuring that interactive elements have a proper, programmatically defined name, role, and value.
It sounds developer-heavy burut at its core, it’s about one simple thing:
When someone uses assistive technology, does your website clearly communicate what an element is and what it does?
And if the answer is no, the experience breaks down fast.
What Is WCAG 4.1.2?
WCAG 4.1.2 – Name, Role, Value requires that for all user interface components:
- The name (what it’s called) is programmatically determinable
- The role (what type of element it is) is defined
- The value (its current state or setting) is communicated
This ensures assistive technologies like screen readers can correctly interpret and announce interactive elements.
This applies to:
- Buttons
- Links styled as buttons
- Dropdown menus
- Toggle switches
- Sliders
- Form fields
- Custom components
If assistive tech can’t identify what something is, users can’t use it properly.
What Do Name, Role, and Value Mean?
Let’s break it down simply.
Name
The accessible label of the element.
Example:
A button that visually says “Submit” must have an accessible name of “Submit.”
Role
The type of component.
Examples:
- button
- checkbox
- slider
- dialog
If you build a clickable <div> that acts like a button but don’t define its role, screen readers won’t know it’s a button.
Value
The current state.
For example:
- A checkbox: checked or unchecked
- A toggle: on or off
- A dropdown: selected option
If the state changes, assistive technology must be notified.
The Human Impact of Missing Name, Role, or Value
Imagine navigating a website using a screen reader.
You tab to a control. The screen reader announces:
“Button.”
That’s it. No name. No purpose or worse, nothing at all.
Now you don’t know:
- What the button does
- Whether it’s expandable
- Whether it’s on or off
- Whether you successfully activated it
Interactive elements without accessible names create confusion. Custom-built components without proper roles create barriers. When users can’t understand controls, they lose independence and when they lose independence, they leave.
Common WCAG 4.1.2 Failures
Here’s what we typically see when scanning websites:
- Clickable <div> elements used instead of proper buttons
- Icon-only buttons without accessible labels
- Custom dropdown menus missing ARIA roles
- Form inputs without associated labels
- Toggle switches not announcing state changes
- Dynamic content that updates visually but not programmatically
All of these can fail WCAG 4.1.2.
How to Fix Name, Role, Value Issues
Use Native HTML Elements Where Possible
Instead of:
<div onclick=”submitForm()”>Submit</div>
Use:
<button type=”submit”>Submit</button>
Native HTML elements automatically include correct roles and behaviours.
This is the simplest and strongest fix.
Ensure Every Interactive Element Has an Accessible Name
Bad:
<button><i class=”icon-search”></i></button>
Better:
<button aria-label=”Search the website”>
<i class=”icon-search”></i>
</button>
The aria-label provides a programmatic name.
Associate Form Labels Properly
Bad:
<input type=”email”>
Better:
<label for=”email”>Email Address</label>
<input type=”email” id=”email”>
This ensures the input has an accessible name.
Ensure State Changes Are Communicated
If you create custom toggles:
Use ARIA attributes like:
- aria-checked=”true”
- aria-expanded=”false”
- aria-selected=”true”
These communicate value and state to assistive technologies.
If You’re Using a CMS or Website Builder
Often these issues appear when:
- Plugins inject custom components
- Designers use visual builders incorrectly
- Buttons are styled using generic containers
To fix:
- Use built-in button blocks
- Ensure form fields include labels
- Avoid clickable containers that aren’t true buttons
- Test interactive elements after publishing
And always retest with an accessibility scan.
How to Test WCAG 4.1.2
After making changes:
- Re-run your accessibility scan
- Confirm 4.1.2 is no longer flagged
- Navigate the page using only the keyboard
- Test with a screen reader
Ask:
- Is every button announced clearly?
- Does every input have a label?
- Do state changes get announced?
If yes, you’ve fixed it.
Why WCAG 4.1.2 Matters Beyond Compliance
Fixing Name, Role, Value:
- Makes custom components usable
- Improves form completion rates
- Reduces user frustration
- Supports screen reader users
- Improves compatibility across devices
- Reduces legal risk
This isn’t just about technical correctness. It’s about making sure your website behaves in a way users can understand. Small structural improvements will massive usability impact.
WCAG 4.1.2 Quick Fix Checklist
All buttons use proper <button> elements
All form inputs have associated labels
Icon-only controls include aria-label
Custom components define correct ARIA roles
State changes are programmatically communicated
Interactive elements tested with screen reader
Issues re-tested after updates
WCAG 4.1.2 Name, Role, Value Frequently Asked Questions
What is WCAG 4.1.2 Name, Role, Value?
WCAG 4.1.2 requires that all interactive elements have a programmatically defined name, role, and value so assistive technologies can accurately communicate their purpose and state.
Why can’t I use a div as a button?
A div does not have a semantic role by default. Screen readers won’t identify it as a button unless proper ARIA roles and keyboard functionality are added.
What is an accessible name?
An accessible name is the label announced by assistive technology. It can come from visible text, a label element, or ARIA attributes such as aria-label.
Does this apply to custom-built components?
Yes. Custom dropdowns, toggles, modals, and sliders must expose proper name, role, and value information to meet WCAG 4.1.2.