WCAG 2.4.4: Doel van de link (in context)

Wat Deze Regel Betekent

WCAG 2.4.4 — Linkdoel (in context) — is een succescriterium op niveau A onder het principe Bedienbaar. Het stelt dat het doel van elke link bepaalbaar moet zijn op basis van alleen de linktekst, of op basis van de linktekst in combinatie met de programmeerbaar bepaalde linkcontext. Als geen van beide voldoende is, voldoet de link niet aan dit criterium.

De uitdrukking "programmeerbaar bepaalde linkcontext" is zorgvuldig gedefinieerd door WCAG. Ze verwijst naar informatie die kan worden afgeleid uit dezelfde zin, alinea, lijstitem of tabelcel als de link, of uit de kop die voorafgaat aan een sectie die de link bevat. Ze omvat ook context die wordt blootgelegd via ARIA-relaties zoals aria-labelledby of aria-describedby. Cruciaal is dat deze context programmeerbaar beschikbaar moet zijn — wat betekent dat ondersteunende technologieën deze automatisch kunnen lezen — en niet alleen visueel geïmpliceerd mag zijn voor ziende gebruikers.

In praktische termen worden de volgende HTML-elementen en -attributen rechtstreeks beïnvloed door dit criterium: <a href>-ankerelementen, <area>-elementen in afbeeldingskaarten, <button>-elementen die navigatie activeren, elementen die met stijlen of scripts als links functioneren via ARIA-rollen zoals role='link', en SVG-<a>-elementen. De toegankelijke naam van de link — berekend op basis van de interne tekst, aria-label, aria-labelledby of een alt-attribuut op een onderliggende afbeelding — is het primaire middel om het doel te communiceren.

Wat telt als voldoende: Een link voldoet als een gebruiker het doel of de functie kan bepalen zonder extra context (bijv. "Download het Jaarverslag 2024 als PDF"), of als de omringende programmeerbare context het doel duidelijk maakt (bijv. een "Read more"-link binnen een <li> dat begint met de artikeltitel). De linktekst hoeft niet overal op de pagina uniek te zijn; ze hoeft alleen ondubbelzinnig te zijn binnen haar context.

Wat telt als onvoldoende: Generieke linkteksten zoals "click here", "read more", "here", "more" of "link" voldoen niet wanneer de omringende programmeerbare context de bestemming niet verduidelijkt. Een afbeeldingslink met een ontbrekend of leeg alt-attribuut voldoet evenmin, omdat de toegankelijke naam dan volledig ontbreekt.

Officiële uitzondering: WCAG erkent één uitzondering. Wanneer het linkdoel opzettelijk dubbelzinnig is — wat betekent dat het vooraf bekendmaken van het doel de bruikbaarheid ervan of die van de omringende inhoud zou ondermijnen — is het criterium niet van toepassing. Deze uitzondering is uiterst beperkt en zelden van toepassing in praktijksituaties.

Waarom Het Belangrijk Is

Ongeveer 2,2 miljard mensen wereldwijd hebben een vorm van visuele beperking, volgens de Wereldgezondheidsorganisatie. Onder hen worden blinde gebruikers die afhankelijk zijn van schermlezers het sterkst getroffen door dubbelzinnige linktekst. Schermleessoftware zoals NVDA, JAWS en VoiceOver stelt gebruikers in staat een pagina te navigeren door een lijst te genereren van alle links, losgetrokken uit hun context. Wanneer die lijst tientallen items bevat die allemaal "read more" of "click here" luiden, kunnen blinde gebruikers niet bepalen welke link waarheen leidt zonder naar elke link terug te navigeren en de omringende inhoud te lezen — een tijdrovend en desoriënterend proces.

Gebruikers met motorische beperkingen die navigeren met uitsluitend toetsenbordinvoer, schakelbediening of oogvolgapparaten profiteren eveneens aanzienlijk. Deze gebruikers doorlopen interactieve elementen vaak sequentieel met de Tab-toets en vertrouwen op het label van het gefocuste element om te beslissen of ze het moeten activeren. Dubbelzinnige linktekst dwingt tot extra navigatiestappen die vermoeidheid en foutpercentages verhogen.

Gebruikers met cognitieve beperkingen — waaronder mensen met aandachtsstoornissen, geheugenproblemen of lage geletterdheid — profiteren van duidelijke, beschrijvende linktekst omdat dit de cognitieve belasting vermindert die nodig is om de structuur van een pagina te begrijpen. Zij hoeven geen contextuele informatie in het werkgeheugen vast te houden terwijl ze links scannen.

