WCAG 3.2.4: Consistente identificatie

Wat Deze Regel Betekent

WCAG Succescriterium 3.2.4 — Consistente identificatie — stelt dat componenten met dezelfde functionaliteit binnen een set webpagina’s consistent moeten worden geïdentificeerd. Dit betekent dat wanneer een interactief element of een afbeelding dezelfde functie vervult, het elke keer dat het op de site verschijnt dezelfde toegankelijke naam of hetzelfde label moet hebben.

De term "geïdentificeerd" verwijst in deze context naar hoe een component wordt gepresenteerd aan ondersteunende technologieën en gebruikers. Dit omvat de zichtbare labeltekst, het attribuut aria-label of aria-labelledby, de alt-tekst op een afbeelding, het attribuut title, of de toegankelijke naam die wordt berekend door de toegankelijkheidsboom van de browser. Als een zoekknop op elke pagina van een site verschijnt, moet deze altijd "Search" worden genoemd — niet "Search" op de homepage, "Find" op de productoverzichtspagina en "Go" op de afrekenpagina.

Dit criterium is van toepassing op een set webpagina’s, wat WCAG definieert als een verzameling pagina’s met een gemeenschappelijk doel en geproduceerd door dezelfde auteur. Dit omvat een volledige website, een webapplicatie of een meerstapsformulier dat meerdere URL’s beslaat. Componenten die alleen visueel vergelijkbaar zijn maar verschillende functies hebben, hoeven niet dezelfde naam te delen — de eis is specifiek gekoppeld aan identieke functionaliteit.

Wat telt als een voldoende resultaat: Een navigatiepictogram dat een hamburgermenu opent, is op alle pagina’s consequent gelabeld als "Open navigation menu" (of equivalent). Een winkelwagenpictogram heeft altijd de alt-tekst of toegankelijke naam "Shopping cart". Een uitlogknop is altijd gelabeld als "Log out". Variatie in bewoording voor dezelfde functie vormt een fout.

Wat telt als een fout: Een verzendknop die op het registratieformulier is gelabeld als "Submit" maar op het contactformulier als "Send", terwijl beide knoppen dezelfde functionele bedoeling hebben: het verzenden van door de gebruiker ingevoerde gegevens. Een pictogramknop met een vergrootglas die op de meeste pagina’s is gelabeld als "Search" maar op één enkele vertaalde subpagina als "Ara", zonder dat er een consistente taalstrategie is.

Officiële uitzondering: WCAG geeft expliciet aan dat het acceptabel is om twee componenten met dezelfde toegankelijke naam te hebben als ze verschillende functies vervullen — in dat geval zorgt de verschillende functie zelf voor de noodzakelijke onderscheidbaarheid. Het criterium wordt alleen van kracht wanneer de functie identiek is maar de naamgeving inconsistent.

Waarom Het Belangrijk Is

Inconsistente identificatie zorgt voor een onevenredige belasting voor gebruikers die vertrouwen op niet-visuele of patroon-gebaseerde navigatiestrategieën. De groepen die het zwaarst worden getroffen zijn onder andere schermlezersgebruikers, gebruikers met cognitieve beperkingen en gebruikers met motorische beperkingen die afhankelijk zijn van spraakbesturingssoftware.

Schermlezersgebruikers bouwen een mentaal model van een website door te luisteren naar elementnamen terwijl ze met Tab navigeren of op landmerk browsen. Wanneer een knop die op de vorige pagina dezelfde functie had nu een andere naam heeft, moet de gebruiker stoppen, onderzoeken en zich opnieuw oriënteren — een tijdrovende en frustrerende ervaring. Volgens de Wereldgezondheidsorganisatie hebben wereldwijd ongeveer 2,2 miljard mensen een vorm van visuele beperking. Zelfs een fractie van die populatie die met een inconsistent gelabelde site interageert, zal aanzienlijke barrières ondervinden.

