WCAG 2.5.3: Label in Name

Wat Deze Regel Betekent

\n

WCAG 2.5.3 — Label in Name — is van toepassing op elke gebruikersinterfacecomponent die een zichtbaar tekstlabel heeft. Het criterium vereist dat de toegankelijke naam van die component ofwel exact overeenkomt met de zichtbare labeltekst, of op zijn minst de zichtbare labeltekst als substring bevat. Dit voorkomt een situatie waarin een gebruiker één label op het scherm ziet, maar hun ondersteunende technologie of spraakherkenningssoftware achter de schermen een volledig andere naam herkent.

\n

De toegankelijke naam is de naam die wordt blootgesteld aan de toegankelijkheidsboom en wordt gebruikt door schermlezers, spraakbesturingssoftware en andere ondersteunende technologieën. Deze kan afkomstig zijn uit verschillende bronnen, waaronder de zichtbare tekstinhoud van het element, een aria-label-attribuut, een aria-labelledby-verwijzing, een title-attribuut of een geassocieerd <label>-element. Wanneer een ontwikkelaar de toegankelijke naam overschrijft met iets dat de zichtbare labeltekst niet bevat, ontstaat er een mismatch en faalt het criterium.

\n

Betrokken elementen zijn alle interactieve componenten die tekst weergeven en ook een toegankelijke naam hebben: knoppen, links, formulierinvoervelden met zichtbare labels, menu-items, tabbladen, selectievakjes, keuzerondjes en aangepaste ARIA-widgets. Niet-interactieve elementen zoals alinea's of koppen vallen niet onder dit criterium.

\n

Wat telt als een voldoende resultaat: De toegankelijke naam bevat de zichtbare labeltekst als een aaneengesloten substring, waarbij voor- en achteraf spaties worden genegeerd. De overeenkomst is niet hoofdlettergevoelig. Als een knop bijvoorbeeld "Search Products" weergeeft, is een toegankelijke naam "Search Products Now" voldoende omdat deze "Search Products" bevat. Een toegankelijke naam "Find Products" faalt omdat deze de zichtbare tekst niet bevat.

\n

Wat telt als een onvoldoende resultaat: De toegankelijke naam is volledig anders dan het zichtbare label, of de toegankelijke naam laat een betekenisvol deel van het zichtbare label weg. Een knop die visueel "Buy Now" weergeeft maar aria-label='Purchase item' heeft, faalt dit criterium. Evenzo faalt een link die "Contact Us" weergeeft maar is omwikkeld met een element met aria-label='Reach our team'.

\n

Officiële uitzonderingen gedefinieerd in WCAG: Het criterium is niet van toepassing op componenten waarbij het label puur symbolisch of pictografisch is zonder tekstueel equivalent (bijvoorbeeld een knop met alleen een pictogram en geen zichtbare tekst). Het is ook niet van toepassing wanneer de tekst deel uitmaakt van een puur decoratief element dat geen semantische betekenis heeft. Wiskundige notatie en taalspecifieke scenario's waarbij de tekstrepresentatie niet kan worden gekoppeld aan een gesproken woord, zijn eveneens uitgesloten. Daarnaast zijn componenten waarbij de toegankelijke naam opzettelijk wordt uitgebreid met extra context — mits de zichtbare tekst nog steeds aanwezig is binnen de toegankelijke naam — conform.

\n\n

Waarom Het Belangrijk Is

\n

Dit criterium beschermt in de eerste plaats gebruikers die vertrouwen op spraakherkenningssoftware zoals Dragon NaturallySpeaking (nu Dragon Professional), Windows Speech Recognition of Apple's Voice Control. Deze gebruikers navigeren en activeren interface-elementen door het label uit te spreken dat ze op het scherm zien. Wanneer de toegankelijke naam niet overeenkomt met het zichtbare label, kan de software het doelelement niet vinden wanneer de gebruiker de naam uitspreekt, waardoor de bediening in feite onbereikbaar wordt zonder muis of toetsenbord. Voor gebruikers met motorische beperkingen — waaronder mensen met RSI, spierdystrofie, cerebrale parese of ruggenmergletsel — is spraakinput vaak hun primaire of enige manier om een computer te bedienen. Een mismatch op één knop kan de toegang tot een volledige workflow blokkeren.

\n

Schermlezergebruikers worden ook getroffen. Wanneer een schermlezer een toegankelijke naam aankondigt die verschilt van wat zichtbaar is op het scherm, veroorzaakt dat cognitieve desoriëntatie. Een ziende gebruiker die ook een schermlezer gebruikt — bijvoorbeeld iemand met een beperkt gezichtsvermogen die zowel visuele als auditieve feedback tegelijk gebruikt — kan één ding horen terwijl hij iets anders op het scherm leest, wat hun mentaal model van de interface verstoort.

\n

Gebruikers met cognitieve beperkingen profiteren van consistentie tussen wat ze lezen en wat wordt uitgesproken of aangekondigd. Onverwachte naamswijzigingen verhogen de cognitieve belasting en kunnen verwarring of fouten veroorzaken, vooral bij gebruikers met geheugenproblemen of bij mensen die een systeem voor het eerst leren gebruiken.