Een concreet praktijkscenario: Stel een e-commerce productoverzichtspagina voor die tien producten toont, elk met een "Buy Now"-knop en een "Learn More"-link die identiek worden weergegeven. Een blinde gebruiker die de lijst met links doorloopt, hoort tien opeenvolgende keren "Learn More" zonder enige aanwijzing naar welk product elke link verwijst. Om het juiste product te kopen, moet die gebruiker de volledige omringende context van elke link lezen — een proces dat minuten in plaats van seconden kan duren. Met beschrijvende linktekst zoals "Learn more about the Sony WH-1000XM5 Headphones" is dezelfde taak met één enkele navigatieactie uit te voeren.

Naast toegankelijkheid levert beschrijvende linktekst meetbare SEO-voordelen op. Zoekmachinecrawlers gebruiken ankertekst als signaal om de inhoud van de gelinkte pagina te begrijpen. Beschrijvende, zoekwoordrijke linktekst verbetert de crawlbaarheid en indexeerbaarheid van gelinkte bronnen en draagt positief bij aan zoekresultaten. Bovendien verlaagt duidelijke linktekst het bouncepercentage en het aantal supportverzoeken doordat gebruikersverwachtingen vóór de navigatie nauwkeurig worden gezet.

Gerelateerde Axe-core-regels

• link-name: Deze regel controleert dat elk <a>-element met een href-attribuut, elk element met role='link' en elk <area>-element een niet-lege toegankelijke naam heeft. De toegankelijke naam wordt berekend via de standaard ARIA-berekening voor toegankelijke namen: interne tekstinhoud, aria-label, aria-labelledby of het alt-attribuut van een onderliggend <img>-element. Axe markeert een overtreding wanneer de berekende toegankelijke naam leeg is, uitsluitend uit witruimte bestaat of volledig ontbreekt. Deze regel detecteert de ernstigste vorm van een 2.4.4-fout — links die volledig naamloos zijn — maar kan geen links detecteren waarvan de namen technisch aanwezig maar semantisch betekenisloos zijn (bijv. "click here" of "read more"), omdat geautomatiseerde tools geen intentie kunnen afleiden uit generieke tekenreeksen.
• duplicate-id-aria: Deze regel controleert dat niet twee elementen op de pagina dezelfde id-waarde delen wanneer die id wordt verwezen door een ARIA-attribuut zoals aria-labelledby of aria-describedby. Dubbele ID’s die in ARIA-relaties worden gebruikt, zorgen ervoor dat de browser de verwijzing onvoorspelbaar oplost — meestal naar het eerste overeenkomende element in DOM-volgorde — wat ertoe kan leiden dat de toegankelijke naam van een link volledig uit het verkeerde element wordt berekend. Als bijvoorbeeld twee links allebei aria-labelledby='product-title' gebruiken en twee elementen die ID delen, kunnen schermlezers voor een of beide links de verkeerde productnaam uitspreken, wat direct in strijd is met 2.4.4. Axe markeert dit als een kritiek probleem omdat de resulterende toegankelijke naam onbetrouwbaar is.

Het is belangrijk de grenzen van geautomatiseerd testen voor dit criterium te begrijpen. Tools zoals axe-core kunnen verifiëren dat een link een toegankelijke naam heeft, maar ze kunnen niet verifiëren dat die naam betekenisvol is. Een link met de naam "here" slaagt automatisch voor de link-name-regel omdat de tekenreeks niet leeg is. Menselijk oordeel is nodig om te beoordelen of generieke linktekst niet voldoet aan 2.4.4. Dit maakt handmatig testen een essentiële aanvulling op geautomatiseerde scans voor dit criterium.