Gebruikers met cognitieve beperkingen, waaronder mensen met dyslexie, aandachtsstoornissen of geheugenproblemen, zijn sterk afhankelijk van voorspelbare naamgeving om de cognitieve belasting te verminderen. Een vertrouwd pictogram of besturingselement onder een andere naam tegenkomen dwingt tot herleren en veroorzaakt angst. Consistente labeling vermindert de inspanning die nodig is om procedureel geheugen op te bouwen bij regelmatig gebruik van een site.

Gebruikers van spraakbesturing (met tools zoals Dragon NaturallySpeaking of Apple’s Voice Control) spreken de naam van een besturingselement uit om het te activeren. Als de toegankelijke naam van een knop afwijkt van wat ze verwachten op basis van eerdere ervaring met de site, zal hun gesproken commando stil falen — de software zal eenvoudigweg geen overeenkomst vinden. Dit maakt de interface op dat moment feitelijk onbruikbaar.

Een concreet scenario uit de praktijk: Stel je een Turks e-commerceplatform voor dat kleding verkoopt. Op de productoverzichtspagina heeft elk item een knop met een hartpictogram waarvan de toegankelijke naam "Add to favourites" is. Op de productdetailpagina heeft hetzelfde hartpictogram de toegankelijke naam "Kaydet" (Turks voor "Opslaan"). Een schermlezersgebruiker die heeft geleerd het hartpictogram op de overzichtspagina op naam te activeren, kan het equivalente besturingselement op de detailpagina nu niet vinden zonder uitputtende verkenning. Diegene kan de site volledig verlaten.

Naast toegankelijkheid levert consistente labeling voordelen op voor SEO. Zoekmachines analyseren toegankelijke namen en linktekst om de inhoud van pagina’s te begrijpen. Inconsistente labeling voor functioneel identieke links (bijv. "Read more", "Continue reading", "Learn more" die allemaal naar artikelpagina’s leiden) verzwakt de keyword-signalen en maakt het moeilijker voor crawlers om de sitestructuur te begrijpen.

Gerelateerde Axe-core-regels

WCAG 3.2.4 vereist handmatige tests omdat geautomatiseerde tools de semantische intentie over pagina’s heen niet kunnen bepalen of kunnen weten dat twee verschillend benoemde componenten dezelfde functie vervullen. Er is geen axe-core-regel die direct aan dit criterium is gekoppeld. Dit is waarom automatisering tekortschiet en wat testers in plaats daarvan moeten doen:

• Handmatige test vereist — consistentie over pagina’s heen: Axe-core evalueert één pagina in isolatie. Het heeft geen mechanisme om de toegankelijke naam van een "Search"-knop op de homepage te vergelijken met een "Find"-knop op een productpagina, omdat het geen cross-pagina-inventaris van componentnamen bijhoudt. Een menselijke tester moet herhaalde functionele elementen inventariseren en verifiëren dat hun naamgeving uniform is op alle pagina’s waar ze voorkomen.
• Handmatige test vereist — consistentie van pictogram- en afbeeldings-alt-tekst: Geautomatiseerde tools kunnen ontbrekende alt-tekst detecteren (via de regel image-alt) maar kunnen niet bepalen of twee afbeeldingen met dezelfde functie op verschillende pagina’s dezelfde alt-tekst hebben. Een printerpictogram op een pagina met bonnen en hetzelfde printerpictogram op een factuurpagina kunnen bijvoorbeeld allebei alt-tekst hebben — maar als de ene "Print" en de andere "Print this page" luidt, moet een mens beoordelen of dit een inconsistentie vormt onder 3.2.4.
• Handmatige test vereist — consistentie van ARIA-labels: Axe-core controleert of ARIA-labels aanwezig en niet leeg zijn, maar controleert niet of aria-label-waarden voor hetzelfde type component consistent zijn over de volledige set pagina’s. Een tester moet de toegankelijkheidsboom op meerdere pagina’s inspecteren en namen vergelijken voor functioneel identieke besturingselementen.
• Handmatige test vereist — labels van formuliervelden: Geautomatiseerde regels zoals label verifiëren dat invoervelden aan labels zijn gekoppeld, maar ze controleren niet of een veld "Username" op de inlogpagina ook "Username" is gelabeld (in plaats van "Email" of "User ID") op de pagina voor accountherstel, wanneer beide velden hetzelfde type invoer accepteren en dezelfde functionele rol vervullen.

