WCAG Fix It Guide: 4.1.2 Name, Role, Value

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.

For example, a button that visually says “Submit” must have an accessible name of “Submit.”

Role

The type of component. Examples include:

• 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. Examples include:

• 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 and 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

It’s not hard to fix WCAG 4.1.2 noncompliance if you know what to look for. Here are some tips:

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, you should 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

Here’s a quick WCAG 4.1.2 checklist you can use to improve your digital content:

• All buttons use proper 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 FAQs

Looking for a quick recap? Here are answers to some of the most frequently asked questions on this topic: