WCAG 1.4.13: Inhoud bij hoveren of focus

Wat Deze Regel Betekent

WCAG 1.4.13 behandelt een veelvoorkomend interactiepatroon op het web: content die zichtbaar wordt wanneer een gebruiker met een aanwijzer over een element zweeft of er met het toetsenbord de focus naartoe verplaatst. Dit omvat tooltips, submenu’s, aangepaste dropdown-hints, datumprikker-popovers en elke andere overlay die verschijnt als reactie op hover- of focusgebeurtenissen. Het criterium is van toepassing wanneer dergelijke content niet native door de browser wordt aangestuurd (bijvoorbeeld: de native tooltip van het attribuut title is uitgezonderd) en stelt drie kernvereisten vast die allemaal gelijktijdig moeten worden vervuld.

Afsluitbaar: De gebruiker moet de extra content kunnen sluiten zonder de aanwijzerfocus of toetsenbordfocus te verplaatsen. De standaardmethode hiervoor is het indrukken van de Escape-toets. Dit voorkomt dat de overlay andere pagina-inhoud op een manier bedekt die de gebruiker niet kan oplossen — met name cruciaal voor gebruikers die het scherm hebben vergroot en niet eenvoudig ergens anders kunnen kijken.

Hoverbaar: Als de extra content verscheen omdat de gebruiker over een triggerelement zweefde, moet de gebruiker de aanwijzer over de nieuw verschenen content kunnen bewegen zonder dat deze verdwijnt. Als een tooltip verdwijnt zodra de cursor het triggerelement verlaat, kunnen gebruikers geen lange content lezen, geen tekst eruit kopiëren of links of bedieningselementen erin activeren.

Persistent: De extra content moet zichtbaar blijven totdat de hover- of focustrigger wordt verwijderd, de gebruiker deze sluit (bijvoorbeeld via Escape), of de informatie niet langer geldig is. Content mag niet verdwijnen op een timer of na een willekeurige vertraging terwijl de aanwijzer of focus zich nog op de trigger of de overlay zelf bevindt.

Een voldoende beoordeling vereist dat aan alle drie de voorwaarden wordt voldaan. Er is sprake van een onvoldoende als ook maar één voorwaarde ontbreekt — bijvoorbeeld een tooltip die verdwijnt wanneer de aanwijzer van de trigger naar de tooltip beweegt (niet hoverbaar), of een tooltip die automatisch sluit na drie seconden (niet persistent), of een tooltip die niet kan worden gesloten zonder de focus te verplaatsen (niet afsluitbaar). De enige officiële uitzondering die WCAG maakt, is wanneer de visuele presentatie van de extra content volledig wordt aangestuurd door de user agent — browser-native tooltips die uitsluitend door het attribuut title worden geproduceerd vallen in deze categorie en zijn uitgezonderd, al hebben ze hun eigen toegankelijkheidsbeperkingen.

Waarom Het Belangrijk Is

Dit criterium komt in de eerste plaats ten goede aan gebruikers die moeite hebben met het bedienen van standaard muis- of toetsenbordinteracties, gebruikers die afhankelijk zijn van schermvergroting en gebruikers die informatie langzamer verwerken. Begrijpen wie wordt getroffen helpt teams om de oplossing op de juiste manier te prioriteren.

Gebruikers met een beperkt gezichtsvermogen gebruiken vaak schermvergrotingssoftware zoals ZoomText of de ingebouwde OS-vergroter, wat betekent dat zij slechts een klein deel van het scherm op hoge zoomniveaus zien. Wanneer een tooltip verschijnt, kan deze gedeeltelijk buiten beeld zijn en moet de gebruiker ernaartoe pannen. Als de tooltip verdwijnt zodra de aanwijzer de trigger verlaat, kan de gebruiker niet pannen om deze te lezen. Volgens de Wereldgezondheidsorganisatie leven wereldwijd ongeveer 2,2 miljard mensen met een vorm van visuele beperking, en een aanzienlijk deel van de computergebruikers onder hen vertrouwt op vergroting in plaats van een schermlezer.

Gebruikers met motorische beperkingen — waaronder mensen met de ziekte van Parkinson, tremoren of beperkte fijne motoriek — kunnen alternatieve aanwijsapparaten, hoofdaanwijzers of oogvolgsystemen gebruiken. Nauwkeurige aanwijzerbediening is voor deze gebruikers moeilijk, wat betekent dat het verplaatsen van een klein triggerelement naar een kleine tooltip zonder per ongeluk beide te verlaten bijna onmogelijk kan zijn als het hovergebied niet vergevingsgezind is. De hoverbare eis speelt hier direct op in.

