WCAG 2.4.11: Focus niet verduisterd (minimum)

Wat Deze Regel Betekent

WCAG 2.4.11 Focus Not Obscured (Minimum) is een criterium op niveau AA dat is geïntroduceerd in WCAG 2.2 en een veelvoorkomend maar ernstig toegankelijkheidsprobleem aanpakt: wanneer een gefocust element volledig verborgen is achter een andere laag content op de pagina. Het criterium stelt dat wanneer een gebruikersinterfacecomponent toetsenbordfocus ontvangt, die component niet volledig verborgen mag zijn door door de auteur gecreëerde content.

Het sleutelwoord hier is volledig. WCAG 2.4.11 stelt de minimumnorm — het vereist alleen dat een deel van het gefocuste element zichtbaar blijft. Als een sticky navigatiebalk de bovenste helft van een gefocuste knop overlapt maar de onderste helft nog zichtbaar is, voldoet dat technisch gezien aan 2.4.11. Het strengere bijbehorende criterium, WCAG 2.4.12 Focus Not Obscured (Enhanced) op niveau AAA, gaat verder door te eisen dat de gefocuste component helemaal niet wordt verduisterd door door de auteur gecreëerde content — zelfs niet gedeeltelijk.

De typen door de auteur gecreëerde content die het vaakst verantwoordelijk zijn voor dit probleem zijn onder andere sticky of fixed-position headers en footers, cookie-toestemmingsbanners, chatsupport-widgets, notificatie-toasts, modale overlays, floating action buttons en onderste navigatiebalken in mobiel-responsieve layouts. Deze elementen worden gerenderd met behulp van CSS-eigenschappen zoals position: fixed, position: sticky of hoge z-index-waarden, waardoor ze boven de normale documentstroom zweven en mogelijk interactieve elementen bedekken die focus ontvangen.

Een pass betekent dat wanneer een toetsenbordgebruiker door interactieve elementen tabt, ten minste een deel van de visuele indicator van elk gefocust element te allen tijde zichtbaar is op het scherm — zelfs als een sticky UI-element een deel ervan overlapt. Een fail treedt op wanneer een gefocust element volledig verborgen is onder een door de auteur gecreëerde laag, wat betekent dat de gebruiker helemaal geen visuele aanwijzing heeft waar de focus zich op dat moment bevindt. Door de browser gerenderde content, zoals de eigen toolbar van de browser, telt niet als door de auteur gecreëerde content en valt daarom buiten de reikwijdte van dit criterium. Evenzo is content die de gebruiker zelf heeft verplaatst (zoals een door de gebruiker versleepbaar paneel) ook uitgesloten.

Dit criterium is van toepassing op alle interactieve HTML-elementen die standaard met het toetsenbord focusbaar zijn of focusbaar zijn gemaakt via tabindex, waaronder <a>, <button>, <input>, <select>, <textarea> en elementen met tabindex='0' of positieve tabindex-waarden.

Waarom Het Belangrijk Is

Toetsenbordnavigatie is fundamenteel voor toegankelijkheid voor meerdere groepen gebruikers. Mensen met motorische beperkingen die geen muis kunnen gebruiken, zijn volledig afhankelijk van toetsenborden, schakelapparaten of sip-and-puff-controllers om door een webpagina te navigeren. Mensen die blind zijn gebruiken schermlezers in combinatie met toetsenborden. Mensen met een beperkt gezichtsvermogen die toetsenbordnavigatie gebruiken zonder schermlezer, zijn sterk afhankelijk van de zichtbare focusindicator om te begrijpen waar ze zich bevinden. Wanneer dat gefocuste element verborgen is achter een sticky header of zwevende widget, zijn deze gebruikers feitelijk de weg kwijt — ze moeten herhaaldelijk op Tab drukken, hun positie raden of de taak helemaal opgeven.

Denk aan een concreet scenario uit de echte wereld: een rolstoelgebruiker met beperkte handmobiliteit is een vluchtboekingsformulier aan het invullen op de website van een Turkse luchtvaartmaatschappij. Diegene gebruikt de Tab-toets om door de formuliervelden te gaan. De pagina heeft een sticky cookie-toestemmingsbanner onderaan de viewport. Wanneer de gebruiker naar het laatste bevestigingsselectievakje tabt, wordt het selectievakje volledig onder de cookie-banner gerenderd. De gebruiker heeft geen visuele indicatie dat het selectievakje focus heeft. Diegene kan niet zien of de Tab-toetsaanslag heeft gewerkt, of er nogmaals op Tab moet worden gedrukt, of dat het selectievakje überhaupt verplicht is. Deze verwarring kan leiden tot het afbreken van het formulier, gemiste inzendingen of herhaalde toetsaanslagen die onbedoelde acties veroorzaken.

De impact reikt verder dan gebruikers met een beperking. Power users die toetsenbordnavigatie prefereren vanwege de snelheid — ontwikkelaars, data-entryprofessionals en ervaren gebruikers — profiteren ook van duidelijke focuszichtbaarheid. Volgens de Wereldgezondheidsorganisatie leven wereldwijd ongeveer 1,3 miljard mensen met een of andere vorm van beperking, en een aanzienlijk deel daarvan is afhankelijk van ondersteunende technologieën of toetsenbordnavigatie. In Turkije rapporteert het Turkse Statistische Instituut (TÜİK) specifiek dat ongeveer 12,7% van de bevolking een of andere vorm van beperking heeft, wat neerkomt op ongeveer 10 miljoen mensen die direct kunnen profiteren van verbeterd focusbeheer op digitale platforms.

Vanuit zakelijk perspectief verhogen verduisterde focusindicatoren het aantal afgebroken taken, verlagen ze de conversie en stellen ze organisaties bloot aan juridische en regelgevende risico’s. Sites die niet aan dit criterium voldoen, zullen waarschijnlijk ook zakken voor toegankelijkheidsaudits die onder de Turkse wet vereist zijn, waardoor hun vermogen om het officiële Erişilebilirlik Logosu (Toegankelijkheidslogo) te verkrijgen of te behouden in gevaar komt.

Gerelateerde Axe-core-regels

WCAG 2.4.11 is in axe-core geclassificeerd als een criterium dat handmatige tests vereist. Er is geen geautomatiseerde axe-core-regel die deze overtreding direct detecteert. Begrijpen waarom geautomatiseerde tools dit probleem niet betrouwbaar kunnen signaleren, helpt teams om betere handmatige testprocessen op te zetten.

• Handmatige test vereist — Focus verduisterd door fixed positioning: Geautomatiseerde tools kunnen niet detecteren of een gefocust element visueel verduisterd is, omdat dit vereist dat de pagina wordt gerenderd, de begrenzingsrechthoeken van alle fixed of sticky elementen tijdens runtime worden berekend en deze worden vergeleken met de begrenzingsrechthoek van het op dat moment gefocuste element. De afmetingen van de viewport, de scrollpositie en de dynamische staat van de pagina (zoals de vraag of een cookie-banner al is gesloten) beïnvloeden allemaal de uitkomst. Geen enkele statische analyse of DOM-inspectie kan deze visuele berekening betrouwbaar repliceren in alle mogelijke toestanden. Axe-core markeert dit criterium als handmatig omdat er een menselijke tester — of een geavanceerde visuele regressietool — nodig is om daadwerkelijk door de pagina te tabben en te observeren of gefocuste componenten verdwijnen achter overlappende lagen.
• Handmatige test vereist — Dynamische overlaycontent: Veel verduisterende elementen worden dynamisch via JavaScript geïnjecteerd na het initiële laden van de pagina — chat-widgets van derden, GDPR-compliancebanners, promotionele pop-ins en zwevende navigatiemenu’s. Geautomatiseerde scanners die de initiële DOM-snapshot analyseren, detecteren deze elementen mogelijk helemaal niet, of detecteren ze in een ingeklapte of verborgen staat die de werkelijke gebruikerservaring niet weerspiegelt. Handmatig testen door een toetsenbordgebruiker die met de pagina in volledig gerenderde, dynamische staat interageert, is de enige betrouwbare manier om deze scenario’s te detecteren.

Hoe te Testen