Hoe te Testen

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 een scan van de volledige pagina en filter de resultaten op de regels link-name en duplicate-id-aria. Beoordeel elk gemarkeerd element: bevestig dat de berekende toegankelijke naam ontbreekt of leeg is bij link-name-overtredingen, en verifieer dat dubbele ID’s ARIA-labelverwijzingen verbreken bij duplicate-id-aria-overtredingen. Let erop dat het slagen voor deze geautomatiseerde controles geen volledige naleving van 2.4.4 garandeert — ga door met de handmatige stappen.
2. Handmatige beoordeling van de lijst met links: Druk in NVDA met Firefox op de toetscombinatie Insert+F7 om het dialoogvenster Elementenlijst te openen en selecteer "Links". Beoordeel elk item in de lijst geïsoleerd, zonder visuele context. Vraag jezelf af: kun je bepalen waar elke link naartoe leidt op basis van alleen de tekst? Herhaal dit in JAWS met Chrome via Insert+F7 om de Links-lijst te openen. In VoiceOver met Safari op macOS druk je op Control+Option+U om de Web Item Rotor te openen en selecteer je "Links". Elke link waarvan het doel in isolatie dubbelzinnig is, moet worden beoordeeld in relatie tot de programmeerbare context.
3. Toetsenbordnavigatietest: Navigeer met alleen de Tab-toets door alle interactieve elementen op de pagina. Telkens wanneer de focus op een link landt, lees je alleen de aangekondigde tekst (niet de omringende visuele inhoud). Als je de bestemming van de link niet kunt bepalen op basis van wat wordt aangekondigd, voldoet de link waarschijnlijk niet aan 2.4.4. Let in het bijzonder op links die alleen uit pictogrammen bestaan (socialmedia-iconen, pijltjestoetsen) en afbeeldingslinks.
4. Contextverificatie: Inspecteer voor links die afhankelijk zijn van omringende context (bijv. "Read more" binnen een lijstitem) de DOM om te bevestigen dat de contextuele tekst zich in dezelfde zin, alinea, hetzelfde lijstitem of dezelfde tabelcel bevindt als de link. Context die alleen visueel aangrenzend is maar niet programmeerbaar geassocieerd, voldoet niet aan het criterium. Gebruik de browser-DevTools om de berekende toegankelijkheidsboom te inspecteren en de relatie te bevestigen.
5. ARIA-labelaudit: Doorzoek de broncode van de pagina naar alle toepassingen van aria-labelledby en aria-describedby op linkelementen. Verifieer dat elke verwezen ID exact één keer in het document voorkomt en dat het verwezen element de beoogde beschrijvende tekst bevat. Gebruik het toegankelijkheidspaneel van de browser (beschikbaar in Chrome DevTools onder het tabblad Accessibility) om de berekende naam voor elke link te bevestigen.

Hoe te Herstellen

Alleen-pictogramlink zonder toegankelijke naam — Onjuist

<!-- An icon link with no text and no aria-label -->
<a href='https://twitter.com/accsible'>
  <svg viewBox='0 0 24 24' width='24' height='24'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Alleen-pictogramlink zonder toegankelijke naam — Juist

<!-- aria-label provides a descriptive accessible name for screen readers -->
<a href='https://twitter.com/accsible' aria-label='Accsible on Twitter'>
  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Generieke "Read more"-links in een kaartenlijst — Onjuist

<!-- Multiple identical link texts with no distinguishing context -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>Read more</a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>Read more</a>
  </li>
</ul>

Generieke "Read more"-links in een kaartenlijst — Juist

<!-- Option 1: Visually hidden text appended to the link -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>
      Read more
      <span class='sr-only'>about the Istanbul Accessibility Summit 2024</span>
    </a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>
      Read more
      <span class='sr-only'>about the New WCAG 2.2 Guidelines</span>
    </a>
  </li>
</ul>

<!-- Option 2: Use aria-label to override the visible text entirely -->
<a href='/events/istanbul-2024' aria-label='Read more about the Istanbul Accessibility Summit 2024'>
  Read more
</a>

Afbeeldingslink met leeg alt-attribuut — Onjuist

<!-- The image has an empty alt, making the link completely unnamed -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='' />
</a>

Afbeeldingslink met leeg alt-attribuut — Juist

<!-- The alt attribute on the image provides the link's accessible name -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='Accsible Overlay Widget — product details' />
</a>

aria-labelledby dat naar een dubbele ID verwijst — Onjuist

<!-- Two elements share the same ID; the second link resolves to the wrong label -->
<div>
  <span id='card-title'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title'>View</a>
</div>
<div>
  <span id='card-title'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title'>View</a>
</div>

aria-labelledby dat naar een dubbele ID verwijst — Juist

<!-- Each ID is unique; each link resolves to the correct label -->
<div>
  <span id='card-title-docs'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title-docs'>View</a>
</div>
<div>
  <span id='card-title-pricing'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title-pricing'>View</a>
</div>

Veelvoorkomende Fouten

