WCAG 3.2.1: Bij focus

Wat Deze Regel Betekent

WCAG Succescriterium 3.2.1 On Focus (Niveau A) stelt: “If any component receives focus, it does not initiate a change of context.” In gewone taal betekent dit dat de handeling van het verplaatsen van de focus naar een interactief element — door op Tab, Shift+Tab, pijltjestoetsen of een ander toetsenbordmechanisme te drukken — op zichzelf niet mag veroorzaken dat er iets dramatisch en onverwachts op de pagina gebeurt.

Een contextwijziging wordt door WCAG gedefinieerd als een grote wijziging in de inhoud van de pagina die, als deze zonder medeweten van de gebruiker wordt uitgevoerd, de gebruiker kan desoriënteren. De specificatie identificeert vier concrete soorten contextwijzigingen: wijzigingen aan de user agent (zoals het openen van een nieuw browservenster of een nieuw tabblad), wijzigingen aan de viewport (zoals automatisch scrollen naar een ver verwijderd deel van de pagina), wijzigingen aan de focus zelf (zoals het automatisch verplaatsen van de focus naar een andere plek) en wijzigingen aan de inhoud die de betekenis van de pagina aanzienlijk veranderen (zoals het verzenden van een formulier of het laden van een volledig andere weergave).

Het belangrijkste onderscheid dat het criterium maakt, is dat tussen focus ontvangen en het activeren van een bedieningselement. Met Tab naar een knop gaan en daardoor een formulier laten verzenden is een overtreding. Maar op Enter of Spatie drukken terwijl die knop de focus heeft — een bewuste, doelgerichte activatie — is volledig acceptabel en zelfs verwacht. De intentie van de gebruiker is wat een voorspelbare interactie scheidt van een desoriënterende.

Veelvoorkomende patronen die niet aan dit criterium voldoen, zijn onder andere:

• Een <select>-dropdown die automatisch naar een nieuwe URL navigeert zodra een optie de focus krijgt (niet wanneer de gebruiker zijn keuze bevestigt).
• Een datumkiezer-widget die een modaal dialoogvenster opent op het moment dat een van de invoervelden de focus krijgt, zonder enige activatie door de gebruiker.
• Een carrousel of diavoorstelling die automatisch naar de volgende dia gaat wanneer de navigatiebolletjes de focus krijgen.
• Een tooltip of popover die, wanneer deze door focus wordt geactiveerd, tegelijkertijd de toetsenbordfocus zonder waarschuwing naar zichzelf verplaatst, waardoor de gebruiker op een onverwachte plek terechtkomt.
• Een zoekveld dat onmiddellijk een formulier verzendt en de pagina herlaadt wanneer het de focus krijgt.

Patronen die expliciet geen overtreding zijn, omvatten: een tooltip of beschrijvingspaneel dat visueel verschijnt maar de focus niet verplaatst of de primaire inhoud van de pagina niet wijzigt; een focusindicator (zoals een omlijning of ring) die rond het gefocuste element verschijnt; of een element dat uitklapt om extra inline-inhoud te tonen, zolang de focus blijft waar de gebruiker die heeft geplaatst.

Er zijn geen officiële uitzonderingen gedefinieerd in WCAG 3.2.1. Het criterium is universeel van toepassing op alle UI-componenten op een pagina. Het WCAG Understanding-document merkt echter op dat contextwijzigingen die worden geactiveerd door een bewuste actie van de gebruiker (klik, Enter, Spatie) buiten de reikwijdte van dit criterium vallen, dat uitsluitend betrekking heeft op de passieve handeling van focus ontvangen.

Waarom Het Belangrijk Is

Het On Focus-criterium valt onder Principe 3 — Begrijpelijk — omdat voorspelbaarheid een fundamentele voorwaarde is voor bruikbaarheid. Wanneer een pagina zich onverwacht gedraagt als reactie op alleen focus, variëren de gevolgen van lichte verwarring tot volledig verlies van toegang, afhankelijk van de behoeften en hulpmiddelen van de gebruiker.

Gebruikers die uitsluitend het toetsenbord gebruiken (mensen die geen muis kunnen gebruiken vanwege motorische beperkingen, RSI of verlamming) zijn volledig afhankelijk van toetsenbordnavigatie. Wanneer het met Tab naar een formulierveld gaan een herladen van de pagina triggert, kunnen zij alle gegevens verliezen die ze al hebben ingevoerd en worden ze mogelijk van hun doel weggeleid. Herstellen van zo’n verstoring kan veel tijd en moeite kosten — of ze geven het simpelweg helemaal op.

Schermlezersgebruikers (die vaak ook uitsluitend het toetsenbord gebruiken) worden geconfronteerd met een extra laag desoriëntatie. Schermlezers kondigen het element aan dat momenteel de focus heeft. Als de focus onverwacht naar een nieuw element springt — bijvoorbeeld een modaal dat automatisch is geopend — kondigt de schermlezer de nieuwe context aan zonder de gebruiker enig referentiekader te geven voor wat er zojuist is gebeurd of waarom. Dit is vergelijkbaar met zonder waarschuwing fysiek opgepakt worden en naar een andere kamer verplaatst worden.

Gebruikers met cognitieve beperkingen, waaronder mensen met ADHD, angststoornissen of geheugenstoornissen, zijn afhankelijk van voorspelbare interfaces om een mentaal model van een pagina op te bouwen en te onderhouden. Plotselinge, onverklaarde contextwijzigingen vernietigen dat model en veroorzaken verwarring, angst en fouten. Een studie van het WebAIM Million-project laat consequent zien dat complexe interactieve componenten met onverwacht gedrag tot de belangrijkste bronnen van toegankelijkheidsklachten behoren bij gebruikers met cognitieve beperkingen.

Gebruikers met een beperkt gezichtsvermogen die schermvergrotingssoftware gebruiken (zoals ZoomText of Windows Vergrootglas) zien slechts een klein deel van het scherm tegelijk. Als focus een automatische scroll of navigatie veroorzaakt, kan de relevante inhoud volledig buiten hun ingezoomde viewport verdwijnen, waardoor ze naar een leeg of niet-gerelateerd deel van het scherm zitten te kijken.

Beschouw een concreet scenario uit de echte wereld: het online overschrijvingsformulier van een Turkse bank bevat een dropdownmenu voor het selecteren van de bestemmingsbank. De ontwikkelaar heeft een onchange-achtige gebeurtenis op het <select>-element geïmplementeerd die niet bij bevestiging, maar al wordt geactiveerd zodra een optie met de pijltjestoetsen de focus krijgt. Een schermlezersgebruiker die met Tab naar het veld gaat en op de pijl-omlaagtoets drukt om beschikbare banken te verkennen, triggert onmiddellijk een formulierverzending of een herladen van de pagina. De overschrijving wordt nooit voltooid en de gebruiker kan niet achterhalen wat er misging. Dit scenario is niet hypothetisch — het was een gedocumenteerd patroon in veel vroege single-page applications.

Naast toegankelijkheid zijn er tastbare voordelen op het gebied van bruikbaarheid en bedrijfsresultaten. Formulieren die de focus niet “kapen” hebben lagere uitvalpercentages. Pagina’s die zich voorspelbaar gedragen, scoren beter in gebruikerstests bij alle doelgroepen. Zoekmachinecrawlers profiteren ook van voorspelbare navigatiestromen, omdat onverwachte redirects die door focus-events worden getriggerd de crawllogica kunnen verwarren in bepaalde dynamische renderingscenario’s.

Gerelateerde Axe-core-regels

WCAG 3.2.1 On Focus vereist handmatige tests, omdat geautomatiseerde tools gebruikersintentie niet betrouwbaar kunnen bepalen of alle mogelijke contextwijzigingen kunnen voorspellen. Axe-core en vergelijkbare geautomatiseerde scanners kunnen statische HTML en ARIA-attributen analyseren, maar ze kunnen het runtime JavaScript-gedrag als reactie op focus-events niet observeren — met name niet of dat gedrag een “grote” contextwijziging vormt zoals gedefinieerd door WCAG. Een script dat de focus verplaatst, een formulier verzendt of naar een URL navigeert bij het focus-event is onzichtbaar voor een statische scanner, tenzij de tool daadwerkelijk focusinteracties op elk interactief element simuleert en vervolgens analyseert wat er daarna in de DOM, de viewport en de URL is veranderd. Dit niveau van gedragsimulatie is in een geautomatiseerde scan niet betrouwbaar haalbaar zonder een onaanvaardbaar hoog aantal fout-positieven.

• Handmatige test vereist — Contextwijziging bij focus: Testers moeten handmatig met Tab door elk interactief element op de pagina gaan (links, knoppen, invoervelden, selects, aangepaste widgets) en observeren of alleen focus — zonder enige activatie — een contextwijziging triggert zoals gedefinieerd door WCAG. Dit omvat het letten op URL-wijzigingen, nieuwe vensters of tabbladen die openen, focus die weggaat van het huidige element, formulierverzendingen en grote vervangingen van inhoud. Geautomatiseerde tools markeren JavaScript-eventlisteners die zijn gekoppeld aan focusgerelateerde events (focus, focusin, onfocus) als kandidaten voor handmatige beoordeling, maar kunnen niet bepalen of deze handlers een diskwalificerende contextwijziging veroorzaken.