1. Voer eerst een geautomatiseerde toegankelijkheidsscan uit. Gebruik axe DevTools (browserextensie), Lighthouse in Chrome DevTools of een CI-geïntegreerde axe-core-scan om automatisch detecteerbare problemen op de pagina te identificeren. Hoewel 2.4.11 zelf handmatige verificatie vereist, kan een geautomatiseerde scan gerelateerde problemen aan het licht brengen, zoals ontbrekende focusindicatoren (2.4.7) of onjuiste z-index-stapeling die wijst op overlappende elementen. Noteer alle elementen die als potentieel problematisch zijn gemarkeerd voordat u met handmatig testen begint.
2. Identificeer alle fixed en sticky elementen op de pagina. Open de DevTools van de browser en inspecteer de CSS van de pagina. Zoek naar elementen die position: fixed of position: sticky gebruiken. Controleer ook op elementen met hoge z-index-waarden (bijv. 100 of hoger). Documenteer elk van deze elementen — headers, footers, banners, chat-widgets, cookiemeldingen — omdat dit de meest waarschijnlijke kandidaten zijn om gefocuste componenten te verduisteren. Verander de grootte van het browservenster om verschillende viewportgroottes te simuleren, waaronder tablet- en mobiele breedtes, omdat sticky/fixed elementen zich vaak anders gedragen op verschillende breakpoints.
3. Voer een volledige toetsenbord-tab-traversal uit. Klik buiten elk interactief element om ervoor te zorgen dat de focus bovenaan de pagina begint en druk vervolgens herhaaldelijk op Tab om door elk focusbaar element te gaan. Let goed op elk element zodra het focus krijgt. Let in het bijzonder op elementen die zich dicht bij de boven- of onderkant van de viewport bevinden, waar fixed headers of footers het meest waarschijnlijk overlappen. Als op enig moment de zichtbare focusring of het gemarkeerde element volledig verdwijnt achter een fixed laag, is dat een fout op 2.4.11. Gebruik ook Shift+Tab om in omgekeerde richting te traverseren, omdat scrollpositie en layout kunnen verschillen.
4. Test met NVDA en Firefox. Open NVDA (gratis, open-source schermlezer voor Windows) en start Firefox. Schakel de browse-modus van NVDA in en gebruik Tab om door de pagina te gaan. Hoewel NVDA elk gefocust element hoorbaar aankondigt, moet u ook het scherm visueel observeren. Noteer elk element waarbij NVDA focus aankondigt maar geen visuele focusindicator zichtbaar is vanwege verduisterende content. Deze combinatie wordt veel gebruikt in Turkije en wereldwijd en vertegenwoordigt een belangrijke combinatie van ondersteunende technologie.
5. Test met VoiceOver en Safari op macOS/iOS. Schakel VoiceOver in (Command+F5 op Mac) en gebruik Tab of de navigatiegebaren van VoiceOver om door focusbare elementen te gaan. Gebruik op iOS veeggebaren. Controleer of gefocuste elementen visueel aanwezig zijn en niet verborgen zijn onder fixed UI-lagen, vooral op mobiel waar navigatiebalken en cookiebanners een groter deel van de viewport kunnen innemen.
6. Test met JAWS en Chrome. Open JAWS (Job Access With Speech) en gebruik Chrome. Tab door alle interactieve elementen en let op elk moment waarop de JAWS-cursor naar een element gaat dat visueel verborgen is onder een fixed laag. JAWS wordt veel gebruikt in bedrijfs- en overheidsomgevingen, waardoor deze combinatie bijzonder belangrijk is voor het testen van websites van de publieke sector en bedrijven.
7. Test na gebruikersinteracties die de layout veranderen. Sluit cookiebanners, open en sluit navigatiemenu’s, activeer notificatie-toasts en open chat-widgets. Voer na elke statuswijziging een nieuwe Tab-traversal uit om ervoor te zorgen dat de nieuwe layout geen nieuwe gevallen introduceert waarin focus wordt verduisterd. Dynamische content is een veelvoorkomende bron van 2.4.11-fouten die pas na gebruikersinteractie optreden.
8. Test op meerdere scrollposities. Scroll naar het midden of de onderkant van een lange pagina en tab vervolgens door elementen in dat gebied. Fixed headers verduisteren mogelijk geen elementen dicht bij de bovenkant van de pagina, maar kunnen wel elementen bedekken die aan de bovenrand van de viewport verschijnen wanneer de gebruiker naar beneden scrollt. Controleer of geen enkele combinatie van scrollpositie en gefocust element resulteert in volledige visuele verberging.

Hoe te Oplossen

Sticky header overlapt gefocuste links — Onjuist

<!-- Sticky header with no scroll offset accommodation -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- No scroll-margin-top set; focused link at top of main scrolls under the header -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

Sticky header overlapt gefocuste links — Juist

<!-- Fixed header with scroll-margin-top applied to all focusable elements -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ensures the browser scrolls the element into view
       with enough clearance so the fixed header does not cover it -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- In your stylesheet: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- The 70px (header height + 10px buffer) keeps focused elements
     visible below the fixed header when the browser auto-scrolls. -->