Gebruikers met cognitieve beperkingen kunnen langzaam lezen of content moeten herlezen. Een tooltip die automatisch wordt gesloten na enkele seconden geeft deze gebruikers niet genoeg tijd om de informatie op te nemen, en een tooltip die niet kan worden gesloten zonder de focus te verplaatsen kan hun aandacht vastzetten in een verwarrende interactietoestand.

Neem een concreet scenario: een bankwebsite toont details over de rente op een rekening in een tooltip die verschijnt wanneer de gebruiker over een klein informatie-icoon zweeft. Een gebruiker met een beperkt gezichtsvermogen die tot 400% heeft ingezoomd, ziet slechts een deel van de pagina tegelijk. Ze zweven over het icoon, de tooltip verschijnt, en ze beginnen de aanwijzer naar de tooltip te verplaatsen om de kleine lettertjes te lezen — maar de tooltip verdwijnt onmiddellijk omdat deze alleen is gekoppeld aan de hoverstatus van het bovenliggende element. De gebruiker kan de vereiste informatie over de voorwaarden niet raadplegen. Dit is niet slechts een gebruiksonvriendelijkheid; in gereguleerde sectoren kan het een juridische toegankelijkheidsbarrière vormen.

Naast de impact specifiek voor mensen met een beperking verbetert een correcte implementatie van dit criterium ook de algemene bruikbaarheid voor alle gebruikers op apparaten met een combinatie van touch en toetsenbord, vermindert het supportverzoeken door “verdwijnende” UI-elementen en is het een signaal van interfacekwaliteit voor zowel gebruikers als auditors.

Gerelateerde Axe-core-regels

WCAG 1.4.13 vereist handmatige tests. Geautomatiseerde tools kunnen overtredingen niet betrouwbaar detecteren omdat het criterium tijdsgebonden en aanwijzerbewegingsgedrag omvat dat statische DOM-analyse niet kan beoordelen. Geen enkele afzonderlijke axe-core-regel komt direct overeen met dit criterium, maar de volgende overwegingen leggen uit waarom automatisering tekortschiet en waar je op moet letten tijdens handmatige beoordeling.

• Handmatige test vereist — hovergedrag: Geautomatiseerde scanners inspecteren de DOM en CSSOM op één moment; ze kunnen niet simuleren dat een aanwijzer van een triggerelement naar een nieuw gerenderde tooltip wordt verplaatst en observeren of de tooltip zichtbaar blijft. Een tool zou theoretisch kunnen detecteren dat een CSS-:hover-pseudoklasse een kindelement verbergt wanneer de ouder de hover verliest, maar kan zonder het simuleren van aanwijzerpaden niet onderscheiden tussen een opzettelijke sluiting en een schending van de hoverbare eis.
• Handmatige test vereist — Escape-afsluiting: Detecteren of het indrukken van Escape een overlay sluit, vereist JavaScript-eventsimulatie die verder gaat dan de huidige regelset van axe-core. Axe kan ontbrekende ARIA-rollen op pop-ups of ontbrekende aria-expanded-attributen signaleren, maar kan niet verifiëren dat een keydown-listener voor Escape is gekoppeld aan een sluitfunctie en het element daadwerkelijk verbergt.
• Handmatige test vereist — persistentie / automatisch sluiten: Een tooltip die zichzelf via een setTimeout-aanroep na drie seconden verbergt, lijkt volledig geldig in een statische scan die binnen dat tijdsvenster wordt uitgevoerd. Alleen een tester die de overlay in de tijd observeert — of de JavaScript-broncode bekijkt — kan een timer voor automatisch sluiten als een overtreding identificeren.
• Aanvullende axe-regels om naast handmatige controles uit te voeren: Hoewel ze 1.4.13 niet direct testen, kunnen regels zoals aria-tooltip-name (zorgen dat tooltips toegankelijke namen hebben), color-contrast (zorgen dat tooltiptekst leesbaar is) en focus-visible (zorgen dat gefocuste triggers visueel herkenbaar zijn) gerelateerde problemen aan het licht brengen die de impact van 1.4.13-fouten vergroten.

Hoe te Testen