Hoe te Testen

1. Geautomatiseerde pre-scan: Voer axe DevTools (browserextensie of CLI) of Google Lighthouse uit op de pagina. Hoewel geen van beide tools On Focus-overtredingen definitief kan markeren, kan axe DevTools gerelateerde problemen met focusbeheer aan het licht brengen (zoals scrollable-region-focusable of focus-trap-patronen) die nader handmatig onderzoek verdienen. Gebruik het paneel “Needs Review” in axe DevTools — items die daar worden gemarkeerd, hebben vaak betrekking op het gedrag van interactieve componenten dat menselijke beoordeling vereist.
2. Identificeer alle interactieve elementen: Maak vóór toetsenbordtesten een lijst van alle interactieve componenten: links, knoppen, formulierinvoervelden, dropdowns, selectievakjes, keuzerondjes, datumkiezers, carrousels, accordeons, tabs, modals en alle aangepaste widgets die tabindex gebruiken. Besteed speciale aandacht aan aangepaste JavaScript-widgets die luisteren naar focus- of focusin-events.
3. Test met uitsluitend toetsenbordnavigatie: Gebruik alleen het toetsenbord (geen muis) en druk achtereenvolgens op Tab om door elk focusbaar element op de pagina te gaan. Observeer na elke druk op Tab, voordat u iets anders indrukt: Is de URL veranderd? Is er een nieuw venster of tabblad geopend? Is de focus weggegaan van het element waar u net naartoe bent getabt? Is er een formulier verzonden? Is de primaire pagina-inhoud drastisch veranderd? Elk “ja”-antwoord is een mogelijke overtreding.
4. Test van select-elementen: Geef een <select>-dropdown de focus. Gebruik de pijl-omhoog- en pijl-omlaagtoetsen om door opties te gaan zonder op Enter of Spatie te drukken. Controleer of het navigeren door opties geen navigatie, formulierverzending of contextwijziging triggert. Dit is een van de meest voorkomende overtreden patronen.
5. NVDA + Firefox: Schakel NVDA in (gratis, Windows). Open Firefox en ga naar de pagina. Druk op Tab om door alle interactieve elementen te gaan. Luister naar de aankondigingen van NVDA — als NVDA na een druk op Tab (zonder dat u op Enter of Spatie drukt) een volledig ander deel van de pagina of een nieuwe paginacontext begint aan te kondigen, is dat een sterk signaal van een overtreding.
6. JAWS + Chrome: Schakel JAWS in. Open Chrome. Gebruik Tab om te navigeren. JAWS kondigt elk element met focus aan. Let op onverwachte aankondigingen van nieuwe dialogen, pagina’s of focuslocaties waar u niet bewust naartoe hebt genavigeerd.
7. VoiceOver + Safari (macOS/iOS): Schakel VoiceOver in (Cmd+F5 op macOS). Navigeer met Tab (of veeg op iOS). Let op onverwachte contextverschuivingen. Test op iOS ook met switch access om gebruikers met ernstige motorische beperkingen te simuleren die via scanning navigeren.
8. Inspectie van eventlisteners in Browser DevTools: Selecteer in Chrome DevTools een verdacht interactief element, ga naar het tabblad Elements en klik op “Event Listeners”. Zoek naar focus- of focusin-listeners. Controleer, als die aanwezig zijn, de gekoppelde JavaScript-code om te bepalen of de handler navigatie, formulierverzending, focusverplaatsing of andere contextveranderende acties triggert.

Hoe te Herstellen

Automatisch verzendende select-dropdown — Onjuist

<!-- FAIL: Selecting an option via arrow key immediately navigates to a new URL -->
<label for='region'>Select Region</label>
<select id='region' onchange='window.location = this.value;'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>

Automatisch verzendende select-dropdown — Juist

<!-- PASS: Navigation only occurs when the user explicitly activates the Go button -->
<label for='region'>Select Region</label>
<select id='region'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>
<button type='button' onclick='navigateToRegion()'>Go</button>

<script>
function navigateToRegion() {
  var select = document.getElementById('region');
  window.location = select.value; // Only fires on deliberate button activation
}
</script>

