Requires every interface component to expose its name and role, and its states and values, so assistive technology can use it.
A screen reader tells a user what a control is called, what it is, and what state it is in: "Subscribe, button", "Dark mode, switch, on". If a control is built from a div with a click handler, the screen reader announces nothing useful, and speech and switch users cannot target it.
This criterion requires that for all user interface components the name and role can be programmatically determined, that states, properties and values that the user can set can be programmatically set, and that notification of changes to these items is available to user agents, including assistive technologies.
TRaria-label can provide the name (ARIA14). aria-labelledby can point at nearby text (ARIA16).Screen reader users, who rely on names, roles and states to understand and use controls. Users of speech recognition, who need a name to speak. Switch and keyboard users, whose software lists and activates controls by name. People who use screen magnifiers with focus following. Anyone using software that adapts the interface.
The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Components that expose name, role and value are part of "robust".
The technical counterpart is the standard EN 301 549, which incorporates WCAG 4.1.2 by reference and turns it into separate clauses for each kind of ICT.
| Clause | Type of ICT | What it requires |
|---|---|---|
| 9.4.1.2 | Web pages | Web content must satisfy WCAG success criterion 4.1.2. |
| 10.4.1.2 | Non-web documents (PDF, Office files) | Documents must expose the name, role and value of interactive components where the standard applies the criterion to them. |
| 11.4.1.2 | Non-web software (native mobile apps) | Software must expose name, role and value to assistive technology through the platform accessibility services. |
Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.
Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 4.1.2 is the same in WCAG 2.1 and 2.2.
A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.
Directive (EU) 2019/882, EUR-Lex, opens in a new tab
A div with a click handler has no role, no name and no keyboard support (F59). Use a button.
<div class="btn" onclick="subscribe()">Subscribe</div><button type="button" onclick="subscribe()">Subscribe</button>A control with no programmatically determined name fails (F68). Give it one (ARIA14).
<button><svg>…</svg></button><button type="button" aria-label="Close"><svg aria-hidden="true">…</svg></button>A link whose only content is an image needs a name from the image's text alternative (F89).
<a href="/home"><img src="logo.svg" alt=""></a><a href="/home"><img src="logo.svg" alt="Corpowid home"></a>If you cannot use a native input, expose the role and the state, update the state when it changes, and support the keyboard (ARIA4, ARIA5).
<div class="check" onclick="this.classList.toggle('on')">Remember me</div><div role="checkbox" tabindex="0" aria-checked="false" id="remember">Remember me</div>
<script>
remember.addEventListener("click", toggle);
remember.addEventListener("keydown", e => { if (e.key === " ") { e.preventDefault(); toggle(); } });
function toggle() {
const on = remember.getAttribute("aria-checked") === "true";
remember.setAttribute("aria-checked", String(!on));
}
</script>Tell assistive technology whether the panel is open.
<div class="head" onclick="toggle()">Details</div><button type="button" aria-expanded="false" aria-controls="panel">Details</button>
<div id="panel" hidden>…</div>A script that makes a span behave like a link loses the link role and keyboard access (F42). Use a real link.
<span class="link" onclick="location.href='/pricing'">Pricing</span><a href="/pricing">Pricing</a>Native components expose name, role and state automatically. When you build a custom control, set its role, its name and its state yourself.
import SwiftUI
struct DarkModeSwitch: View {
@Binding var isOn: Bool
var body: some View {
// A custom control built from an Image. Give it a name, a role and a value
Image(systemName: isOn ? "moon.fill" : "moon")
.onTapGesture { isOn.toggle() }
.accessibilityLabel("Dark mode")
.accessibilityAddTraits(.isButton)
.accessibilityValue(isOn ? "On" : "Off")
// Better still, use Toggle("Dark mode", isOn: $isOn)
}
}import androidx.compose.foundation.layout.Row
import androidx.compose.foundation.selection.toggleable
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.Role
@Composable
fun DarkModeRow(checked: Boolean, onChange: (Boolean) -> Unit) {
// toggleable exposes the role, the state and the click action
Row(
modifier = Modifier.toggleable(
value = checked,
role = Role.Switch,
onValueChange = onChange
)
) {
Text("Dark mode")
// The visual switch is drawn here
}
}div and span controls: No role and no keyboard support (F59, F42).aria-expanded or aria-checked that never changes.Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.
