Category: ARIA and Semantic Structure
Name, Role, Value
Also known as: WCAG Success Criterion 4.1.2, SC 4.1.2
Simply put
Name, Role, Value is a web accessibility requirement that ensures the interactive parts of a webpage, such as buttons, links, and form fields, can be understood by assistive technologies like screen readers. It means each control should have a name that identifies it, a role that explains what it is, and a value or state that communicates its current condition. When this information is properly provided, people who use assistive technologies can perceive, understand, and operate the controls.
Formal definition
Name, Role, Value (WCAG Success Criterion 4.1.2, a Level A criterion) requires that for all user interface components, including form elements, links, and scripted components, the name and role can be programmatically determined; that states, properties, and values that can be set by the user can be programmatically set; and that notification of changes to these items is available to user agents, including assistive technologies. The name may be visible or invisible. For standard HTML controls used according to specification, these requirements are generally satisfied by using semantic markup; custom or scripted components may require ARIA attributes to expose accessible name, role, and state/value information to the accessibility API. Conformance with this criterion supports, but does not by itself guarantee, an accessible experience, and both automated and manual testing with assistive technologies are generally needed to verify it.
Why it matters
Name, Role, Value sits at the heart of how assistive technologies interpret interactive content. When a control such as a button, link, or form field exposes a programmatically determinable name, role, and current state or value, a screen reader user can understand what the control is, what it does, and its present condition. When that information is missing or incorrect, the same control may be announced as an unlabeled or generic element, leaving the user unable to perceive its purpose or operate it reliably. Because this is a Level A success criterion in WCAG, it represents a foundational rather than an advanced requirement.
Who it's relevant to
Front-end and accessibility engineers
Developers building interactive components are directly responsible for ensuring each control exposes a programmatically determinable name and role, along with any state or value a user can set. This is often achieved by using semantic HTML correctly and, for custom widgets, by applying appropriate ARIA attributes so that changes are communicated to user agents and assistive technologies.
UX and interaction designers
Designers influence whether controls have clear, identifiable names and predictable roles. Specifying accessible names, distinguishing component types, and accounting for state changes at the design stage helps ensure that what users see visually is also conveyed to those relying on assistive technologies.
QA and accessibility testers
Because automated tools detect only a portion of Name, Role, Value issues, testers verifying this Level A criterion generally need to combine automated scans with manual testing using screen readers and other assistive technologies to confirm that controls are announced with the correct name, role, and current state or value.
Compliance officers and accessibility program leads
Those overseeing conformance efforts should treat Name, Role, Value as a foundational Level A requirement and recognize that meeting it supports, but does not guarantee, an accessible experience or legal compliance. Specific obligations depend on the applicable authority and jurisdiction, and legal questions should be directed to qualified counsel.
Inside Name, Role, Value
Name
The accessible name that identifies a user interface component to assistive technologies. It can be derived from visible text, an associated label, an aria-label, an aria-labelledby reference, or other host-language mechanisms, allowing users to understand what a control is.
Role
The programmatically determinable type or purpose of a component (for example, button, checkbox, link, or dialog). Roles may be conveyed through native HTML elements or through ARIA role attributes when native semantics are unavailable.
Value
The current state, properties, and values that can be set by the user, along with notification of changes to assistive technologies. Examples include whether a checkbox is checked, the current position of a slider, or the expanded/collapsed state of a disclosure control.
States and Properties
Attributes that communicate a component's condition or characteristics (such as aria-expanded, aria-checked, aria-disabled, or aria-selected) so that assistive technology users receive accurate, up-to-date information as the interface changes.
Success Criterion 4.1.2
Name, Role, Value is WCAG Success Criterion 4.1.2 at Level A, which addresses the programmatic exposure of interface component semantics. It is commonly cited as foundational for the compatibility of custom and scripted components with assistive technologies.
Common questions
Answers to the questions practitioners most commonly ask about Name, Role, Value.
Does using standard HTML elements automatically satisfy Name, Role, Value?
Not automatically, though it is a strong starting point. Native HTML elements such as buttons, links, and form inputs commonly expose an appropriate name, role, and value to assistive technology by default, which is why using native semantics is generally recommended. However, this benefit can be lost when default elements are restyled, replaced with generic elements like <div> or <span>, or manipulated with scripting that does not preserve or update the accessible name, role, or programmatically determined value. Custom and dynamic components in particular require explicit attention to ensure these properties are correctly conveyed and kept in sync as state changes.
Is Name, Role, Value only relevant to custom widgets built with ARIA?
No. While custom widgets built with ARIA are a frequent context where this criterion becomes challenging, Name, Role, Value applies to all user interface components, including native controls. The criterion addresses whether the name and role can be programmatically determined, whether states, properties, and values can be set where users can change them, and whether changes are made available to assistive technologies. This applies broadly across interactive content, not solely to ARIA-based components. ARIA is one mechanism for meeting the criterion when native semantics are insufficient, not the only situation in which it is relevant.
Which WCAG success criterion covers Name, Role, Value, and at what conformance level?
Name, Role, Value is Success Criterion 4.1.2, which is a Level A criterion present since WCAG 2.0. Because it is a Level A criterion, it is included in conformance targets at Level A, AA, and AAA. AA is the level most commonly cited as a target in policies and settlements. As with all guidance here, this describes the technical standard published by the W3C and is not legal advice regarding any specific obligation.
How should the accessible name for a custom control be provided?
An accessible name can commonly be provided through several mechanisms, which should be chosen based on the component and context. For native controls, a visible label associated with a form field, the text content of a button or link, or an alt attribute on an image may supply the name. For custom components, attributes such as aria-label or aria-labelledby can supply or reference a name. Where possible, associating a visible label with the control is generally preferred so that the name is available to all users, and care should be taken that the accessible name reflects the control's visible label.
How do you ensure that state and value changes are conveyed to assistive technology?
When a control's state or value changes, the corresponding programmatic property must be updated so assistive technology can detect it. For native elements, this is often handled by the platform. For custom components, this generally means updating the relevant ARIA state or property in sync with the visible change, for example toggling an expanded or checked state attribute, or updating a value attribute when a user adjusts a control. The key is that the programmatically exposed value matches the current on-screen state at all times, including after scripted interactions.
Can automated testing confirm that Name, Role, Value is met?
Automated testing can detect only a portion of the issues relevant to this criterion, such as missing accessible names on some elements or certain invalid attribute usage. It generally cannot confirm that a role is appropriate for the component's actual behavior, that the accessible name is meaningful, or that state and value changes are announced correctly during interaction. Manual review and testing with assistive technologies such as screen readers are typically required to verify that a component's name, role, and value are correctly conveyed in practice.
Common misconceptions
Visible on-screen labels are enough to satisfy Name, Role, Value.
A label that is only visually present does not necessarily expose the name, role, or value programmatically. The information must be available to assistive technologies through the accessibility API, which generally requires correct native semantics or appropriate ARIA.
Adding ARIA attributes automatically makes a custom control accessible.
ARIA can supply name, role, and value information, but it does not add behavior. Incorrect or incomplete ARIA can worsen the experience. Native HTML elements are generally preferred, and any ARIA-based approach should be verified with assistive technology testing.
Passing automated checks confirms that Name, Role, Value is met.
Automated tools detect only a portion of issues, such as a missing accessible name, but cannot fully confirm that roles are appropriate or that state changes are announced correctly. Manual and assistive technology testing are required to evaluate real usability.
Best practices
Prefer native HTML elements (such as button, input, and select) that expose name, role, and value automatically, and reserve ARIA for cases where native semantics are unavailable.
Provide a clear accessible name for every interactive component using visible text, a properly associated label, aria-label, or aria-labelledby, and verify the exposed name in an accessibility inspector.
Ensure the role of each component accurately reflects its purpose and behavior, avoiding mismatches such as marking a non-interactive element with an interactive role.
Programmatically convey and update states and properties (for example, checked, expanded, selected, or disabled) so that assistive technologies are notified when values change.
Test custom and scripted components with multiple screen readers and assistive technologies, since conformance with the success criterion does not by itself guarantee a usable experience.
Treat Name, Role, Value as one part of broader accessibility work; consult current WCAG guidance and, where legal obligations are at issue, qualified legal counsel, as this guidance is not legal advice.