• "click here", "here", "more" of "read more" als linktekst gebruiken zonder aanvullende toegankelijke naam via aria-label, aria-labelledby of visueel verborgen <span>-elementen — deze tekenreeksen zijn betekenisloos wanneer ze door een schermlezer uit de visuele context worden gehaald.
• Een aria-label toevoegen aan een link die andere zichtbare tekst bevat zonder ervoor te zorgen dat het label begint met de zichtbare teksttekenreeks — dit is in strijd met WCAG 2.5.3 (Label in Name) en veroorzaakt verwarring bij gebruikers van spraakbesturing die proberen de link te activeren door de zichtbare naam uit te spreken.
• alt='' instellen op een afbeelding die de enige inhoud van een link is, waardoor de berekende toegankelijke naam van de link leeg wordt en een link-name-overtreding ontstaat — een leeg alt-attribuut is correct voor decoratieve afbeeldingen, maar niet wanneer de afbeelding de enige inhoud van een interactief element is.
• aria-hidden='true' toepassen op de enige tekstnode binnen een link, waardoor de toegankelijke naam uit de toegankelijkheidsboom wordt verwijderd en de link naamloos blijft voor schermlezergebruikers.
• Dezelfde id-waarde hergebruiken in meerdere elementen waarnaar wordt verwezen door aria-labelledby op verschillende links, waardoor schermlezers de verkeerde toegankelijke naam voor een of meer links berekenen vanwege onvoorspelbare ID-resolutie.
• Een volledige kaartcomponent (kop, afbeelding, alinea en knop) in één <a>-tag wikkelen, waardoor schermlezers de volledige kaartinhoud als toegankelijke naam van de link voorlezen — een breedsprakige en desoriënterende ervaring — in plaats van een korte, beschrijvende label te gebruiken.
• Uitsluitend vertrouwen op een CSS-title-attribuuttooltip of een :hover-pseudo-class om linkcontext te bieden — het title-attribuut wordt inconsistent blootgelegd door schermlezers en is volledig ontoegankelijk voor toetsenbordgebruikers die geen hovertoestanden kunnen activeren.
• De URL zelf als linktekst gebruiken (bijv. <a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>), wat onuitspreekbaar is voor schermlezers en betekenisloos voor gebruikers met cognitieve beperkingen.
• Link-ID’s of ARIA-attribuutwaarden dynamisch genereren met JavaScript-frameworks zonder uniciteit te waarborgen — React-, Vue- en Angular-componenten die in lijsten worden gerenderd, produceren vaak dubbele ID’s tenzij expliciete keying-strategieën worden geïmplementeerd.
• Vergeten focusable='false' toe te voegen aan inline SVG-iconen binnen links in Internet Explorer en oudere Edge-versies, waardoor de SVG een eigen tabstop krijgt en schermlezers de SVG los van de linktekst aankondigen, wat de berekening van de toegankelijke naam opsplitst.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidentiële Circulaire 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 2.4.4 Link Purpose (In Context) is een criterium op niveau A, wat betekent dat het valt binnen de verplichte basislijn die alle betrokken entiteiten moeten behalen.

De circulaire is van toepassing op een gedefinieerde set entiteitstypen in zowel de publieke als de private sector. Publieke instellingen — waaronder ministeries, overheidsdiensten, gemeenten en openbare universiteiten — moeten binnen één jaar na publicatie van de circulaire volledige conformiteit met niveau A bereiken. Partijen in de private sector die onder de circulaire vallen, hebben een nalevingstermijn van twee jaar. De reikwijdte in de private sector is breed en omvat expliciet e-commerceplatforms, banken en financiële instellingen, particuliere ziekenhuizen en zorgaanbieders, telecomoperators met 200.000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs.

Voor al deze entiteiten vormt niet-conforme linktekst een directe schending van de regelgeving. Stel een Turks e-commerceplatform voor dat productoverzichtspagina’s toont met herhaalde "Satın Al" (Buy Now) of "Devamını Oku" (Read More)-links zonder programmeerbare context. Een blinde gebruiker die vertrouwt op TalkBack, NVDA of VoiceOver kan dan niet bepalen naar welk product elke link verwijst, wat een 2.4.4-fout en een schending van de vereisten van de circulaire vormt. Evenzo zou het afsprakenportaal van een openbaar ziekenhuis dat alleen pictogramlinks voor navigatie gebruikt zonder toegankelijke namen, zowel de link-name-regel van axe als het mandaat van de circulaire schenden.

Naleving van 2.4.4 is niet slechts een technische afvinkactie. De circulaire geeft blijk van een bredere overheidsinzet voor digitale inclusie voor de ongeveer 8,5 miljoen burgers met een beperking in Turkije. Voor entiteiten binnen de reikwijdte is het proactief aanpakken van fouten rond het linkdoel — via ontwerpstandaarden in design systems, ontwikkelaarstraining en geautomatiseerde CI/CD-scans — zowel een wettelijke verplichting als een verstandige investering in bruikbaarheid en zoekprestaties. Niet-naleving binnen de voorgeschreven termijnen kan leiden tot handhavingsmaatregelen door de relevante toezichthoudende autoriteiten die in de circulaire zijn aangewezen.