Hoe te Testen

1. Geautomatiseerde pre-scan: Voer axe DevTools of Lighthouse uit op elke pagina om gerelateerde overtredingen te vinden, zoals ontbrekende toegankelijke namen (image-alt, button-name, link-name). Los deze eerst op — je kunt naamgevingsconsistentie niet beoordelen als namen ontbreken. Noteer de toegankelijke namen die worden gerapporteerd voor herhaalde componenten in je scanresultaten.
2. Maak een componentinventaris: Maak handmatig een lijst van alle functionele componenten die op meerdere pagina’s terugkeren — navigatiemenu’s, zoekvelden, verzendknoppen, pictogramknoppen, kruimelpadlinks, socialmedialinks, print-/deelknoppen en pagineringsbesturingselementen. Leg de toegankelijke naam van elk exemplaar vast met behulp van het Accessibility-paneel van je browser (Chrome DevTools > Elements > Accessibility, of Firefox Accessibility Inspector).
3. Vergelijk namen over pagina’s heen: Controleer voor elk type component in je inventaris of elk exemplaar dezelfde toegankelijke naam heeft. Markeer elke afwijking. Let in het bijzonder op componenten die in paginakoppen, voetteksten en zijbalken voorkomen, omdat deze het meest waarschijnlijk inconsistent zijn gelabeld over verschillende templates.
4. Schermlezertest met NVDA + Firefox: Navigeer naar de homepage en gebruik vervolgens de elementlijst van NVDA (Insert + F7) om de knoppen- en linkenlijst te openen. Noteer de namen van herhaalde besturingselementen. Navigeer daarna naar drie of vier andere representatieve pagina’s en herhaal dit. Luister naar eventuele variatie in naamgeving bij functioneel identieke besturingselementen.
5. Schermlezertest met VoiceOver + Safari (macOS/iOS): Gebruik de Rotor (VO + U) om op elke pagina de knoppen- of linkenlijst te openen. Vergelijk de namen van herhaalde elementen. Veeg op iOS door interactieve elementen op equivalente pagina’s en noteer eventuele verschillen in naamgeving.
6. Schermlezertest met JAWS + Chrome: Gebruik de virtuele cursor van JAWS en de lijst met formuliervelden (Insert + F5) en links (Insert + F7) op meerdere pagina’s. Bevestig dat identieke besturingselementen overal op de site identieke namen hebben.
7. Test met spraakbesturing: Gebruik Windows Voice Access of Dragon NaturallySpeaking en spreek de naam van een herhaald besturingselement op één pagina (bijv. "Click Search"). Navigeer naar een andere pagina en spreek hetzelfde commando. Als het faalt, zijn de namen vanuit functioneel oogpunt inconsistent.

Hoe te Herstellen

Zoekknop met inconsistente labels — Onjuist

<!-- Homepage -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Blog page -->
<button type='submit' aria-label='Go'>
  <svg aria-hidden='true'>...</svg>
</button>

Zoekknop met inconsistente labels — Juist

<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
     always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

Pictogramafbeelding gebruikt voor dezelfde actie met verschillende alt-tekst — Onjuist

<!-- Order history page -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print order' />
</a>

<!-- Invoice page -->
<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print this document' />
</a>

<!-- Receipt page -->
<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Yazdir' />
</a>

Pictogramafbeelding gebruikt voor dezelfde actie met verschillende alt-tekst — Juist

<!-- All print links across the site share the same alt text.
     The destination URL differentiates which document is printed;
     the control's accessible name remains consistent. -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Print' />
</a>

Sluitknop voor navigatie inconsistent benoemd — Onjuist

