G108Sufficient technique WCAG 4.1.2 Level A Partly scanner-detectable

Expose name, role, and changes through markup

Assistive technology can only describe a control if the markup says what the control is, what it is called, and what it is doing right now. G108 asks you to build with markup features that expose an accessible name and a role, let assistive technology set the values a user is allowed to set, and announce state changes when they happen. W3C lists it as sufficient for 4.1.2 Name, Role, Value at Level A, reached through a more specific technique rather than through this one alone. Native HTML is the shortcut. A real button supplies role, keyboard behavior and state handling before you write a line of ARIA. W3C is careful about one half of this. Even a component that supports accessibility properly cannot invent its own name, so the name is still your job.

How we find it in an audit

Scanners catch the obvious half, a control with no accessible name or a clickable element with no role. They miss the half that matters more. Our reviewers walk each interactive component with a screen reader and check what actually gets announced, then compare that against what the control is called on screen and what it is doing. State changes get the same treatment, because a toggle that flips silently reads as a toggle that did nothing.

How affected users experience it

A div with a click handler is, to a screen reader, a piece of text. No role to announce, no name, no keyboard behavior, no way to report that it is now pressed or expanded. The user hears a word with nothing to suggest it can be operated. The control might as well not be on the page. A native button carries all four of those for free.

Passes vs. fails

Passes: name, role, and state exposed. Fails: a control with no identity.

Passes

<button type="button" onclick="save()">Save</button> exposes name, role, state and focus behavior with nothing extra written.

Fails

<div class="btn" onclick="save()">Save</div> exposes no role, no accessible name, no keyboard support, and no state.

How this gets tested

The W3C publishes test rules that define what a checker looks for here.

Image button has non-empty accessible nameA tool can check this
Link has non-empty accessible nameA tool can check this
ARIA attribute is defined in WAI-ARIAA tool can check this
ARIA state or property has valid valueA tool can check this
Element with role attribute has required states and propertiesA tool can check this
Form field has non-empty accessible nameA tool can check this
Role attribute has valid valueA tool can check this
ARIA state or property is permittedA tool can check this
Button has non-empty accessible nameA tool can check this
Element with aria-hidden has no content in sequential focus navigationA tool can check this
Element with presentational children has no focusable contentA tool can check this
Menuitem has non-empty accessible nameA tool can check this
Summary element has non-empty accessible nameA tool can check this
Iframe element has non-empty accessible nameA tool can check this
Iframe elements with identical accessible names have equivalent purposeA tool finds candidates, you decide

Other ways to satisfy this rule

23 guides on this site are filed under 4.1.2 Name, Role, Value. W3C lists this one as sufficient for that rule when it is implemented through a more specific technique, so the condition is part of the test rather than a footnote to it.

This guide is our interpretation of W3C technique G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.