The 2025 TestParty Guide to WCAG 4.1.2 – Name, Role, Value (Level A)

Why did the custom dropdown component fail the accessibility audit? Because it had an identity crisis—no name, no role, and definitely no values.

WCAG 4.1.2 ensures that every interactive element on your site can tell assistive technologies who it is, what it does, and what state it's in. When you build custom UI components—fancy dropdowns, toggle switches, sliders, or anything beyond standard HTML—this criterion keeps them from becoming black boxes to screen readers.

Table of Contents

• What WCAG 4.1.2 Requires
• Why This Matters
• Quick Implementation Guide
• Common Mistakes to Avoid
• How to Test for WCAG 4.1.2
• How TestParty Helps
• FAQs

What WCAG 4.1.2 Requires

Every user interface component must expose three things programmatically to assistive technologies:

Name: What the component is called. A button needs a label like "Submit" or "Close menu." A form field needs an associated label or accessible name.

Role: What type of component it is. Is it a button? A checkbox? A slider? A tab? Assistive technologies need to know so they can announce it correctly and explain how to interact with it.

Value/State: The current condition of the component. Is the checkbox checked? Is the accordion expanded? What's the current value of the slider? When users change these values, assistive technologies must be notified.

Key points:

• Standard HTML elements (button, input, select, a) already meet this criterion when used correctly
• Custom components built with div and span require explicit ARIA roles, labels, and state management
• Dynamic changes to state must trigger notifications to assistive technologies
• This applies to scripted components, not just static content

What's covered:

• Form controls (inputs, selects, custom dropdowns, date pickers)
• Interactive widgets (tabs, accordions, modals, tooltips, sliders)
• Custom buttons and links
• Any div or span made clickable or interactive with JavaScript

Why This Matters

Screen reader users navigate by jumping between interactive elements—buttons, links, form fields. When a custom component lacks a proper name, role, or state, it's either invisible to assistive tech or announced incorrectly.

Imagine clicking a mystery button that's only announced as "clickable" with no label, or a custom checkbox that never tells you whether it's checked. That's the experience when 4.1.2 fails.

Legal and compliance context:

WCAG 4.1.2 is a Level A requirement, making it foundational for ADA Title III compliance, Section 508 procurement, EN 301 549 (EU), and the European Accessibility Act. Courts have cited failures of custom components to work with screen readers in numerous ADA lawsuits. If your checkout flow uses a custom dropdown that doesn't expose its value, you're creating both a legal risk and a conversion barrier.

Business impact:

Custom UI components often appear in critical flows—checkout, account creation, filters, search. When they fail 4.1.2, you lose customers who rely on assistive tech. Fixing these issues improves usability for everyone, including keyboard users and voice control users.

Quick Implementation Guide

1. Use native HTML elements whenever possible

Native controls come with name, role, and value built in. A <button> is already a button. An <input type="checkbox"> already announces its checked state.

<!-- Good: Native button with visible text -->
<button type="submit">Create Account</button>

<!-- Good: Native checkbox with associated label -->
<input type="checkbox" id="terms" />
<label for="terms">I agree to the terms</label>

2. Add explicit roles to custom components

If you must use <div> or <span> for interactive elements, add an ARIA role:

<!-- Custom button built with div -->
<div role="button" tabindex="0" onclick="submitForm()">
  Submit
</div>

<!-- Custom checkbox -->
<div role="checkbox" aria-checked="false" tabindex="0">
  Subscribe to newsletter
</div>

3. Provide accessible names

Use aria-label, aria-labelledby, or visible text content:

<!-- Icon button with aria-label -->
<button aria-label="Close dialog">
  <svg>...</svg>
</button>

<!-- Input with aria-labelledby pointing to visible label -->
<span id="email-label">Email address</span>
<input type="text" aria-labelledby="email-label" />

4. Expose and update state

Use ARIA state attributes and update them when users interact:

<!-- Expandable section -->
<button aria-expanded="false" aria-controls="details">
  Show details
</button>
<div id="details" hidden>...</div>

<!-- Toggle switch -->
<button role="switch" aria-checked="false">
  Enable notifications
</button>

5. Ensure state changes are announced

When JavaScript changes state (checking a box, expanding a panel), update the ARIA attribute. Modern assistive tech will announce the change automatically.

Key techniques:

• ARIA14: Using aria-label for accessible names
• ARIA16: Using aria-labelledby to reference visible labels
• G108: Using semantic markup to expose name, role, and state

Common Mistakes to Avoid

Using div or span as buttons without role="button"

A <div onclick="..."> looks clickable but screen readers don't know it's a button. Add role="button" and tabindex="0", and handle keyboard events (Enter/Space).

Icon buttons with no accessible name

<button><svg>...</svg></button> has no text for screen readers to announce. Add aria-label="Close" or visually-hidden text.

Custom controls that don't update state

Building a custom checkbox that toggles a class but never updates aria-checked means screen reader users never know if it's checked.

Multi-part form fields without individual labels

A phone number split into three inputs (area code, prefix, line) needs a label for each part, not just one label for the group. Use aria-label on each input or wrap in a fieldset with individual labels.

Emulating links with JavaScript on non-link elements

<span onclick="navigate()"> isn't a link. Use <a href="..."> or add role="link" and full keyboard support.

How to Test for WCAG 4.1.2

Automated checks:

• Run an accessibility scanner (axe, WAVE, Lighthouse) to catch missing roles, labels, and ARIA attributes
• Look for violations flagged as F59, F68, F79, F86, F89, F111
• Check that all interactive elements have accessible names

Manual testing:

• Navigate with keyboard only—can you reach every interactive element? Does focus order make sense?
• Use a screen reader (NVDA, JAWS, VoiceOver) to interact with custom components
• Is each component announced with a clear name?
• Is the role correct (button, checkbox, tab, etc.)?
• When you toggle or change something, is the new state announced?
• Inspect the accessibility tree in browser DevTools—verify name, role, and state properties are present

What automation misses:

• Whether accessible names are meaningful (a button labeled "Click here" has a name, but it's not useful)
• Whether state changes are announced clearly in context
• Complex widget patterns (comboboxes, tree views) that require manual interaction testing

How TestParty Helps

TestParty's code-level analysis and AI-powered remediation are purpose-built to catch and fix WCAG 4.1.2 violations before they reach production.

What TestParty detects:

TestParty scans your DOM and source code to identify interactive elements missing names, roles, or state attributes:

• <div> and <span> elements with click handlers but no role attribute
• Buttons and links with no accessible name (icon-only buttons, image links, empty labels)
• Form inputs without associated <label> elements or aria-label
• Custom components (dropdowns, toggles, sliders) missing ARIA roles or state attributes (aria-checked, aria-expanded, aria-pressed)
• Multi-part form fields (phone numbers, dates) where individual inputs lack labels
• Focus state issues—elements that receive focus but don't expose their focus state programmatically

TestParty flags these as Level A violations and surfaces them in your dashboard with line-level references to the offending code.

How TestParty suggests fixes:

For many 4.1.2 violations, TestParty's AI generates specific code fixes:

• Missing roles: Suggests adding role="button", role="checkbox", etc., to custom interactive elements
• Missing names: Proposes aria-label text based on surrounding context, or suggests linking to visible labels with aria-labelledby
• Missing state attributes: Recommends adding aria-checked, aria-expanded, aria-pressed, and provides JavaScript snippets to toggle them on interaction
• Form label associations: Generates for/id pairings or aria-labelledby references to connect inputs with labels

Each suggested fix includes an explanation of why it's needed and a reference to the relevant WCAG technique. Developers or TestParty accessibility specialists review and approve fixes before they're committed, ensuring context-appropriate remediation.

Developer workflow integration:

TestParty integrates directly into your development process to prevent 4.1.2 regressions:

• CI/CD gates: Block pull requests that introduce interactive elements without proper name/role/value attributes
• IDE and PR annotations: Surface missing ARIA attributes and accessible names as inline comments during code review, with one-click fix suggestions
• Pre-commit hooks: Warn developers when they add onclick handlers to non-semantic elements without adding roles

This shift-left approach catches issues when they're easiest to fix—before merge, not after customer complaints.

Ongoing monitoring:

TestParty continuously scans your site (or runs on every deploy) to track 4.1.2 compliance over time:

• Dashboards show trends in missing names, roles, and states across your component library
• Alerts fire when new violations are introduced (e.g., a new custom component ships without ARIA)
• Audit-ready reports document compliance for each interactive component, useful for legal review or procurement requirements

For teams managing design systems or component libraries, TestParty can scan your Storybook or pattern library to ensure every reusable component meets 4.1.2 before it's distributed to product teams.

TestParty's combination of automated detection, AI-suggested fixes, and CI/CD enforcement helps teams scale 4.1.2 compliance across thousands of components without manual audits of every page.

Some TestParty features described in this article are currently under development. Visit TestParty.ai to learn more about our current capabilities and roadmap, or book a demo at TestParty.ai/book-a-demo to see TestParty in action.

Disclaimer: Some of this article was generated with Large Language Models (LLMs) and Artificial Intelligence (AI). There may be some errors and we advise you to consult with human professionals for detailed questions.

FAQs About WCAG 4.1.2

What is WCAG 4.1.2 in plain language?

WCAG 4.1.2 requires that every interactive element on your site—buttons, links, form fields, custom widgets—tells assistive technologies its name (label), role (what type of control it is), and current state or value. This ensures screen readers and other assistive tech can announce controls correctly and notify users when states change.

Is WCAG 4.1.2 required for ADA compliance?

Yes. WCAG 4.1.2 is a Level A criterion, which means it's part of the baseline accessibility standard referenced in ADA Title III enforcement, Section 508, and international regulations like EN 301 549 and the European Accessibility Act. Failing 4.1.2—especially on critical interactive elements like checkout buttons or form controls—creates significant legal risk.

Do I need to worry about 4.1.2 if I only use standard HTML elements?

Mostly no. Standard HTML controls (<button>, <input>, <select>, <a>) already meet 4.1.2 when used according to specification. The criterion becomes critical when you build custom components with <div>, <span>, or heavily scripted interactions. If you're using a well-maintained component library (Material UI, Radix, Reach UI), those components typically handle ARIA correctly—but you should still test.

What's the difference between "name" and "label" in 4.1.2?

In WCAG terms, "name" is the programmatic accessible name that assistive tech reads. It can come from a visible <label> element, aria-label, aria-labelledby, or the text content of the element itself. "Label" often refers to the visible text, but 4.1.2 cares about the accessible name—which might be invisible (like aria-label on an icon button).

How do I handle dynamic content that changes role or state?

When JavaScript changes a component's state (expanding an accordion, checking a checkbox, loading new content), update the relevant ARIA attribute (aria-expanded, aria-checked, aria-busy, etc.). Modern assistive technologies monitor these attributes and announce changes automatically. Avoid only changing CSS classes—screen readers can't see visual changes, only changes to the accessibility tree.

Can automated tools fully test WCAG 4.1.2 compliance?

Automated tools can catch many 4.1.2 violations—missing roles, missing labels, incorrect ARIA usage. But they can't judge whether an accessible name is meaningful or whether a complex widget behaves correctly with a screen reader. Combine automated scanning (like TestParty) with manual testing using keyboard navigation and screen readers for full confidence.