\n

Een concreet scenario uit de praktijk: Stel je een afrekenpagina van een e-commercewebsite voor met een knop die visueel de tekst "Place Order" weergeeft. Een ontwikkelaar voegt aria-label='Submit purchase form' toe om wat hij als een meer beschrijvende naam beschouwt. Een klant die Dragon NaturallySpeaking gebruikt, zegt "Click Place Order" — Dragon scant de toegankelijkheidsboom, vindt geen element met de naam "Place Order" en kan de knop niet activeren. De klant kan de aankoop niet voltooien zonder over te schakelen op muisbediening, wat hij of zij mogelijk niet kan. De klant breekt de transactie af. Dit is geen hypothetisch randgeval; het is een veelvoorkomend faalpatroon dat wordt aangetroffen in geautomatiseerde audits van retail- en bankwebsites.

\n

Volgens de Wereldgezondheidsorganisatie leven wereldwijd meer dan één miljard mensen met een of andere vorm van beperking. Het WebAIM Million-rapport van 2023 constateerde dat WCAG 2.5.3-labelmismatches voorkwamen in een betekenisvol deel van de geauditeerde pagina's, vaak geïntroduceerd door goedbedoelde maar verkeerd toegepaste ARIA. Los van toegankelijkheid verbetert consistente labeling de SEO, omdat zoekmachinecrawlers die link- en knoptekst indexeren voor relevantieranking, meer betekenisvolle signalen ontvangen wanneer toegankelijke namen overeenkomen met zichtbare tekst.

\n\n

Gerelateerde Axe-core-regels

\n

\n
• label-content-name-mismatch: Dit is de primaire geautomatiseerde regel die is gekoppeld aan WCAG 2.5.3. De regel controleert interactieve elementen — zoals knoppen, links en ARIA-rollen zoals role='button', role='link', role='menuitem' en role='tab' — die zowel een zichtbaar tekstlabel als een toegankelijke naam hebben. De regel markeert elk element waarbij de toegankelijke naam de zichtbare tekst niet als substring bevat (niet hoofdlettergevoelig). De regel richt zich specifiek op elementen waarbij de toegankelijke naam wordt overschreven door aria-label of aria-labelledby op een manier die afwijkt van de tekst op het scherm. Axe rapporteert deze als overtredingen met impactniveau "serious" omdat ze spraakinputgebruikers direct verhinderen om bedieningselementen te activeren.
\n
• Beperkingen van geautomatiseerde detectie: Geautomatiseerde tools zoals axe-core kunnen mismatches betrouwbaar detecteren wanneer de zichtbare tekst wordt weergegeven als platte tekstnodes binnen het element en de toegankelijke naam afkomstig is van een statisch aria-label- of aria-labelledby-attribuut. Handmatig testen is echter vereist wanneer: (1) de zichtbare tekst wordt weergegeven via CSS-::before- of ::after-pseudo-elementen, omdat deze al dan niet in de toegankelijkheidsboom kunnen worden opgenomen, afhankelijk van browser- en AT-versie; (2) het label dynamisch wordt ingevoegd via JavaScript na het laden van de pagina; (3) de zichtbare tekst pictogrammen of op afbeeldingen gebaseerde tekst bevat waarbij het tekstuele onderdeel moet worden afgeleid; (4) de berekende toegankelijke naam van het element complexe aria-labelledby-ketens omvat die meerdere elementen aaneenrijgen. In deze gevallen moet een menselijke tester met een schermlezer verifiëren wat er daadwerkelijk wordt aangekondigd versus wat zichtbaar is.
\n

\n\n

Hoe te Testen

\n