Cookie-banner bedekt onderaan gefocust formulierveld — Onjuist

<!-- Cookie banner fixed at bottom with no accommodation for form fields above it -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- This checkbox renders in the viewport area covered by the cookie banner -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Cookie-banner bedekt onderaan gefocust formulierveld — Juist

<!-- Cookie banner pushes page content up instead of overlapping it -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- In your stylesheet: -->
<!-- .cookie-banner-flow { position: static; } instead of position: fixed -->
<!-- Alternatively, if fixed positioning is required for design reasons,
     add scroll-margin-bottom to all focusable elements equal to the
     banner height, or apply padding-bottom to <body> equal to
     the banner height so content is never hidden beneath it. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Chat-widget van derden overlapt gefocuste knop — Onjuist

<!-- Third-party chat widget injected in bottom-right corner
     with a high z-index, obscuring the focused Submit button -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Injected by third-party script, covers 120x120px in bottom-right -->
</div>

<section class='cta-section'>
  <!-- Button positioned in the bottom-right area of the layout;
       when focused, it is completely hidden beneath the chat widget -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

Chat-widget van derden overlapt gefocuste knop — Juist

<!-- Approach 1: Reposition the chat widget to avoid overlapping focusable content -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Widget repositioned to bottom-left, away from the CTA button -->
</div>

<!-- Approach 2: Ensure the button has scroll-margin that keeps it
     clear of the widget when focused -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Approach 3: Use JavaScript to detect focus events on elements
     near the widget's bounding box and temporarily collapse or
     move the widget so the focused element is visible. -->
<script>
  // Example: collapse widget when nearby element gains focus
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Additional logic to reposition or minimize widget
    });
  });
</script>

Veelvoorkomende Fouten

• position: fixed toepassen op headers en footers zonder scroll-margin-top of scroll-margin-bottom toe te voegen aan focusbare elementen. De native focus-scrolling van de browser houdt geen rekening met fixed overlappende elementen, waardoor gefocuste items naar de boven- of onderkant van de viewport scrollen en uiteindelijk achter de fixed laag terechtkomen. Een globale CSS-regel zoals * { scroll-margin-top: [header-height]px; } lost dit efficiënt op.
• body { padding-top: 60px; } instellen om een fixed header te compenseren maar vergeten een equivalente scroll-margin-top voor toetsenbordfocus toe te voegen. De padding zorgt ervoor dat content niet in eerste instantie verborgen is, maar wanneer toetsenbordfocus de automatische scrollfunctie van de browser activeert, kan het scroll-doel nog steeds achter de header verdwijnen. Beide benaderingen moeten samen worden gebruikt.
• z-index: 9999 gebruiken op promotiebanners of chat-widgets zonder te controleren welke focusbare elementen binnen hun footprint vallen. Een hoge z-index garandeert dat de overlay boven alles wordt gerenderd, inclusief gefocuste knoppen en links, waardoor dit de meest voorkomende hoofdoorzaak is van 2.4.11-fouten.
• Cookie-banners via JavaScript sluiten zonder ze direct uit de layout te verwijderen. Als het DOM-element van de banner blijft bestaan met visibility: hidden of opacity: 0 maar nog steeds ruimte inneemt of een niet-nul z-index heeft, kan het in bepaalde browserscenario’s gefocuste elementen visueel blijven verduisteren.
• Widgets van derden (live chat, toegankelijkheidsoverlays, GDPR-managers) insluiten zonder hun impact op de zichtbaarheid van toetsenbordfocus te verifiëren. Scripts van derden injecteren vaak fixed-position elementen met zeer hoge z-index-waarden. Teams moeten deze integraties expliciet testen als onderdeel van hun toegankelijkheids-QA-proces.
• Verzuimen om 2.4.11 te testen na wijzigingen in responsieve breakpoints. Een sticky navigatiebalk die op desktop 60px hoog is, kan op tablet uitklappen tot 120px wanneer een hamburgermenu is geopend, waardoor plotseling een veel groter gebied wordt verduisterd en nieuwe fouten ontstaan op breakpoints die op desktop slaagden.
• scroll-margin-top alleen toepassen op ankerdoelen (<h2>, <section>) maar niet op interactieve elementen zoals <input>, <button> en <a>. Anker-scroll-offset wordt vaak aangepakt, maar automatische toetsenbordfocus-scroll naar niet-ankerelementen wordt op dezelfde manier beïnvloed en moet door dezelfde CSS-regel worden gedekt.
• Aannemen dat omdat een gefocust element door een schermlezer wordt aangekondigd, het ook visueel zichtbaar is. Schermlezers benaderen de toegankelijkheidsboom, niet de visuele rendering. Een element kan volledig verborgen zijn achter een fixed overlay en toch correct worden aangekondigd door NVDA of JAWS. Dit zijn twee afzonderlijke kwesties — 2.4.11 gaat specifiek over visuele focuszichtbaarheid voor ziende toetsenbordgebruikers.
• Verzuimen om focusverduistering te testen na routewijzigingen in single-page applications (SPA). In React-, Vue- of Angular-apps renderen routeovergangen vaak fixed headers opnieuw met bijgewerkte status, en focusbeheer tijdens navigatie kan focus plaatsen op elementen die onmiddellijk worden verduisterd door een opnieuw gemonteerde sticky header voordat de gebruiker de nieuwe pagina ziet.
• Uitsluitend vertrouwen op geautomatiseerde testtools en concluderen dat er geen 2.4.11-problemen bestaan omdat geen enkele geautomatiseerde regel de pagina heeft gemarkeerd. Omdat axe-core geen geautomatiseerde regel voor dit criterium heeft, betekent een schone geautomatiseerde rapportage niet dat de pagina slaagt. Handmatige toetsenbord-traversal over alle viewportgroottes en paginastaten is verplicht.