1. Geautomatiseerde baselinescan: Voer axe DevTools of Lighthouse uit op de pagina met hover-/focustriggered content. Noteer eventuele gemarkeerde problemen met tooltiprollen, contrast of focuszichtbaarheid — deze bevestigen geen naleving van 1.4.13 maar vormen een basislijn. Leg vast welke elementen overlaycontent activeren zodat je ze in de handmatige stappen kunt targeten.
2. Identificeer alle hover-/focustriggered content: Scroll door de pagina en zweef systematisch over elk interactief element — icoonknoppen, links met extra beschrijvingen, hints bij formuliervelden, navigatie-items, kolomkoppen in datatabellen en datapunten in grafieken. Noteer elk element dat extra content laat verschijnen.
3. Test de hoverbare eis: Zweef voor elke geïdentificeerde trigger erover om de overlay te tonen en verplaats vervolgens de aanwijzer langzaam van het triggerelement naar de overlaycontent zelf. De overlay moet gedurende deze beweging zichtbaar blijven. Als deze verdwijnt voordat de aanwijzer deze bereikt, voldoet het niet aan het criterium.
4. Test de afsluitbare eis: Terwijl een overlay zichtbaar is (geactiveerd door hover of toetsenbordfocus), druk je op de Escape-toets. De overlay moet sluiten. Als deze niet sluit, voldoet het niet aan het criterium. Voer deze test uit terwijl de aanwijzer nog op de trigger staat en ook terwijl de aanwijzer zich boven de overlay bevindt.
5. Test de persistente eis: Activeer een overlay en laat vervolgens je aanwijzer minstens 10–15 seconden stil op de trigger of de overlay staan. De overlay moet gedurende deze tijd zichtbaar blijven. Als deze vervaagt, een timeout heeft of verdwijnt zonder gebruikersactie, voldoet het niet aan het criterium.
6. Alleen-toetsenbordtest: Navigeer met Tab door de pagina met alleen het toetsenbord. Wanneer de focus op een trigger landt die extra content toont, controleer dan: (a) de content verschijnt, (b) het indrukken van Escape sluit deze, en (c) de content verdwijnt niet vanzelf terwijl de focus op de trigger blijft. Gebruik NVDA met Firefox, JAWS met Chrome en VoiceOver met Safari om te bevestigen dat schermlezers de content ook correct weergeven.
7. Test met schermvergroting: Stel de browserzoom in op 400% of activeer vergroting op OS-niveau. Herhaal de hovertests. Controleer of een gebruiker die de viewport moet pannen om de tooltip te bereiken dit kan doen zonder dat de tooltip verdwijnt.
8. Beoordeel de JavaScript-broncode: Doorzoek de codebase op setTimeout-, mouseleave-, mouseout- en blur-eventhandlers die zijn gekoppeld aan logica om overlays te verbergen. Controleer dat verberglogica niet wordt geactiveerd terwijl de aanwijzer zich boven de overlay bevindt of terwijl de trigger de focus behoudt, en dat er geen timer voor automatisch sluiten is ingesteld.

Hoe te Oplossen

Tooltip alleen met CSS die verdwijnt bij mouseleave — Onjuist

<!-- Tooltip wordt alleen getoond via CSS :hover op de ouder; verdwijnt zodra
     de aanwijzer de trigger verlaat richting de tooltiptekst -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip'>This is the tooltip content.</span>
</span>

<!-- CSS (illustratief) -->
<!--
.tooltip { display: none; }
.tip-wrapper:hover .tooltip { display: block; }
-->

Tooltip alleen met CSS die verdwijnt bij mouseleave — Juist

<!-- Juist: tooltip wordt ook getoond wanneer de aanwijzer zich boven de tooltip zelf bevindt,
     en de ruimte tussen trigger en tooltip is afgedekt zodat aanwijzerbeweging
     de overlay niet per ongeluk sluit. -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip' role='tooltip' id='tip1'>This is the tooltip content.</span>
</span>

<!-- CSS (illustratief) -->
<!--
.tooltip { display: none; position: absolute; }
.tip-wrapper:hover .tooltip,
.tooltip:hover { display: block; }
/* Gebruik padding of een transparante pseudo-elementbrug tussen trigger en tooltip */
-->

JavaScript-tooltip zonder Escape-afsluiting — Onjuist

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
// Alleen mouseenter/mouseleave — geen toetsenbord- of Escape-afhandeling
document.querySelector('button').addEventListener('mouseenter', () => {
  document.getElementById('tip2').removeAttribute('hidden');
});
document.querySelector('button').addEventListener('mouseleave', () => {
  document.getElementById('tip2').setAttribute('hidden', '');
});
</script>

JavaScript-tooltip zonder Escape-afsluiting — Juist

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
const btn = document.querySelector('button');
const tip = document.getElementById('tip2');

function showTip() { tip.removeAttribute('hidden'); }
function hideTip() { tip.setAttribute('hidden', ''); }