\n
1. Geautomatiseerde scan met axe DevTools of Lighthouse: Installeer de axe DevTools-browserextensie (Chrome of Firefox) of voer een Lighthouse-toegankelijkheidsaudit uit in Chrome DevTools. Start de scan op de volledig gerenderde pagina — zorg ervoor dat dynamische content, modals en uitgeklapte menu's geopend zijn als ze interactieve elementen bevatten. Filter in het axe-resultatenpaneel op regel-ID label-content-name-mismatch. Elk gemarkeerd element toont zijn berekende toegankelijke naam naast de zichtbare tekst, waardoor de mismatch direct duidelijk wordt. Noteer de elementselector en inspecteer de DOM om de bron van de overschreven toegankelijke naam te identificeren. Lighthouse toont dezelfde fouten onder de categorie "Accessibility" met een verwijzing naar WCAG 2.5.3.
\n
2. Handmatige inspectie met browser DevTools: Open het toegankelijkheidspaneel van de browser (Chrome DevTools → Elements → tabblad Accessibility, of Firefox DevTools → tabblad Accessibility). Selecteer elk interactief element dat zichtbare tekst heeft. Controleer in de sectie "Computed Properties" het veld Name van het element. Vergelijk deze waarde met het zichtbare label. Als de berekende naam de zichtbare labeltekst niet als substring bevat, faalt het element 2.5.3.
\n
3. Schermlezertest met NVDA + Firefox: Open Firefox met NVDA actief. Navigeer met de Tab-toets naar elk interactief element. Luister naar wat NVDA aankondigt als de naam van het element. Noteer elke discrepantie tussen de aangekondigde naam en de tekst die op het scherm wordt weergegeven. Gebruik NVDA's Element List (Insert+F7) om alle links en knoppen te doorlopen en de aangekondigde namen in bulk te vergelijken met de visuele labels.
\n
4. Schermlezertest met JAWS + Chrome: Open Chrome met JAWS actief. Doorloop alle interactieve bedieningselementen met Tab. JAWS kondigt de toegankelijke naam aan, gevolgd door de rol. Wanneer de aangekondigde naam de zichtbare tekst niet bevat, noteer je het element. Gebruik daarnaast JAWS' "Browse Mode" en de virtuele viewer om de berekende toegankelijke naam voor elk bedieningselement te bekijken.
\n
5. Schermlezertest met VoiceOver + Safari (macOS/iOS): Schakel VoiceOver in (Command+F5 op macOS). Gebruik Tab of VO+Pijl rechts om door interactieve elementen te navigeren. VoiceOver kondigt de toegankelijke naam voor elk bedieningselement aan. Veeg op iOS met één vinger naar rechts om door elementen te gaan en luister naar discrepanties tussen naam en label.
\n
6. Spraakherkenningstest met Voice Control (macOS/iOS) of Dragon: Schakel macOS Voice Control in (Systeeminstellingen → Toegankelijkheid → Voice Control). Zeg "Show names" om labels voor alle interactieve elementen weer te geven. Controleer of de labels die door Voice Control worden getoond overeenkomen met de zichtbare tekst op het scherm. Probeer bedieningselementen te activeren door de zichtbare labeltekst uit te spreken — elk element dat niet reageert op zijn zichtbare naam is een 2.5.3-fout. Herhaal dit met Dragon NaturallySpeaking op Windows indien beschikbaar, met het commando "Click [label]".
\n

\n\n

Hoe te Herstellen

\n\n

Knop met overschrijvend aria-label — Onjuist

\n

<!-- FAIL: aria-label vervangt de zichtbare tekst \"Search\"\n     volledig door \"Execute query\", waardoor spraakinput wordt doorbroken -->\n<button aria-label='Execute query'>\n  Search\n</button>

\n\n

Knop met overschrijvend aria-label — Juist

\n

<!-- PASS: Verwijder het niet-overeenkomende aria-label volledig.\n     De zichtbare tekst \"Search\" van de knop wordt automatisch de toegankelijke naam.\n     Spraakgebruikers kunnen \"Click Search\" zeggen om deze te activeren. -->\n<button>\n  Search\n</button>\n\n<!-- PASS (alternatief): Als extra context nodig is,\n     zorg ervoor dat de toegankelijke naam de zichtbare tekst BEVAT. -->\n<button aria-label='Search products'>\n  Search\n</button>

\n\n

Link met aria-labelledby die naar niet-gerelateerde tekst verwijst — Onjuist

\n

<!-- FAIL: aria-labelledby verwijst naar een kop \"Our Services\"\n     maar de link leest visueel \"Learn more\",\n     waardoor de toegankelijke naam \"Our Services\" is in plaats van \"Learn more\" -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' aria-labelledby='services-heading'>Learn more</a>\n</p>

\n\n

Link met aria-labelledby die naar niet-gerelateerde tekst verwijst — Juist

\n

<!-- PASS: Gebruik aria-labelledby om de eigen tekst van de link met de kop te combineren.\n     De toegankelijke naam wordt \"Learn more Our Services\",\n     wat het zichtbare label \"Learn more\" bevat. -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' id='learn-link' aria-labelledby='learn-link services-heading'>\n    Learn more\n  </a>\n</p>\n\n<!-- PASS (alternatief): Maak de zichtbare linktekst zelfbeschrijvend\n     zodat geen override nodig is. -->\n<a href='/services'>Learn more about our services</a>

\n\n

Pictogramknop waarbij aria-label in conflict is met zichtbare tekst — Onjuist

\n

<!-- FAIL: De knop toont een winkelwagenpictogram EN de tekst \"Cart\".\n     Het aria-label 'View shopping basket' bevat \"Cart\" niet,\n     waardoor spraakgebruikers die \"Click Cart\" zeggen geen reactie krijgen. -->\n<button aria-label='View shopping basket'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Pictogramknop waarbij aria-label in conflict is met zichtbare tekst — Juist

\n

<!-- PASS: Het aria-label bevat de zichtbare tekst \"Cart\" als substring.\n     Spraakgebruikers kunnen \"Click Cart\" of \"Click View Cart\" zeggen en beide werken. -->\n<button aria-label='View Cart'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>\n\n<!-- PASS (voorkeur): Verwijder aria-label en verberg het pictogram in de boom.\n     De tekstinhoud \"Cart\" van de knop wordt direct de toegankelijke naam. -->\n<button>\n  <svg aria-hidden='true' focusable='false'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Formulierveld met een zichtbaar label maar niet-overeenkomend aria-label — Onjuist

\n\n

(Content truncated due to token limit — please retry this article.)