WCAG Success Criteria · Level A

WCAG 4.1.2: Name, Role, Value

WCAG 4.1.2 requires that all user interface components have a programmatically determinable name and role, and that states, properties, and values can be both read and set by assistive technologies. This ensures screen readers and other tools can accurately identify, describe, and interact with every element on the page.

Level A
Wcag
Wcag 2 2 a
Robust
Accessibility

What This Rule Means

WCAG 4.1.2 — Name, Role, Value is a Level A success criterion under the Robust principle. It requires that for every user interface component — including form elements, buttons, links, custom widgets, frames, and interactive controls — the following three things must be true:

Name: Each component must have an accessible name that assistive technologies can read aloud or expose through a braille display. The name can come from element content (e.g., the text inside a <button>), a label element, an aria-label attribute, an aria-labelledby reference, or a title attribute.
Role: Each component must have a role that communicates its purpose to assistive technologies. Native HTML elements carry implicit roles (a <button> has role button, a <input type='checkbox'> has role checkbox). Custom widgets built from generic elements like <div> or <span> must explicitly declare a role using the ARIA role attribute.
Value (States and Properties): Any current state or value that is meaningful to the user — whether a checkbox is checked, whether a disclosure widget is expanded, whether a field is required — must be programmatically exposed so that assistive technologies can report it and so that users can change it where applicable.

A component passes this criterion when its accessible name is non-empty, its role is valid and semantically appropriate, and all relevant states (such as aria-checked, aria-expanded, or aria-required) are correctly applied and kept in sync with the visual UI. A component fails when any of these three elements is absent, incorrect, or out of sync — for example, a custom toggle button that changes color visually but never updates its aria-pressed state.

The official WCAG exception covers components that are intentionally not exposed to accessibility APIs — for example, purely decorative elements or content hidden with aria-hidden='true'. However, hiding active or focusable content with aria-hidden (for instance, applying it to the <body> element) is itself a violation, because it removes all page content from the accessibility tree.

Why It Matters

Approximately 2.2 billion people worldwide have some form of vision impairment, according to the World Health Organization. For blind and low-vision users who rely on screen readers such as JAWS, NVDA, or VoiceOver, the accessible name and role of every interactive component are the primary — and often only — means of understanding what a control does and how to use it. If a button has no accessible name, a screen reader user hears only "button" with no indication of its purpose. If a custom dropdown has no role, the user cannot tell it apart from static text.

Motor-impaired users who operate software through switch access, voice control tools like Dragon NaturallySpeaking, or keyboard navigation also depend on this criterion. Voice control software maps spoken commands ("click Submit") to accessible names. If the accessible name of a button does not match its visible label, voice commands fail entirely.

Cognitive accessibility is equally relevant. Consistent, predictable labeling reduces cognitive load for users with dyslexia, memory impairments, or attention-related disabilities. When state changes — such as a modal opening or a form field becoming required — are not announced by assistive technologies, users can become disoriented and unable to complete tasks.

Consider a concrete real-world scenario: a Turkish e-commerce platform displays an "Add to Cart" button built as a <div> with a click handler and a shopping cart icon. Visually it looks like a button. But because it lacks a role='button', an accessible name, and tabindex='0', a screen reader user navigating by keyboard encounters nothing — the element is completely invisible to their assistive technology. They cannot add products to their cart, effectively excluding them from the entire shopping experience.

Beyond accessibility, properly named and structured components improve SEO because search engine crawlers rely on semantic markup to understand page structure and interactive intent. They also improve testability, as automated testing frameworks can more reliably locate and interact with elements that have meaningful roles and labels.

The following axe-core rules are directly associated with WCAG 4.1.2. Each targets a specific category of name, role, or value failure:

aria-allowed-attr: Checks that ARIA attributes applied to an element are permitted for that element's role. For example, applying aria-checked to an element with role='link' is invalid and flagged, because the link role does not support aria-checked.
aria-command-name: Ensures that elements with ARIA command roles (link, button, menuitem) have a non-empty accessible name. An icon-only button with no label text and no aria-label would be flagged here.
aria-hidden-body: Flags the specific case where aria-hidden='true' has been applied to the <body> element, which removes the entire page from the accessibility tree and makes all content invisible to screen readers.
aria-input-field-name: Checks that elements with ARIA input roles (textbox, searchbox, spinbutton, slider, combobox) have an accessible name. A custom search input built with role='textbox' but no label would be flagged.
aria-meter-name: Verifies that elements with role='meter' have an accessible name, so screen reader users understand what quantity the meter is measuring (for example, storage usage or battery level).
aria-progressbar-name: Ensures elements with role='progressbar' carry an accessible name, so users know which process or operation is in progress rather than hearing just "progress bar."
aria-required-attr: Checks that elements using a given ARIA role include all attributes that are required by the ARIA specification for that role. For example, role='slider' requires aria-valuenow, aria-valuemin, and aria-valuemax; omitting any of these is flagged.
aria-roles: Validates that all values assigned to the role attribute are valid, non-abstract ARIA roles. Typos, invented roles, or abstract roles (like role='widget') used directly on elements are all flagged.
aria-tooltip-name: Checks that elements with role='tooltip' have an accessible name. An empty tooltip element provides no value to screen reader users and represents a labeling failure.
button-name: Verifies that <button> elements and elements with role='button' have a non-empty accessible name. This catches icon buttons with no aria-label and empty buttons used as decorative triggers.
frame-title: Requires that <iframe> and <frame> elements have a non-empty title attribute describing the content of the frame. Without it, screen reader users cannot determine the purpose of the embedded content and may not know whether to enter or skip the frame.
input-button-name: Checks that <input> elements of type submit, reset, button, and image have an accessible name — either through a value attribute or, for image inputs, an alt attribute.

It is important to note that while automated tools catch many name, role, and value failures, some violations require manual testing. Automated scanners cannot verify whether an accessible name is meaningful — a button labeled "click here" technically passes the automated check for having a name, but fails to communicate its actual purpose. Similarly, whether state changes (such as aria-expanded toggling when a menu opens) are correctly announced during live interaction can only be confirmed through hands-on screen reader testing.

How to Test

Automated scan with axe DevTools or Lighthouse: Install the axe DevTools browser extension (Chrome or Firefox) or run a Lighthouse audit in Chrome DevTools under the Accessibility tab. Activate the full-page scan and filter results by the WCAG 4.1.2 tag. Look specifically for violations of button-name, frame-title, aria-required-attr, aria-roles, and aria-input-field-name. Each finding will include the offending element, a description of the failure, and a suggested fix. Export the results and prioritize Critical and Serious severity items first.
Keyboard navigation test: Disconnect your mouse and navigate the entire page using the Tab key. Confirm that every focusable element receives visible focus, that the browser's native focus indicator (or a custom one) is clearly visible, and that you can activate all controls using Enter or Space. Any element you reach that you cannot identify by context alone — without looking at the screen — indicates a likely accessible name failure.
Screen reader testing with NVDA and Firefox: Open NVDA (Windows, free), launch Firefox, and navigate the page using Tab to move through interactive elements and the NVDA Elements List (Insert+F7) to browse all buttons, links, and form fields. For each interactive element, listen to what NVDA announces. It should read the element's name, role, and any relevant state (e.g., "Subscribe, button" or "Email address, required, edit text"). Flag any element announced without a name or with an incorrect role.
Screen reader testing with VoiceOver and Safari (macOS/iOS): Enable VoiceOver (Command+F5 on macOS), open Safari, and use VO+Right Arrow to navigate through elements. Use the VoiceOver Rotor (VO+U) to list all form controls and buttons. Verify that names are descriptive, roles are appropriate, and states are updated dynamically when you interact (for example, toggling a custom accordion should cause VoiceOver to announce "expanded" or "collapsed").
Screen reader testing with JAWS and Chrome: Launch JAWS and open Chrome. Use the Tab key to navigate interactive elements and the JAWS Virtual Cursor (Insert+F3 for a list of form fields) to review labels. Pay special attention to custom widgets built with ARIA — confirm that state changes triggered by keyboard interaction are reflected in what JAWS announces in real time.
Custom widget state verification: For any custom widget (accordion, tab panel, combobox, modal), interact with it fully using only the keyboard. At each step, verify that the screen reader announces the correct state update — for example, opening a disclosure widget should trigger an announcement of "expanded," and closing it should announce "collapsed." If the visual state changes but the screen reader is silent, aria-expanded is either missing or not being toggled programmatically.