<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Sluitknop voor navigatie inconsistent benoemd — Juist

<!-- A shared component/template ensures the label is identical everywhere.
     Using a single reusable component or design token for the label
     eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Sociale deel-links met verschillende namen — Onjuist

<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
  <svg aria-hidden='true'>...</svg>
</a>

Sociale deel-links met verschillende namen — Juist

<!-- Both pages use the same accessible name for the functionally
     identical sharing action. The URL parameter carries the context;
     the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

Veelvoorkomende Fouten

• Verschillende aria-label-waarden gebruiken in verschillende templates voor hetzelfde component: Wanneer afzonderlijke ontwikkelaars paginatemplates onafhankelijk bouwen zonder een gedeelde componentenbibliotheek, krijgen pictogramknoppen zoals sluiten, zoeken en winkelwagen vaak ad-hoclabels. Stel een design system-token of gedeeld component in voor elk herhaald interactief element, zodat de toegankelijke naam één keer wordt gedefinieerd en overal wordt hergebruikt.
• Toegankelijke namen inconsistent vertalen op meertalige pagina’s: Een site kan een zoekknop correct labelen als "Search" in het Engels, maar vervolgens een inconsistente Turkse equivalent gebruiken — soms "Ara", soms "Arama Yap" — afhankelijk van welk paginatemplate als eerste is gelokaliseerd. Behoud één vertalingssleutel per componentlabel en dwing deze af in alle taalbestanden.
• Contextspecifieke achtervoegsels toevoegen aan verder identieke besturingselementen: Knoppen labelen als "Add to cart — Blue T-Shirt", "Add to cart — Red Dress" enzovoort wanneer de kernfunctie (toevoegen aan winkelwagen) hetzelfde is, is niet automatisch een 3.2.4-fout — WCAG staat disambiguatie toe — maar dit inconsistent doen (soms met achtervoegsel, soms zonder) zorgt voor verwarring. Kies één patroon en pas dit uniform toe.
• Vertrouwen op de zichtbare tekstlabel voor consistentie terwijl aria-label-overrides verschillen: Wanneer een knop visueel "Search" toont, maar één template aria-label='Search the site' toevoegt en een ander geen aria-label heeft (waardoor de toegankelijke naam alleen uit de zichtbare tekst wordt afgeleid), zullen schermlezers verschillende namen aankondigen, ook al ziet de knop er hetzelfde uit. Controleer de volledige berekening van de toegankelijke naam, niet alleen het zichtbare label.
• CMS-editors de knoptekst vrij laten wijzigen zonder toegankelijkheidsgovernance: Contentmanagementsystemen die knoplabels als bewerkbare velden aanbieden, stellen editors in staat om "Submit" te hernoemen naar "Send" of "Gönder" op basis van persoonlijke voorkeur. Beperk het bewerken van labels voor functionele UI-componenten of voeg validatie toe die editors waarschuwt wanneer een voorgesteld label afwijkt van de vastgestelde standaard.
• Verzuimen om widgets of ingesloten componenten van derden te controleren: Chatwidgets, cookietoestemmingsbanners en betaal-iframes die door derden worden ingesloten, bevatten vaak knoppen die anders zijn gelabeld dan de conventies van de hostsite. Controleer en configureer waar mogelijk de toegankelijke namen van derden zodat ze aansluiten bij je naamgevingsconventies, of documenteer de afwijking als een bekende uitzondering.
• Tooltiptekst (title-attribuut) gebruiken als enige toegankelijke naam in sommige gevallen maar aria-label in andere: Het attribuut title wordt niet betrouwbaar aangekondigd door alle ondersteunende technologieën en wordt beschouwd als een zwakke bron voor toegankelijke namen. Als sommige exemplaren van een herhaald component title gebruiken en andere aria-label, kunnen de berekende namen verschillen door verschillen in de manier waarop browsers en schermlezers hiermee omgaan.
• Aannemen dat pagineringsbesturingselementen zijn uitgezonderd omdat hun nummers verschillen: Besturingselementen "Next page" en "Previous page", zelfs wanneer ze een paginanummer in hun label hebben (bijv. "Go to page 3"), moeten een consistent patroon volgen. Het mixen van "Next" op sommige pagina’s met "Next page" of "İleri" op andere voor hetzelfde pagineringsbesturingselement is een 3.2.4-fout.
• Header- en footercomponenten niet testen op elk afzonderlijk paginatemplate: Sites hebben vaak meerdere paginatemplates (homepage, categoriepagina, artikelpagina, checkout). Header- en footercomponenten kunnen per template net iets anders worden weergegeven. Testers die slechts één of twee templates controleren, kunnen inconsistenties missen die zijn geïntroduceerd door template-specifieke overrides.
• 3.2.4 verwarren met 3.2.3 (Consistente navigatie): Teams denken soms dat als de navigatievolgorde consistent is (3.2.3), de naamgeving dat ook moet zijn — maar dit zijn afzonderlijke vereisten. Een navigatiebalk op dezelfde locatie op elke pagina (conformiteit met 3.2.3) kan nog steeds 3.2.4 schenden als de links verschillend zijn gelabeld op verschillende pagina’s. Pak beide criteria expliciet aan in je QA-proces.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidentiële Circulaire 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt bindende toegankelijkheidseisen vast voor een breed scala aan publieke en private digitale diensten. De Circulaire verplicht naleving van internationaal erkende toegankelijkheidsstandaarden — in de praktijk in lijn met WCAG 2.2 Niveau AA — en koppelt deze naleving aan het Toegankelijkheidslogo (Erişilebilirlik Logosu) dat wordt uitgegeven door het Ministerie van Gezin en Sociale Diensten (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.2.4 Consistente identificatie is een criterium op Niveau AA, wat betekent dat het een verplichte eis is — geen vrijblijvende aanbeveling — voor organisaties die het Erişilebilirlik Logosu willen verkrijgen of behouden. Het niet implementeren van consistente identificatie in een digitale dienst verhindert volledige AA-conformiteit en daarmee de geschiktheid voor het logo.

De Circulaire heeft expliciet betrekking op de volgende typen entiteiten, die allemaal WCAG 3.2.4 in hun web- en mobiele interfaces moeten adresseren: publieke instellingen en overheidsinstanties; banken en aanbieders van financiële diensten; ziekenhuizen en zorgplatforms; telecomoperators met 200,000 of meer abonnees; e-commerceplatforms; reisbureaus en boekingsdiensten; particuliere vervoersbedrijven; en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (Milli Eğitim Bakanlığı).

Voor deze organisaties zijn de praktische implicaties aanzienlijk. Grote institutionele websites — zoals de internetbankierportal van een bank, het afsprakensysteem van een ziekenhuis of het studenteninformatiesysteem van een universiteit — beslaan doorgaans honderden pagina’s en worden in de loop van vele jaren door meerdere ontwikkelingsteams gebouwd. Inconsistente labeling van herhaalde besturingselementen (knoppen voor accountacties, zoekbalken, navigatiepictogrammen) op deze pagina’s is een veelvoorkomende en gemakkelijk over het hoofd geziene faalmodus. Complianceprogramma’s moeten cross-pagina-consistentie-audits opnemen als een aparte testfase, niet alleen geautomatiseerde scans van afzonderlijke pagina’s.

Turkse organisaties die het Erişilebilirlik Logosu nastreven, moeten controles op WCAG 3.2.4 integreren in hun design system-governance, contentmanagementworkflows en QA-pijplijnen. Concreet moet elk herbruikbaar UI-component zijn toegankelijke naam gedefinieerd hebben als een niet-bewerkbare constante op het niveau van het design system, met vertalingssleutels die centraal worden beheerd om ervoor te zorgen dat de Turkse en eventuele andere taalvarianten consistent blijven op alle pagina’s en templates waar het component voorkomt.