// Tonen bij hover en focus
btn.addEventListener('mouseenter', showTip);
btn.addEventListener('focus', showTip);

// Verbergen alleen wanneer de aanwijzer zowel de trigger ALS de tooltip verlaat
btn.addEventListener('mouseleave', (e) => {
  // Korte vertraging maakt het mogelijk dat de aanwijzer de tooltip bereikt
  setTimeout(() => {
    if (!tip.matches(':hover') && !btn.matches(':hover')) hideTip();
  }, 100);
});
tip.addEventListener('mouseleave', () => {
  if (!btn.matches(':hover')) hideTip();
});

// Verbergen bij blur (toetsenbord)
btn.addEventListener('blur', hideTip);

// Afsluitbaar via Escape-toets — vereist door 1.4.13
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape' && !tip.hidden) hideTip();
});
</script>

Automatisch sluitende tooltip met setTimeout — Onjuist

<button id='info-btn'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
document.getElementById('info-btn').addEventListener('mouseenter', () => {
  const t = document.getElementById('tip3');
  t.removeAttribute('hidden');
  // Overtreding: sluit automatisch na 3 seconden ongeacht de gebruikersstatus
  setTimeout(() => t.setAttribute('hidden', ''), 3000);
});
</script>

Automatisch sluitende tooltip met setTimeout — Juist

<button id='info-btn' aria-describedby='tip3'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
const btn2 = document.getElementById('info-btn');
const tip3 = document.getElementById('tip3');

// Geen setTimeout — tooltip blijft zichtbaar totdat de gebruiker hover/focus verwijdert of Escape indrukt
function show() { tip3.removeAttribute('hidden'); }
function hide() {
  setTimeout(() => {
    if (!tip3.matches(':hover') && !btn2.matches(':hover') && document.activeElement !== btn2) {
      tip3.setAttribute('hidden', '');
    }
  }, 100);
}

btn2.addEventListener('mouseenter', show);
btn2.addEventListener('focus', show);
btn2.addEventListener('mouseleave', hide);
btn2.addEventListener('blur', hide);
tip3.addEventListener('mouseleave', hide);
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') tip3.setAttribute('hidden', '');
});
</script>

Veelvoorkomende Fouten