How to Fix

Icon-Only Button Without Accessible Name — Incorrect

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Icon-Only Button Without Accessible Name — Correct

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Custom Toggle Widget Without Role or State — Incorrect

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

Custom Toggle Widget Without Role or State — Correct

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

Unlabeled iframe — Incorrect

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

Unlabeled iframe — Correct

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

Custom Progress Bar Missing Required ARIA Attributes — Incorrect

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

Custom Progress Bar Missing Required ARIA Attributes — Correct

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

Common Mistakes

Using role='button' on a <div> without adding tabindex='0' — the element becomes announced as a button by screen readers but remains unreachable via keyboard Tab navigation, making it unusable for keyboard-only users.
Applying aria-label to a non-interactive element — adding aria-label to a <div> or <span> with no role has no effect; the label is ignored by most browsers because the element has no role for it to name.
Leaving aria-expanded static after implementing a disclosure widget — setting aria-expanded='false' in HTML and never toggling it with JavaScript means the attribute is always wrong after the first click, announcing the opposite state to screen reader users.
Using aria-hidden='true' on a container that holds focusable elements — this hides the container from the accessibility tree but not from keyboard focus, so screen reader users can Tab into elements they cannot hear, causing extreme confusion.
Providing a placeholder as the only label for an <input> — placeholder text disappears on input, is not reliably announced as a label by all screen readers, and fails to satisfy the accessible name requirement for form fields.
Using an invalid or abstract ARIA role such as role='widget' or role='structure' — these are base roles in the ARIA specification and are not intended for direct use; they provide no meaningful semantic information and may be ignored or cause errors in assistive technologies.
Referencing a non-existent element ID in aria-labelledby — if the ID pointed to by aria-labelledby does not exist in the DOM, the accessible name computation fails and the element is left with no name.
Using value instead of aria-label for <input type='image'> — image input buttons require an alt attribute for their accessible name; the value attribute is ignored for name computation on image inputs.
Omitting the title attribute on <iframe> elements that load third-party content — developers often assume that well-known embeds (maps, payment widgets, video players) are self-describing, but screen reader users must be told the frame's purpose before deciding whether to enter it.
Forgetting to update accessible names dynamically when content changes — if a button's label changes from "Play" to "Pause" visually but the aria-label remains "Play", screen reader users are given incorrect information about the current state and action.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory digital accessibility requirements aligned with WCAG 2.2. WCAG 4.1.2 — Name, Role, Value is a Level A criterion, meaning it sits at the most fundamental tier of conformance. Under the circular, Level A conformance is not optional — it is the baseline that all covered entities must achieve.

The circular applies to a broad range of entity types operating in Turkey. Public institutions — including ministries, municipalities, and state agencies — must achieve conformance within one year of the circular's publication date. Private sector entities — including e-commerce platforms, banks and financial institutions, hospitals and private health providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE) — must achieve conformance within two years.

WCAG 4.1.2 is particularly consequential for Turkish organizations because so many modern Turkish websites rely on custom-built interactive components — product carousels, accordion FAQs, step-by-step checkout flows, and banking dashboards — that are frequently implemented without proper ARIA roles, names, or state management. A custom checkout button that has no accessible name, or a loan calculator slider that lacks aria-valuenow, is not merely a poor user experience: under the circular, it constitutes a legal compliance failure.

For banks and e-commerce platforms subject to the circular, WCAG 4.1.2 violations in transaction-critical flows — payment forms, authentication modals, account dashboards — are especially high-risk. A visually-styled custom combobox for selecting a bank branch that lacks proper ARIA markup can prevent a screen reader user from completing a transaction entirely, exposing the institution to both regulatory action and discrimination claims.

Organizations using the Accsible overlay SDK can benefit from automated detection and runtime remediation of many Name, Role, Value violations — including injecting missing accessible names, correcting invalid ARIA roles on known widget patterns, and synchronizing state attributes on interactive components. However, organizations should treat automated overlay support as a complement to, not a replacement for, proper semantic HTML development, particularly for complex custom widgets where programmatic state management must be baked into the application logic from the outset.

Sources & references

AWCAG 1.1.1: Non-text Content AWCAG 1.2.1: Audio-only and Video-only (Prerecorded)AWCAG 1.2.2: Captions (Prerecorded)