Skip to main content
Perceivly: Perceivly home

4.1.2 Name, Role, Value

Level A · added in WCAG 2.0

Every interactive element must expose its name, its role and its current state or value in code. Assistive technology must also be told when that state or value changes.

Who it helps

Screen reader and voice control users depend on this information to find, understand and operate controls. A button announced only as "clickable" or a toggle with no state leaves them guessing.

How to meet it

Examples

Fails:A div used as a button, with no role, name or keyboard support
<div class="btn" onclick="openMenu()">
  <svg aria-hidden="true" width="20" height="20"><use href="#icon-menu"></use></svg>
</div>
Fails:A disclosure toggle that never exposes its open or closed state
<button type="button" onclick="toggleFaq()">Shipping times</button>
<div id="faq-1" hidden>Orders ship within 2 business days.</div>
Passes:A native button with an accessible name and expanded state
<button type="button" aria-label="Menu" aria-expanded="false"
        aria-controls="main-menu" onclick="openMenu()">
  <svg aria-hidden="true" width="20" height="20"><use href="#icon-menu"></use></svg>
</button>
Passes:The toggle reports its state; your script flips aria-expanded on click
<button type="button" aria-expanded="false" aria-controls="faq-1"
        onclick="toggleFaq()">Shipping times</button>
<div id="faq-1" hidden>Orders ship within 2 business days.</div>

Can a scanner detect this?

Partly

Automated tools catch many failures, such as controls with no name, invalid ARIA and focusable elements inside aria-hidden content. They cannot tell whether a name is accurate or whether states update correctly when you use the control.

axe-core rules that test it

Common mistakes

Official W3C explanation of 4.1.2

Check your own page

See which automated WCAG checks your page fails, with the failing elements and how to fix them.

Enter a page address, for example example.com/shop.

Reviewed November 2, 2026