• Alleen CSS-:hover gebruiken zonder de ruimte tussen trigger en tooltip af te dekken: Wanneer er zelfs maar een ruimte van 1–2 px is tussen het triggerelement en de tooltipcontainer, zorgt het verplaatsen van de aanwijzer ertussen voor het verlies van de hoverstatus, waardoor de tooltip verdwijnt voordat de gebruiker deze bereikt. Gebruik een transparant pseudo-element of overlappende padding om deze ruimte te overbruggen.
• Verberglogica koppelen aan mouseleave op de trigger zonder te controleren of de aanwijzer naar de tooltip is verplaatst: De tooltip verdwijnt op het moment dat de cursor de trigger verlaat, zelfs als de bestemming de tooltip zelf is. Controleer altijd tip.matches(':hover') voordat je verbergt, of gebruik een korte debouncevertraging.
• Vergeten focus- en blur-events te koppelen naast mouseenter en mouseleave: Gebruikers die uitsluitend het toetsenbord gebruiken en naar de trigger tabben, zullen de tooltip nooit zien als alleen muisgebeurtenissen worden afgehandeld, waardoor de bijbehorende informatie volledig ontoegankelijk is zonder muis.
• Geen Escape-keylistener toevoegen, in de veronderstelling dat wegklikken voldoende is: Toetsenbordgebruikers en gebruikers met schermvergroting kunnen niet eenvoudig “wegklikken” van een overlay. Escape is de verwachte en vereiste afsluitmethode voor dit criterium.
• De Escape-listener alleen op het triggerelement plaatsen in plaats van op het document: Als de gebruiker de focus naar de tooltip of naar een ander element verplaatst, wordt een listener die is beperkt tot de trigger niet geactiveerd. De Escape-handler moet op het document of een gedeelde voorouder staan die altijd keyevents ontvangt wanneer de overlay open is.
• setTimeout gebruiken om tooltips na een vaste tijdsduur automatisch te sluiten: Elke timergebaseerde afsluiting die wordt geactiveerd terwijl de aanwijzer zich nog op de trigger of tooltip bevindt, of terwijl de trigger nog toetsenbordfocus heeft, is een directe schending van de persistente eis. Verwijder alle timers voor automatisch sluiten uit overlays die door hover/focus worden geactiveerd.
• Tooltipzichtbaarheid uitsluitend aansturen via vervanging van het title-attribuut met aangepaste styling: Ontwikkelaars die de native title-tooltip verwijderen en vervangen door een aangepaste versie, moeten alle drie de 1.4.13-vereisten zelf implementeren. De uitzondering voor browser-native tooltips geldt niet voor aangepaste JavaScriptreproducties van hetzelfde patroon.
• Niet testen met schermvergroting op 400% zoom: Een tooltip die bij normale zoom toegankelijk lijkt, kan bij hoge zoomniveaus gedeeltelijk buiten beeld zijn, waardoor de gebruiker moet pannen — en als deze verdwijnt voordat de gebruiker ernaartoe kan pannen, faalt de test die bij 100% zoom slaagde in echte gebruiksomstandigheden.
• pointer-events: none toepassen op de tooltipcontainer: Deze CSS-eigenschap voorkomt dat de aanwijzer ooit als “boven” de tooltip wordt beschouwd, waardoor het onmogelijk wordt om aan de hoverbare eis te voldoen, ongeacht andere logica. Tooltips waarmee gebruikers mogelijk moeten interageren of waar ze simpelweg overheen moeten kunnen zweven om ze zichtbaar te houden, mogen nooit pointer-events: none hebben.
• ARIA-role='tooltip' op zichzelf als voldoende voor naleving beschouwen: Het toevoegen van role='tooltip' en aria-describedby is belangrijk voor schermlezer-toegankelijkheid, maar pakt een andere laag van het probleem aan. Deze ARIA-attributen maken content niet automatisch afsluitbaar, hoverbaar of persistent — het interactiegedrag moet nog steeds expliciet worden geïmplementeerd.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidentiële Circulaire 2025/10, gepubliceerd in het Staatsblad met nummer 32933 op 21 juni 2025, stelt een formeel toegankelijkheidsmandaat vast dat WCAG-standaarden door verwijzing opneemt. De circulaire vereist dat onder de regeling vallende entiteiten webtoegankelijkheidsmaatregelen implementeren die in lijn zijn met internationaal erkende richtlijnen, en conformiteit op niveau AA — waaronder WCAG 1.4.13 — wordt zowel sterk aangemoedigd als vereist voor entiteiten die het Toegankelijkheidslogo (Erişilebilirlik Logosu) willen verkrijgen dat wordt uitgegeven door het Ministerie van Gezin en Sociale Diensten (Aile ve Sosyal Hizmetler Bakanlığı).

De circulaire heeft betrekking op een breed scala aan entiteitstypen die in Turkije actief zijn. Overheidsinstellingen en -organen op alle bestuursniveaus zijn verplicht hun digitale diensten toegankelijk te maken. In de private sector strekt de verplichting zich uit tot e-commerceplatforms, banken en aanbieders van financiële diensten, ziekenhuizen en particuliere zorginstellingen, telecomoperators met 200.000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die opereren onder een vergunning van het Ministerie van Nationaal Onderwijs (Millî Eğitim Bakanlığı).

WCAG 1.4.13 is bijzonder relevant in Turkse digitale contexten waar tooltip- en popoverpatronen veel worden gebruikt in e-overheidsportalen (zoals e-Devlet-integraties), bank- en fintechinterfaces die kosten- of tariefinformatie in tooltips tonen, en systemen voor zorgafspraken die extra instructies via hover-geactiveerde overlays tonen. Een bankplatform dat niet voldoet aan 1.4.13 kan voorkomen dat klanten met een beperkt gezichtsvermogen rentetoelichtingen die via een tooltip worden verstrekt, kunnen lezen — een scenario met zowel toegankelijkheids- als financiële consumentenbeschermingsimplicaties.

Voor entiteiten die het Erişilebilirlik Logosu nastreven, zal een toegankelijkheidsaudit handmatige tests van hover- en focusgedrag omvatten, juist omdat geautomatiseerde tools deze overtredingen niet kunnen detecteren. Organisaties die een toegankelijkheidsoverlay-SDK zoals Accsible gebruiken, moeten ervoor zorgen dat alle tooltips, guided tour-popovers of contextuele helppanels die door de SDK zelf als widget worden geïnjecteerd volledig voldoen aan alle drie de 1.4.13-vereisten — afsluitbaar via Escape, hoverbaar zonder te verdwijnen en persistent tot gebruikersactie. Als dit niet gebeurt, worden nieuwe barrières geïntroduceerd door precies het hulpmiddel dat bedoeld is om de toegankelijkheid te verbeteren, wat zowel de naleving van regelgeving als het vertrouwen van gebruikers ondermijnt.