WCAG-succescriteria · Level A
WCAG 4.1.2: Naam, rol, waarde
WCAG 4.1.2 vereist dat alle gebruikersinterfacecomponenten een programmatisch bepaalbare naam en rol hebben, en dat toestanden, eigenschappen en waarden zowel kunnen worden gelezen als ingesteld door ondersteunende technologieën. Dit zorgt ervoor dat schermlezers en andere hulpmiddelen elk element op de pagina nauwkeurig kunnen identificeren, beschrijven en ermee kunnen interageren.
Wat Deze Regel Betekent
WCAG 4.1.2 — Name, Role, Value is een succescriterium op Niveau A onder het principe Robuust. Het vereist dat voor elke gebruikersinterfacecomponent — inclusief formelementen, knoppen, links, aangepaste widgets, frames en interactieve bedieningselementen — de volgende drie zaken waar moeten zijn:
- Naam: Elke component moet een toegankelijke naam hebben die door ondersteunende technologieën kan worden voorgelezen of via een brailleleesregel kan worden weergegeven. De naam kan afkomstig zijn van de inhoud van het element (bijv. de tekst binnen een
<button>), eenlabel-element, eenaria-label-attribuut, eenaria-labelledby-verwijzing of eentitle-attribuut. - Rol: Elke component moet een rol hebben die het doel ervan communiceert aan ondersteunende technologieën. Native HTML-elementen hebben impliciete rollen (een
<button>heeft rol button, een<input type='checkbox'>heeft rol checkbox). Aangepaste widgets die zijn opgebouwd uit generieke elementen zoals<div>of<span>moeten expliciet een rol declareren met behulp van het ARIA-role-attribuut. - Waarde (Toestanden en Eigenschappen): Elke huidige toestand of waarde die betekenisvol is voor de gebruiker — of een selectievakje is aangevinkt, of een disclosure-widget is uitgeklapt, of een veld verplicht is — moet programmatisch worden blootgelegd zodat ondersteunende technologieën dit kunnen melden en zodat gebruikers dit waar van toepassing kunnen wijzigen.
Een component voldoet aan dit criterium wanneer de toegankelijke naam niet leeg is, de rol geldig en semantisch passend is, en alle relevante toestanden (zoals aria-checked, aria-expanded of aria-required) correct zijn toegepast en in sync worden gehouden met de visuele UI. Een component voldoet niet wanneer een van deze drie elementen ontbreekt, onjuist is of niet in sync is — bijvoorbeeld een aangepaste toggleknop die visueel van kleur verandert maar nooit zijn aria-pressed-toestand bijwerkt.
De officiële WCAG-uitzondering heeft betrekking op componenten die bewust niet worden blootgesteld aan toegankelijkheids-API’s — bijvoorbeeld puur decoratieve elementen of inhoud die is verborgen met aria-hidden='true'. Het verbergen van actieve of focusbare inhoud met aria-hidden (bijvoorbeeld dit toepassen op het <body>-element) is echter op zichzelf een overtreding, omdat het alle pagina-inhoud uit de toegankelijkheidsboom verwijdert.
Waarom Het Belangrijk Is
Ongeveer 2,2 miljard mensen wereldwijd hebben een vorm van visuele beperking, volgens de Wereldgezondheidsorganisatie. Voor blinde en slechtziende gebruikers die vertrouwen op schermlezers zoals JAWS, NVDA of VoiceOver, zijn de toegankelijke naam en rol van elke interactieve component de primaire — en vaak enige — manier om te begrijpen wat een bedieningselement doet en hoe het te gebruiken. Als een knop geen toegankelijke naam heeft, hoort een schermlezergebruiker alleen "button" zonder enige aanwijzing van het doel. Als een aangepaste dropdown geen rol heeft, kan de gebruiker deze niet onderscheiden van statische tekst.
Gebruikers met motorische beperkingen die software bedienen via switch access, spraakbesturingstools zoals Dragon NaturallySpeaking of toetsenbordnavigatie zijn eveneens afhankelijk van dit criterium. Spraakbesturingssoftware koppelt gesproken commando’s ("klik Verzenden") aan toegankelijke namen. Als de toegankelijke naam van een knop niet overeenkomt met het zichtbare label, falen spraakcommando’s volledig.
Cognitieve toegankelijkheid is even relevant. Consistente, voorspelbare labeling vermindert de cognitieve belasting voor gebruikers met dyslexie, geheugenstoornissen of aandachtsgerelateerde beperkingen. Wanneer toestandswijzigingen — zoals het openen van een modal of het verplicht worden van een formulierveld — niet worden aangekondigd door ondersteunende technologieën, kunnen gebruikers gedesoriënteerd raken en niet in staat zijn taken te voltooien.
Beschouw een concreet scenario uit de echte wereld: een Turks e-commerceplatform toont een knop "Add to Cart" die is gebouwd als een <div> met een click-handler en een winkelwagenpictogram. Visueel ziet het eruit als een knop. Maar omdat het geen role='button', geen toegankelijke naam en geen tabindex='0' heeft, komt een schermlezergebruiker die met het toetsenbord navigeert niets tegen — het element is volledig onzichtbaar voor hun ondersteunende technologie. Ze kunnen geen producten aan hun winkelwagen toevoegen en worden feitelijk uitgesloten van de volledige winkelervaring.
Naast toegankelijkheid verbeteren correct benoemde en gestructureerde componenten de SEO, omdat zoekmachinecrawlers vertrouwen op semantische markup om de paginastructuur en interactieve intentie te begrijpen. Ze verbeteren ook de testbaarheid, omdat geautomatiseerde testframeworks elementen met betekenisvolle rollen en labels betrouwbaarder kunnen lokaliseren en ermee kunnen interageren.
Gerelateerde Axe-core-regels
De volgende axe-core-regels zijn direct gekoppeld aan WCAG 4.1.2. Elke regel richt zich op een specifieke categorie van fouten in naam, rol of waarde:
- aria-allowed-attr: Controleert of ARIA-attributen die op een element zijn toegepast, zijn toegestaan voor de rol van dat element. Het toepassen van bijvoorbeeld
aria-checkedop een element metrole='link'is ongeldig en wordt gemarkeerd, omdat delink-rol geenaria-checkedondersteunt. - aria-command-name: Zorgt ervoor dat elementen met ARIA-commando-rollen (
link,button,menuitem) een niet-lege toegankelijke naam hebben. Een knop die alleen uit een pictogram bestaat, zonder labeltekst en zonderaria-label, zou hier worden gemarkeerd. - aria-hidden-body: Markeert de specifieke situatie waarin
aria-hidden='true'is toegepast op het<body>-element, wat de volledige pagina uit de toegankelijkheidsboom verwijdert en alle inhoud onzichtbaar maakt voor schermlezers. - aria-input-field-name: Controleert of elementen met ARIA-invoerrollen (
textbox,searchbox,spinbutton,slider,combobox) een toegankelijke naam hebben. Een aangepast zoekveld dat is gebouwd metrole='textbox'maar geen label heeft, zou worden gemarkeerd. - aria-meter-name: Verifieert dat elementen met
role='meter'een toegankelijke naam hebben, zodat schermlezergebruikers begrijpen welke grootheid de meter meet (bijvoorbeeld opslaggebruik of batterijniveau). - aria-progressbar-name: Zorgt ervoor dat elementen met
role='progressbar'een toegankelijke naam hebben, zodat gebruikers weten welk proces of welke bewerking bezig is in plaats van alleen "progress bar" te horen. - aria-required-attr: Controleert of elementen die een bepaalde ARIA-rol gebruiken alle attributen bevatten die volgens de ARIA-specificatie voor die rol vereist zijn. Zo vereist
role='slider'de attributenaria-valuenow,aria-valueminenaria-valuemax; het weglaten van een van deze wordt gemarkeerd. - aria-roles: Valideert dat alle waarden die aan het
role-attribuut zijn toegekend, geldige, niet-abstracte ARIA-rollen zijn. Typfouten, zelfbedachte rollen of abstracte rollen (zoalsrole='widget') die direct op elementen worden gebruikt, worden allemaal gemarkeerd. - aria-tooltip-name: Controleert of elementen met
role='tooltip'een toegankelijke naam hebben. Een leeg tooltip-element biedt geen waarde voor schermlezergebruikers en vertegenwoordigt een labelingsfout. - button-name: Verifieert dat
<button>-elementen en elementen metrole='button'een niet-lege toegankelijke naam hebben. Dit vangt pictogramknoppen zonderaria-labelen lege knoppen die als decoratieve triggers worden gebruikt. - frame-title: Vereist dat
<iframe>- en<frame>-elementen een niet-leegtitle-attribuut hebben dat de inhoud van het frame beschrijft. Zonder dit kunnen schermlezergebruikers het doel van de ingesloten inhoud niet bepalen en weten ze mogelijk niet of ze het frame moeten betreden of overslaan. - input-button-name: Controleert of
<input>-elementen van het typesubmit,reset,buttonenimageeen toegankelijke naam hebben — via eenvalue-attribuut of, voor image-inputs, eenalt-attribuut.
Het is belangrijk op te merken dat, hoewel geautomatiseerde tools veel fouten in naam, rol en waarde opsporen, sommige overtredingen handmatige tests vereisen. Geautomatiseerde scanners kunnen niet verifiëren of een toegankelijke naam betekenisvol is — een knop met het label "klik hier" slaagt technisch voor de geautomatiseerde controle op het hebben van een naam, maar slaagt er niet in het werkelijke doel te communiceren. Evenzo kan alleen via praktische tests met een schermlezer worden bevestigd of toestandswijzigingen (zoals het toggelen van aria-expanded wanneer een menu wordt geopend) tijdens live interactie correct worden aangekondigd.
Hoe te Testen
- Geautomatiseerde scan met axe DevTools of Lighthouse: Installeer de axe DevTools-browserextensie (Chrome of Firefox) of voer een Lighthouse-audit uit in Chrome DevTools onder het tabblad Accessibility. Activeer de scan van de volledige pagina en filter de resultaten op de WCAG 4.1.2-tag. Let specifiek op overtredingen van
button-name,frame-title,aria-required-attr,aria-rolesenaria-input-field-name. Elke bevinding bevat het betreffende element, een beschrijving van de fout en een voorgestelde oplossing. Exporteer de resultaten en geef prioriteit aan items met de ernst Critical en Serious. - Toetsenbordnavigatietest: Koppel je muis los en navigeer de volledige pagina met de Tab-toets. Controleer of elk focusbaar element zichtbare focus krijgt, of de native focusindicator van de browser (of een aangepaste) duidelijk zichtbaar is, en of je alle bedieningselementen kunt activeren met Enter of Spatie. Elk element dat je bereikt en dat je niet op basis van context alleen kunt identificeren — zonder naar het scherm te kijken — duidt op een waarschijnlijke fout in de toegankelijke naam.
- Schermlezertest met NVDA en Firefox: Open NVDA (Windows, gratis), start Firefox en navigeer door de pagina met Tab om door interactieve elementen te gaan en met de NVDA Elements List (Insert+F7) om alle knoppen, links en formuliervelden te bekijken. Luister voor elk interactief element naar wat NVDA aankondigt. Het zou de naam, rol en relevante toestand van het element moeten voorlezen (bijv. "Abonneren, button" of "E-mailadres, verplicht, edit text"). Markeer elk element dat zonder naam of met een onjuiste rol wordt aangekondigd.
- Schermlezertest met VoiceOver en Safari (macOS/iOS): Schakel VoiceOver in (Command+F5 op macOS), open Safari en gebruik VO+Pijl rechts om door elementen te navigeren. Gebruik de VoiceOver Rotor (VO+U) om alle formuliervelden en knoppen te tonen. Controleer of namen beschrijvend zijn, rollen passend zijn en toestanden dynamisch worden bijgewerkt wanneer je interacteert (bijvoorbeeld: het toggelen van een aangepaste accordion moet ertoe leiden dat VoiceOver "expanded" of "collapsed" aankondigt).
- Schermlezertest met JAWS en Chrome: Start JAWS en open Chrome. Gebruik de Tab-toets om door interactieve elementen te navigeren en de JAWS Virtual Cursor (Insert+F3 voor een lijst met formuliervelden) om labels te controleren. Let in het bijzonder op aangepaste widgets die met ARIA zijn gebouwd — controleer of toestandswijzigingen die door toetsenbordinteractie worden geactiveerd, worden weerspiegeld in wat JAWS in real time aankondigt.
- Verificatie van toestanden bij aangepaste widgets: Interageer voor elke aangepaste widget (accordion, tabpanel, combobox, modal) volledig met alleen het toetsenbord. Controleer bij elke stap of de schermlezer de juiste toestandsupdate aankondigt — het openen van een disclosure-widget moet bijvoorbeeld een aankondiging van "expanded" triggeren, en het sluiten ervan "collapsed". Als de visuele toestand verandert maar de schermlezer stil blijft, ontbreekt
aria-expandedof wordt het niet programmatisch getoggeld.
Hoe te Herstellen
Alleen-pictogramknop zonder toegankelijke naam — Onjuist
<!-- 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>Alleen-pictogramknop zonder toegankelijke naam — Juist
<!-- 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>Aangepaste toggle-widget zonder rol of toestand — Onjuist
<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
Dark Mode
</div>Aangepaste toggle-widget zonder rol of toestand — Juist
<!-- 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>Iframe zonder label — Onjuist
<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>Iframe zonder label — Juist
<!-- 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>Aangepaste voortgangsbalk zonder vereiste ARIA-attributen — Onjuist
<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>Aangepaste voortgangsbalk zonder vereiste ARIA-attributen — Juist
<!-- 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>Veelvoorkomende Fouten
role='button'gebruiken op een<div>zondertabindex='0'toe te voegen — het element wordt door schermlezers als een knop aangekondigd maar blijft onbereikbaar via toetsenbordnavigatie met Tab, waardoor het onbruikbaar is voor gebruikers die alleen het toetsenbord gebruiken.aria-labeltoepassen op een niet-interactief element — het toevoegen vanaria-labelaan een<div>of<span>zonder rol heeft geen effect; het label wordt door de meeste browsers genegeerd omdat het element geen rol heeft die het kan benoemen.aria-expandedstatisch laten na het implementeren van een disclosure-widget — het instellen vanaria-expanded='false'in HTML en dit nooit toggelen met JavaScript betekent dat het attribuut na de eerste klik altijd onjuist is en de tegenovergestelde toestand aankondigt aan schermlezergebruikers.aria-hidden='true'gebruiken op een container met focusbare elementen — dit verbergt de container in de toegankelijkheidsboom maar niet voor toetsenbordfocus, waardoor schermlezergebruikers met Tab in elementen terechtkomen die ze niet kunnen horen, wat tot grote verwarring leidt.- Een
placeholdergebruiken als het enige label voor een<input>— placeholdertekst verdwijnt bij invoer, wordt niet door alle schermlezers betrouwbaar als label aangekondigd en voldoet niet aan de eis van een toegankelijke naam voor formuliervelden. - Een ongeldige of abstracte ARIA-rol gebruiken, zoals
role='widget'ofrole='structure'— dit zijn basisrollen in de ARIA-specificatie en zijn niet bedoeld voor direct gebruik; ze bieden geen betekenisvolle semantische informatie en kunnen worden genegeerd of fouten veroorzaken in ondersteunende technologieën. - Verwijzen naar een niet-bestaand element-ID in
aria-labelledby— als het ID waarnaar dooraria-labelledbywordt verwezen niet in de DOM bestaat, mislukt de berekening van de toegankelijke naam en blijft het element zonder naam. valuegebruiken in plaats vanaria-labelvoor<input type='image'>— image-invoerknoppen vereisen eenalt-attribuut voor hun toegankelijke naam; hetvalue-attribuut wordt genegeerd bij de naamberekening voor image-inputs.- Het
title-attribuut weglaten op<iframe>-elementen die content van derden laden — ontwikkelaars gaan er vaak van uit dat bekende embeds (kaarten, betaalwidgets, videospelers) zichzelf verklaren, maar schermlezergebruikers moeten het doel van het frame kennen voordat ze kunnen beslissen of ze het moeten betreden. - Vergeten toegankelijke namen dynamisch bij te werken wanneer inhoud verandert — als het label van een knop visueel verandert van "Play" naar "Pause" maar het
aria-label"Play" blijft, krijgen schermlezergebruikers onjuiste informatie over de huidige toestand en actie.
Relatie met de Toegankelijkheidsregelgeving van Turkije
De Turkse Presidential Circular 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte digitale toegankelijkheidseisen vast die zijn afgestemd op WCAG 2.2. WCAG 4.1.2 — Name, Role, Value is een criterium op Niveau A, wat betekent dat het zich op het meest fundamentele niveau van conformiteit bevindt. Onder de circulaire is conformiteit op Niveau A niet optioneel — het is de basis die alle betrokken entiteiten moeten bereiken.
De circulaire is van toepassing op een breed scala aan entiteitstypen die in Turkije actief zijn. Publieke instellingen — waaronder ministeries, gemeenten en overheidsinstanties — moeten binnen één jaar na de publicatiedatum van de circulaire conformiteit bereiken. Entiteiten in de private sector — waaronder e-commerceplatforms, banken en financiële instellingen, ziekenhuizen en particuliere zorgaanbieders, telecombedrijven met 200.000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministry of National Education (MoNE) — moeten binnen twee jaar conformiteit bereiken.
WCAG 4.1.2 is bijzonder ingrijpend voor Turkse organisaties omdat zoveel moderne Turkse websites vertrouwen op zelfgebouwde interactieve componenten — productcarrousels, accordion-FAQ’s, stapsgewijze checkoutflows en bankdashboards — die vaak worden geïmplementeerd zonder correcte ARIA-rollen, namen of toestandsbeheer. Een aangepaste checkoutknop zonder toegankelijke naam, of een schuifregelaar voor een leningscalculator zonder aria-valuenow, is niet slechts een slechte gebruikerservaring: onder de circulaire vormt dit een juridische non-conformiteit.
Voor banken en e-commerceplatforms die onder de circulaire vallen, zijn overtredingen van WCAG 4.1.2 in transactiekritieke flows — betalingsformulieren, authenticatiemodals, accountdashboards — bijzonder risicovol. Een visueel gestileerde aangepaste combobox voor het selecteren van een bankfiliaal die geen correcte ARIA-markup heeft, kan voorkomen dat een schermlezergebruiker een transactie voltooit, waardoor de instelling wordt blootgesteld aan zowel regulatoire maatregelen als discriminatieclaims.
Organisaties die de Accsible overlay SDK gebruiken, kunnen profiteren van geautomatiseerde detectie en runtime-remediatie van veel Name, Role, Value-overtredingen — waaronder het injecteren van ontbrekende toegankelijke namen, het corrigeren van ongeldige ARIA-rollen bij bekende widgetpatronen en het synchroniseren van toestandsattributen op interactieve componenten. Organisaties moeten overlay-ondersteuning echter zien als een aanvulling op, en niet als vervanging van, correcte semantische HTML-ontwikkeling, vooral bij complexe aangepaste widgets waarbij programmatisch toestandsbeheer vanaf het begin in de applicatielogica moet zijn ingebouwd.