Relatie met de Turkse Toegankelijkheidsregelgeving

WCAG 2.4.11 Focus Not Obscured (Minimum) is direct relevant voor het opkomende juridische toegankelijkheidskader 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 in lijn zijn met WCAG 2.2. Deze circulaire vertegenwoordigt een aanzienlijke uitbreiding van de inzet van Turkije voor digitale inclusie en legt afdwingbare verplichtingen op aan een breed scala van entiteiten die actief zijn op de Turkse digitale markt.

De circulaire heeft betrekking op een brede groep organisaties, waaronder publieke instellingen en overheidsinstanties, e-commerceplatforms, banken en aanbieders van financiële diensten, ziekenhuizen en zorgorganisaties, telecombedrijven met meer dan 200.000 abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE). Al deze entiteiten worden geacht ervoor te zorgen dat hun digitale interfaces — websites, mobiele applicaties en webgebaseerde tools — voldoen aan niveau AA van WCAG 2.2.

Omdat WCAG 2.4.11 een criterium op niveau AA is in WCAG 2.2, is naleving van deze regel niet optioneel voor de betrokken entiteiten. Organisaties die het officiële Erişilebilirlik Logosu (Toegankelijkheidslogo), uitgegeven door het Ministerie van Gezin en Sociale Diensten (Aile ve Sosyal Hizmetler Bakanlığı), willen verkrijgen of behouden, moeten voldoen aan niveau AA. Het Toegankelijkheidslogo fungeert als een publiek signaal van inzet voor digitale inclusie en wordt in toenemende mate verwacht door Turkse consumenten en overheidsinkooporganen.

In praktische termen betekent dit dat Turkse websites van publieke instellingen met sticky navigatieheaders, e-commercesites met persistente promotiebanners, bankportalen met zwevende help-widgets en systemen voor zorgafspraken met cookie-toestemmingsoverlays allemaal moeten worden getest en hersteld op focusverduistering onder 2.4.11. Fouten in dit criterium komen vooral voor in complexe, marketingzware interfaces — precies het type sites dat wordt geëxploiteerd door de grote commerciële entiteiten die onder de circulaire vallen.

Organisaties die onder de circulaire vallen, moeten 2.4.11-testen opnemen in hun reguliere toegankelijkheidsauditcycli. Aangezien dit criterium handmatige tests vereist, zal uitsluitend vertrouwen op geautomatiseerde scans niet voldoen aan de zorgvuldigheidseisen. Turkse entiteiten die volledige naleving nastreven, wordt geadviseerd om handmatige toetsenbord-traversaltests uit te voeren over alle viewportgroottes en dynamische paginastaten als onderdeel van hun conformiteitsdocumentatie, en om eventuele geïdentificeerde focusverduisteringsproblemen aan te pakken als onderdeel van hun herstelroadmap vóór aanvraag of verlenging van het toegankelijkheidslogo.