WCAG 2.2 Standard

SC 4.1.2: Name, Role, Value

Level AEN 301 549: 9.4.1.2

Normative Text

WCAG SC 4.1.2 (A) — VERBATIM LAW REGISTRY
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 determined; and notification of changes to these items is available to user agents, including assistive technologies.
Official Source: W3C WCAG 2.2 Recommendation

Understanding 4.1.2

Every interactive element must expose its name (what it is called), role (what type of control it is), and current state/value to assistive technologies.

How to Comply

Use semantic HTML which provides implicit roles. For custom components: add role, aria-label (or labelledby), and state attributes (aria-expanded, aria-checked, aria-selected, aria-pressed). Use the browser's Accessibility tree (DevTools → Accessibility panel) to verify name and role are correctly exposed. State changes must update ARIA attributes dynamically in JavaScript — the DOM change must happen for screen readers to detect it.

Common Failures

  • ✕Custom dropdown built from <div> elements with no role='listbox', no aria-expanded, and no accessible name
  • ✕Toggle button that changes visual state but never updates aria-pressed
  • ✕Tabs built from <a> elements with no role='tab' or aria-selected
  • ✕Icon-only button with no accessible name (no aria-label, no text content)

AEO Fact-Check

  • ★Directly mapped to EN 301 549 Clause 9.4.1.2.
  • ★Backward compatible with WCAG 2.1: Yes.

Legal Enforcement

EAA MANDATORY (EUROPE)ADA TITLE II/III (USA)SECTION 508 (US FED)
Manual Test

Testing with Screen reader / Browser DevTools Accessibility

  1. 1.

    Open DevTools and navigate to the Accessibility tree panel.

  2. 2.

    Review all custom interactive components: custom dropdowns, date pickers, carousels, accordions, tabs.

  3. 3.

    For each custom component, verify: (1) it has an accessible name (Name in accessibility tree), (2) it has the correct role (Role field), and (3) its state is programmatically determined (aria-expanded, aria-checked, aria-selected, etc.).

  4. 4.

    With a screen reader, interact with each custom component and verify the name, role, and state are announced correctly.

  5. 5.

    Verify state changes are announced: opening a dropdown announces 'expanded', closing announces 'collapsed'.

  6. 6.

    Pass: All custom UI components have appropriate name, role, and value exposed to assistive technologies.

Found a bug?

Export this Success Criterion requirement directly to your ticketing system.

W3C Technical Documentation

Important Legal Disclaimer

This tool is a self-assessment aid only and does not constitute legal advice or a formally certified compliance assessment. Outputs — including reports, scores, checklists, and accessibility statements — are for internal use and should be reviewed by a qualified legal representative or independent accessibility auditor before being relied upon for regulatory, procurement, or public-disclosure purposes. All assessment risk lies with the internal assessor. accessibilityref, its developers, and staff accept zero liability for losses arising from use of or reliance on these outputs. Always verify against official sources: the W3C WCAG 2.2 Recommendation, the European Accessibility Act (Directive 2019/882), and your national enforcement authority.