Modaal dat opent bij focus op invoerveld — Onjuist

<!-- FAIL: Focusing the date input immediately opens a modal dialog and moves focus -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' onfocus='openDatePickerModal()' />

<script>
function openDatePickerModal() {
  var modal = document.getElementById('date-modal');
  modal.style.display = 'block';
  modal.querySelector('button').focus(); // Moves focus away without user intent
}
</script>

Modaal dat opent bij focus op invoerveld — Juist

<!-- PASS: The date picker opens only when the user explicitly clicks or presses Enter/Space -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' readonly aria-haspopup='dialog'
       aria-label='Departure Date — press Enter to open date picker' />
<button type='button' id='open-picker'
        aria-controls='date-modal'
        onclick='openDatePickerModal()'>
  Choose Date
</button>

<script>
function openDatePickerModal() {
  // Only called on explicit activation (click or Enter/Space on the button)
  var modal = document.getElementById('date-modal');
  modal.removeAttribute('hidden');
  modal.querySelector('[data-initial-focus]').focus();
}
</script>

Carrousel die automatisch doorschuift bij focus — Onjuist

<!-- FAIL: Focusing a navigation dot advances the carousel slide, changing page content -->
<div class='carousel-dots'>
  <button class='dot' onfocus='showSlide(0)'>1</button>
  <button class='dot' onfocus='showSlide(1)'>2</button>
  <button class='dot' onfocus='showSlide(2)'>3</button>
</div>

Carrousel die alleen doorschuift bij activatie — Juist

<!-- PASS: The carousel only changes slides when the dot is explicitly activated (click/Enter) -->
<div class='carousel-dots' role='tablist' aria-label='Carousel navigation'>
  <button class='dot' role='tab' aria-selected='true'
          aria-controls='slide-0' onclick='showSlide(0)'>
    Slide 1
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-1' onclick='showSlide(1)'>
    Slide 2
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-2' onclick='showSlide(2)'>
    Slide 3
  </button>
</div>
<!-- onclick only fires on deliberate activation, not on Tab focus -->

Veelvoorkomende Fouten

• onfocus gebruiken als vervanging voor onclick op navigatie-elementen: Ontwikkelaars koppelen soms onfocus-handlers aan navigatielinks of -knoppen om een bestemming “vooraf te laden”, maar triggeren per ongeluk een volledige navigatie in plaats van alleen een prefetch. Gebruik altijd onclick of onkeydown (met controle op Enter/Spatie) voor elke actie die de context wijzigt.
• onchange binden aan <select>-elementen zonder een expliciete verzendactie: In desktopbrowsers wordt onchange op een <select> geactiveerd wanneer een optie wordt bevestigd, maar in sommige oudere implementaties en bepaalde mobiele browsers kan het al afgaan terwijl de pijltjestoetsen door opties bladeren. Combineer select-gestuurde navigatie altijd met een expliciete verzendknop of gebruik een <form> met een <button type='submit'>.
• Focus programmatisch verplaatsen binnen een focus-eventhandler: element.focus() aanroepen binnen de onfocus- of focusin-handler van een ander element veroorzaakt een onverwachte focusverspringing. Dit is een directe overtreding — de gebruiker heeft met Tab naar element A genavigeerd en de focus is stilletjes naar element B verplaatst. Verplaats focus altijd alleen als reactie op bewuste acties van de gebruiker.
• Modale dialogen openen op focus-events van een trigger-element: Een veelgebruikte snelkoppeling is een handler voor het openen van een modaal koppelen aan het focus-event van een triggerknop of invoerveld. Modals mogen alleen worden geopend als reactie op een klik, Enter-toets of Spatiebalk — nooit op focus alleen.
• Automatisch afspelen van media of animaties die de viewportcontext wijzigen bij focus: Een hero-banner die een volledig schermvullende video of een grote animatie start op het moment dat de afspeelknop de focus krijgt, wijzigt de visuele context aanzienlijk. Koppel afspeelacties aan activatie-events, niet aan focus-events.
• Live-regio-updates triggeren die de pagina naar nieuwe inhoud scrollen bij focus: Sommige dynamische widgets werken een live-regio bij en scrollen vervolgens de viewport naar die regio zodra een invoerveld de focus krijgt. Dit wijzigt de viewportcontext en desoriënteert gebruikers van schermvergroting. Ontkoppel live-regio-updates waar mogelijk van focus-events.
• Aangepaste focus-traps implementeren die gebruikers onmiddellijk vastzetten zonder uitleg: Een aangepaste component die alle Tab-toetsaanslagen onderschept zodra deze de focus krijgt, zonder de gebruiker te laten weten dat hij zich in een focus-trap bevindt, schendt zowel de letter als de geest van dit criterium. Focus-traps zijn alleen gepast binnen volledig geopende modale dialogen, en gebruikers moeten geïnformeerd worden over hoe ze kunnen ontsnappen.
• CSS :focus gebruiken om display: block te triggeren op dropdownmenu’s met focusbare kinderen, wat cascaderende onverwachte focusbeweging veroorzaakt: Alleen-met-CSS focusgestuurde menu’s die focusbare items zichtbaar maken, kunnen verwarrende sprongen veroorzaken wanneer de focusvolgorde van de browser vervolgens naar de nieuw zichtbare items gaat. Zorg ervoor dat zichtbare menu’s verwacht worden en duidelijk worden gecommuniceerd via ARIA-attributen zoals aria-expanded.
• Vertrouwen op third-party widgetbibliotheken zonder hun focusgedrag te controleren: Veel UI-componentbibliotheken (datumkiezers, rich-text-editors, select2-achtige dropdowns) hebben in het verleden 3.2.1 geschonden door pop-ups te openen of de focus te verplaatsen bij focus-events. Controleer third-party componenten altijd handmatig vóór uitrol, ongeacht de toegankelijkheidsclaims van de bibliotheek.
• Vergeten te testen in routingcontexten van single-page applications (SPA’s): In React-, Vue- en Angular-SPA’s kunnen focus-events op navigatielinks soms routewijzigingen triggeren via de routerprefetchlogica of event bubbling, vooral wanneer focus-events niet correct worden gestopt in hun propagatie. Test SPA-navigatiecomponenten expliciet op naleving van 3.2.1.

