4.1.2 Name, Role, Value

1. What is the goal of this criterion?

A screen reader tries to describe a button, but all it finds is a <div> with no name – like a stranger knocking at the door without saying who they are. People who rely on assistive technologies are left puzzled: what does this element do? How do I use it?

So the goal of WCAG Success Criterion 4.1.2 is clear: every control must be understandable to assistive technologies. It needs a name (What am I called?), a role (What kind of element am I?) and information about its current state and value (What state am I in?).

In short: your code has to speak the language assistive technologies understand.

2. What exactly does it require?

Specifically, it covers all user interface components – from form elements and links to custom-built widgets:

Name and role can be programmatically determined:

• Every control needs a name that assistive technologies can read
• The role (button, link, text field, checkbox …) must be clearly identifiable
• This also applies to components generated by scripts

States, properties and values are available:

• States, properties and values that you as a user can change must also be programmatically settable
• Changes to them must be communicated to browsers and assistive technologies
• Examples: whether a checkbox is checked, whether a menu is expanded, what value a slider has, which tab is selected

Good to know: standard HTML elements already meet this criterion when used according to specification. Problems usually arise with custom widgets or when HTML elements are misused.

3. Why does it matter for accessibility?

Imagine using a satnav where all the road signs are blank – that’s what it feels like when assistive technologies get no information about controls.

Name, role and value create clarity because they:

• let screen reader users understand what an element does and how to operate it
• allow voice control to target elements directly (“Click Submit”)
• let switch devices and other alternative input methods present controls reliably
• tell screen reader users about states, such as whether a menu is open or an option is selected
• provide cognitive support through clear, consistent element labels

And last but not least: they make websites more robust and easier to maintain – for developer tools and automated tests too.

4. How to meet the criterion

The good news: if you use semantic HTML, you’re already on the right track. Here are the key tips:

Use native HTML wherever possible:

• <button> instead of <div onclick="…"> for buttons
• <input> with an associated <label> for input fields
• <a href="…"> for links
• <select> for select menus

Use ARIA for custom widgets – but do it properly:

• role="button" for a custom button – but then also with tabindex="0" and operation via Enter and Space (see Keyboard). A real <button> is almost always simpler.
• aria-label="Description" for elements without visible text, such as icon buttons
• aria-labelledby="id" to point to a visible label
• aria-expanded="true" or "false" for expandable sections
• aria-checked only on custom elements with role="checkbox" or role="switch" – native checkboxes expose their state on their own

Keep names concise and functional:

• “Submit” rather than “Click here”
• “Open main menu” rather than an unnamed hamburger icon
• “Sort by price, ascending” rather than “Sort”
• If there’s a visible label, the accessible name must contain it (see Label in Name)

Think about state changes:

• Update attributes such as aria-expanded, aria-pressed or aria-selected via script as soon as the state changes
• For form validation, use aria-invalid and aria-describedby
• For announcing changes without moving focus, there are live regions – that’s covered by Status Messages

Tools for checking:

• Browser developer tools (accessibility panel or accessibility tree)
• Screen readers such as NVDA, JAWS or VoiceOver for testing
• Automated tools such as axe-core or Lighthouse

5. Why this criterion matters for businesses

With Success Criterion 4.1.2, too, accessibility isn’t an end in itself – it brings tangible benefits for your business.

1. Reach a wider audience

Well-named, well-structured controls aren’t only important for people with disabilities. They improve usability for everyone – including people who navigate by voice or need to find the right element quickly in stressful situations.

2. Clean semantics – for machines too

Accessibility isn’t a direct Google ranking factor. But semantically correct HTML makes content easier for every kind of software to read – assistive technologies just as much as crawlers, browser features or test automation.

3. Better code quality and maintainability

Clean, semantic code with clear labels is easier to maintain, test and debug. Many testing tools even locate elements by role and name – so good accessibility makes automated testing easier too.

And then there’s the legal side: since 28 June 2025, the European Accessibility Act (Directive (EU) 2019/882) has applied to many consumer-facing digital services, such as online shops and banking services. Germany implements it through the Barrierefreiheitsstärkungsgesetz (BFSG). The technical benchmark is the harmonised standard EN 301 549, which refers to WCAG 2.1 Level AA for web content – and 4.1.2 is part of that. Public sector bodies are covered separately by the Web Accessibility Directive (EU) 2016/2102. This section is general information, not legal advice.

6. The success criterion in the W3C’s words

Success Criterion 4.1.2 Name, Role, Value (Level A)

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Note: This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

In short: for every control, the name and role are machine-readable, changeable states and values can be set programmatically, and changes are reported to assistive technologies.