Relatie met de Turkse Toegankelijkheidsregelgeving

De Turkse Presidentiële Circulaire 2025/10, gepubliceerd in Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte eisen voor webtoegankelijkheid vast die WCAG 2.2 expliciet als technische standaard aanhalen. WCAG 3.2.1 On Focus is een criterium op Niveau A, wat betekent dat het tot de basisvereisten voor verplichte naleving onder de circulaire behoort. Er zijn geen uitzonderingen voor criteria op Niveau A — alle betrokken entiteiten moeten hieraan voldoen binnen de vastgestelde termijnen.

Overheidsinstellingen moeten binnen één jaar na de publicatiedatum van de circulaire volledige conformiteit bereiken. Partijen in de private sector die onder de reikwijdte vallen, krijgen twee jaar. De entiteiten die onder Presidentiële Circulaire 2025/10 vallen, omvatten een brede reeks organisaties: alle overheidsinstellingen en -agentschappen, e-commerceplatforms en online marktplaatsen, banken en financiële instellingen, ziekenhuizen en particuliere zorgaanbieders, telecombedrijven met 200,000 of meer abonnees, reisbureaus en boekingsplatforms, particuliere vervoersbedrijven en particuliere scholen en onderwijsinstellingen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE).

De relevantie van WCAG 3.2.1 On Focus voor deze typen entiteiten is direct en praktisch. Denk aan een e-commerceplatform waar een productcategoriedropdown automatisch navigeert bij focus — een klant met een mobiliteitsbeperking die het toetsenbord gebruikt, kan productcategorieën niet doorbladeren en zal de aankoop afbreken. Een online overschrijvingsformulier van een bank met focusgestuurde verzendingen kan onbedoelde financiële transacties veroorzaken of herhaalde mislukte pogingen voor schermlezersgebruikers. Een systeem voor het boeken van ziekenhuisafspraken waarbij datumvelden modals openen bij focus, kan voorkomen dat patiënten met een beperking zelfstandig zorgafspraken plannen.

Niet-naleving stelt betrokken entiteiten onder de circulaire bloot aan administratieve sancties en reputatierisico. Voor organisaties die momenteel een digitale transformatie ondergaan of nieuwe websystemen aanschaffen, is het nu inbouwen van naleving van WCAG 3.2.1 in aanbestedingsvereisten en ontwikkelaarsrichtlijnen — in plaats van achteraf aanpassingen te doen na een klacht — zowel kostenefficiënter als beter in lijn met de geest van de regelgeving. Organisaties die de Accsible overlay SDK gebruiken, profiteren van ingebouwde tools voor focusbeheer die helpen onverwacht gedrag bij focus te identificeren en te verhelpen als onderdeel van een bredere workflow voor naleving van WCAG 2.2 Niveau A.