WCAG 2.4.7: Focus zichtbaar

Wat Deze Regel Betekent

WCAG 2.4.7 Focus Visible vereist dat elk interactief element op een webpagina — links, knoppen, formulierinvoervelden, aangepaste widgets en elk ander via het toetsenbord bedienbaar onderdeel — een zichtbare focusindicator toont wanneer het toetsenbordfocus ontvangt. Simpel gezegd: wanneer een gebruiker op de Tab-toets drukt om door een pagina te gaan, moet die precies kunnen zien welk element op dat moment actief is.

Het criterium schrijft geen specifieke visuele stijl voor de focusindicator voor. Het vereist alleen dat er enige zichtbare verandering optreedt. Dat gezegd hebbende: een nauwelijks waarneembare indicator — bijvoorbeeld een stippellijn van één pixel die wegvalt tegen de achtergrond — kan technisch gezien voldoen aan 2.4.7, maar toch niet slagen voor de strengere WCAG 2.4.11 (Focus Appearance) die in WCAG 2.2 is geïntroduceerd. Onder alleen 2.4.7 is elke waarneembare visuele verandering voldoende.

Wat telt als een voldoende resultaat: Een focusindicator voldoet als een ziende gebruiker die met Tab door de pagina navigeert, kan vaststellen welk element focus heeft zonder te vertrouwen op schermlezer-aankondigingen of andere niet-visuele signalen. Veelvoorkomende acceptabele implementaties zijn de standaardomlijningen van de browser, aangepaste CSS-regels met outline of box-shadow, veranderingen in onderstreping of achtergrondkleur die worden toegepast op :focus of :focus-visible.

Wat telt als een onvoldoende resultaat: Er is sprake van een fout wanneer een ontwikkelaar de standaard focusring van de browser verwijdert — meestal via outline: none of outline: 0 in CSS — en deze niet vervangt door een gelijkwaardige aangepaste indicator. Fouten treden ook op wanneer een aangepast component (gebouwd met <div>- of <span>-elementen) via tabindex toetsenbord-focusbaar wordt gemaakt, maar geen zichtbare stijlverandering krijgt bij focus.

Officiële uitzonderingen: WCAG merkt op dat het criterium alleen van toepassing is op via het toetsenbord bedienbare interfaces. Componenten die puur decoratief zijn of expliciet uit de tabvolgorde zijn gehaald (via tabindex='-1') hoeven geen focusindicator te tonen, omdat ze geen focus kunnen krijgen via normale toetsenbordnavigatie.

Waarom Het Belangrijk Is

Focuszichtbaarheid is fundamenteel voor toetsenbordtoegankelijkheid, en toetsenbordtoegankelijkheid is de toegangspoort voor een brede groep mensen met een beperking. Ongeveer 26% van de volwassenen in de Verenigde Staten leeft met een of andere vorm van beperking volgens de CDC, en veel van deze personen vertrouwen op toetsenborden of toetsenbord-emulerende ondersteunende technologieën in plaats van aanwijsapparaten.

Gebruikers met motorische beperkingen — waaronder mensen met aandoeningen zoals ALS, cerebrale parese, RSI of de ziekte van Parkinson — vertrouwen vaak op toetsenborden, schakelapparaten, sip-and-puff-controllers of oogvolgsoftware. Al deze invoermethoden zijn afhankelijk van het focusmodel van de browser voor het toetsenbord. Als de focusindicator onzichtbaar is, kunnen deze gebruikers niet bepalen waar ze zich op de pagina bevinden, kunnen ze het juiste besturingselement niet activeren en kunnen ze volledig buitengesloten raken van kritieke taken zoals het verzenden van een formulier, het afronden van een aankoop of het navigeren door een menu.

Gebruikers met een beperkt gezichtsvermogen die geen schermlezer gebruiken maar het scherm mogelijk vergroten, zijn eveneens afhankelijk van zichtbare focus. Wanneer zij inzoomen op een deel van de pagina, vertelt de zichtbare focusring hen welk element actief is en stuurt hun interactie.

Mensen met cognitieve en aandachtsgerelateerde beperkingen profiteren ook van duidelijke focusindicatoren. Gebruikers met ADHD of geheugenproblemen raken vaak de draad kwijt op een complexe pagina; een prominente focusindicator biedt een betrouwbaar visueel anker.

Een concreet scenario uit de praktijk: stel een gebruiker met multiple sclerose die een e-commercesite uitsluitend met een toetsenbord bezoekt omdat muisprecisie moeilijk is geworden. Diegene tabt door de productpagina om de knop "Add to Cart" te bereiken. Als de ontwikkelaar de focusring heeft onderdrukt, ziet de gebruiker geen enkele aanwijzing waar de focus zich bevindt. Ze drukken op Enter en er gebeurt niets (de focus is op een niet-interactief element terechtgekomen) of de verkeerde actie wordt uitgevoerd. Het resultaat is frustratie, het afbreken van de taak en omzetverlies voor het bedrijf — allemaal te voorkomen met één enkele CSS-regel.

Los van beperkingen leveren focusindicatoren voordelen op voor alle gebruikers in situaties waarin muisgebruik onhandig is: power users die met sneltoetsen navigeren, laptopgebruikers zonder externe muis en gebruikers die lange formulieren invullen. Zichtbare focus verbetert indirect ook SEO door semantische HTML en een correcte tabvolgorde te stimuleren, waar zoekmachinecrawlers beide waarde aan hechten.

Gerelateerde Axe-core Regels

WCAG 2.4.7 vereist handmatige tests omdat geautomatiseerde tools niet betrouwbaar kunnen bepalen of een focusindicator zichtbaar is. Axe-core en vergelijkbare engines kunnen detecteren dat er een CSS-regel zoals outline: none bestaat, maar ze kunnen het gerenderde visuele resultaat niet beoordelen in alle thema’s, hoogcontrastmodi en browserrendering-engines. Het volgende licht het testlandschap toe:

• Handmatige test vereist — onderdrukking van focus-visible: Axe-core levert geen speciale regel die 2.4.7-fouten definitief markeert, omdat dit zou vereisen dat de pagina wordt gerenderd, door elk element wordt getabt en er pixelniveau-contrastanalyses op de focusindicator worden uitgevoerd — een taak die verder gaat dan statische of DOM-niveau-analyse. In plaats daarvan moeten testers handmatig met Tab door de pagina gaan en visueel bevestigen dat elk interactief element een focusverandering toont.
• Gedeeltelijk signaal van css-orientation-lock en stijlcontroles: Sommige axe-core-configuraties markeren de aanwezigheid van outline: 0 of outline: none in stylesheets als een best-practice-waarschuwing, maar dit is een heuristiek, geen definitieve overtredingscontrole, omdat de regel elders in de cascade kan worden overschreven door een geldige aangepaste focusstijl.
• Waarom automatisering tekortschiet: Een focusindicator kan alleen in bepaalde toestanden verborgen zijn (bijv. wanneer een modal is geopend), alleen voor bepaalde elementtypen of alleen in bepaalde kleurthema’s. Deze voorwaardelijke fouten vereisen dat een menselijke tester elk interactief element in de daadwerkelijk gerenderde omgeving doorloopt en de zichtbaarheid bevestigt. Tools zoals axe DevTools Pro kunnen helpen door elementen te markeren waarop outline: none is toegepast, maar de uiteindelijke beoordeling voldoende/onvoldoende moet door een mens worden gedaan.

Hoe te Testen

1. Geautomatiseerde pre-scan: Voer axe DevTools (browserextensie of CLI) of Google Lighthouse uit op de pagina. Zoek naar best-practice- of experimentele waarschuwingen met betrekking tot focusstijlen. Hoewel deze niet definitief bevestigen dat er sprake is van een 2.4.7-fout, brengen ze elementen aan het licht die nader onderzoek verdienen. Controleer in Lighthouse de categorie "Accessibility" op focusgerelateerde bevindingen. Exporteer het rapport en noteer alle gemarkeerde interactieve elementen.
2. Handmatige toetsenbord-tabtest: Koppel uw muis los of leg deze weg. Druk herhaaldelijk op Tab vanaf de bovenkant van de pagina en navigeer door elk interactief element — links, knoppen, invoervelden, dropdowns, modals, tabs, accordeons en datumkiezers. Bevestig bij elke stop dat het element met focus visueel te onderscheiden is van de niet-gefocuste buren. Noteer elk element waarbij het verkrijgen van focus geen zichtbare verandering oplevert.
3. Omgekeerde tabtest: Gebruik Shift+Tab om achterwaarts door de pagina te navigeren en herhaal de visuele controle. Sommige implementaties verbreken de focuszichtbaarheid slechts in één richting door problemen met CSS-specificiteit.
4. NVDA + Firefox-test: Open Firefox met NVDA actief. Gebruik Browse Mode (pijltjestoetsen) en schakel vervolgens over naar Forms Mode (Enter) om met formulierbesturingselementen te werken. Bevestig dat elk element dat NVDA als gefocust aankondigt ook een zichtbare indicator op het scherm toont — nuttig om discrepanties tussen AT-focus en browserfocus op te sporen.
5. VoiceOver + Safari-test (macOS/iOS): Schakel VoiceOver in en gebruik Tab of VO+Pijl-rechts om door interactieve elementen te gaan. Controleer visueel of de focusring op het scherm overeenkomt met wat VoiceOver aankondigt.
6. JAWS + Chrome-test: Gebruik JAWS in virtual cursor mode en vervolgens in application mode. Tab door interactieve besturingselementen en bevestig dat de zichtbare focusindicator verschijnt op elk element met focus.
7. Hoogcontrastmodustest: Schakel Windows High Contrast Mode (of macOS Increase Contrast) in en herhaal de Tabtest. Sommige focusindicatoren zijn afhankelijk van kleuren die verdwijnen in hoogcontrastthema’s; de indicator moet in deze modi zichtbaar blijven.
8. CSS-inspectie: Open de DevTools van de browser, selecteer een interactief element, geef het focus door op Tab te drukken totdat het actief is, en inspecteer de berekende stijlen. Controleer of geen enkele regel outline: none of outline: 0 instelt zonder een compenserende focusstijl. Controleer ook op :focus-visible versus :focus om zeker te zijn dat toetsenbord-geactiveerde focus wordt afgedekt.

Hoe te Herstellen

Globale onderdrukking van outline zonder vervanging — Onjuist

<!-- CSS-resets die alle focusindicatoren globaal verwijderen -->
<style>
  * {
    outline: none; /* Verwijdert de focusring van elk element */
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>

Globale onderdrukking van outline zonder vervanging — Juist

<!-- Verwijder de globale outline: none-reset.
     Voorzie in een aangepaste focusstijl die visueel duidelijk is. -->
<style>
  /* Respecteer gebruikers die minder beweging prefereren */
  :focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>
<!-- Nu tonen beide elementen een contrastrijke blauwe omlijning wanneer ze via het toetsenbord focus krijgen -->

Aangepaste op div gebaseerde knop zonder focusstijl — Onjuist

<!-- Een div die als knop is gestyled, focusbaar gemaakt, maar zonder :focus CSS -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  /* Geen :focus- of :focus-visible-regel gedefinieerd */
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>

Aangepaste op div gebaseerde knop zonder focusstijl — Juist

<!-- Voeg :focus-visible toe aan het aangepaste component zodat
     toetsenbordgebruikers een duidelijke indicator zien wanneer dit element focus heeft -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  .fake-btn:focus-visible {
    outline: 3px solid #ffcc00;
    outline-offset: 3px;
  }
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>
<!-- De gele omlijning verschijnt alleen bij toetsenbordfocus, niet bij muisklik -->

Focusring verborgen in een modal overlay — Onjuist

<!-- Modal past overflow:hidden en een stacking context toe die
     de standaardomlijning afknipt, waardoor deze onzichtbaar wordt -->
<style>
  .modal-body {
    overflow: hidden; /* Knipt omlijningen af die buiten het element uitsteken */
    border-radius: 8px;
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Focusring verborgen in een modal overlay — Juist

<!-- Gebruik box-shadow in plaats van outline zodat deze
     binnen de stacking context wordt gerenderd en nooit wordt afgeknipt -->
<style>
  .modal-body {
    overflow: hidden;
    border-radius: 8px;
  }
  .modal-body button:focus-visible {
    /* box-shadow wordt niet afgeknipt door overflow:hidden --
       het blijft binnen de eigen box van het element -->
    box-shadow: 0 0 0 3px #005fcc;
    outline: none; /* Verwijder standaard om dubbele ring te voorkomen */
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Veelvoorkomende Fouten

• outline: none toevoegen aan een basis-CSS-reset zonder te controleren welke elementen dit beïnvloedt. Veel populaire resets (bijv. oudere versies van normalize.css of Bootstrap-utilities) onderdrukken focusringen globaal. Volg dit altijd op met een expliciete :focus-visible-regel die de zichtbaarheid voor toetsenbordgebruikers herstelt.
• Uitsluitend vertrouwen op :focus wanneer :focus-visible passender is — of andersom. Alleen :focus gebruiken zorgt ervoor dat de indicator ook bij muisklikken verschijnt, wat er vreemd uit kan zien. Alleen :focus-visible gebruiken zonder een :focus-fallback kan ertoe leiden dat oudere browsers helemaal geen indicator tonen. Test in alle doelbrowsers.
• outline: none toepassen binnen een thema-override van een componentenbibliotheek zonder de cascade te begrijpen. Eén enkele override in een themabestand kan ongemerkt focusindicatoren verwijderen voor elk component dat hiervan erft, inclusief widgets van derden.
• Een focuskleur gebruiken met onvoldoende contrast ten opzichte van het element of de paginabackground. Een lichtgrijze omlijning op een witte achtergrond voegt technisch gezien een omlijning toe, maar kan onwaarneembaar zijn. Hoewel 2.4.7 geen specifieke contrastverhouding voorschrijft, doet 2.4.11 dat wel — en focusindicatoren met weinig contrast zijn een veelvoorkomende bron van auditfouten, zelfs wanneer ontwikkelaars denken dat ze hebben voldaan.
• overflow: hidden of clip-path instellen op een container, waardoor de standaardomlijning van de browser wordt afgeknipt. De oplossing is om over te stappen op op box-shadow gebaseerde focusindicatoren, die binnen de eigen box van het element worden gerenderd en niet worden afgeknipt door overflow-regels van de ouder.
• Focusindicatoren vergeten op interactieve elementen binnen SVG- of Canvas-componenten. Aangepaste grafiek-tooltips, op SVG gebaseerde pictogramknoppen en canvas-gebaseerde tekentools hebben vaak geen native focusstyling. Deze vereisen expliciete ARIA-rollen, tabindex en :focus-visible CSS of door JavaScript aangestuurde visuele feedback.
• Focuszichtbaarheid alleen verwijderen in productie-CSS (bijv. via een post-processor of build-stap) terwijl deze in de ontwikkelomgeving zichtbaar blijft. Dit zorgt ervoor dat het ontwikkelingsteam lokale QA doorstaat terwijl er gebrekkige toegankelijkheid naar eindgebruikers wordt uitgerold.
• Een focusindicator alleen toepassen op het <a>-element maar niet op role='link'-span-elementen die worden gebruikt voor SPA-navigatielinks. Elk via het toetsenbord focusbaar element — ongeacht het native tagtype — heeft een zichtbare focusstatus nodig.
• Focusringen alleen verbergen bij bepaalde viewportbreedtes via media queries, in de veronderstelling dat mobiele gebruikers altijd het scherm aanraken. Tabletgebruikers met Bluetooth-toetsenborden en gebruikers in liggende stand die afhankelijk zijn van toetsenbordinvoer blijven zo zonder enige focusindicator.
• JavaScript gebruiken om direct na programmatische focus .blur() aan te roepen om te voorkomen dat de focusring verschijnt. Dit is een kritieke fout die de focuszichtbaarheid volledig wegneemt en nooit als ontwerpsnelkoppeling mag worden gebruikt.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt bindende toegankelijkheidseisen voor web en mobiel vast voor een brede groep entiteiten die in Turkije actief zijn. De circulaire verplicht tot conformiteit met WCAG 2.2 op niveau AA voor de betrokken organisaties, waardoor WCAG 2.4.7 Focus Visible een direct afdwingbare eis wordt in plaats van slechts een best-practice-aanbeveling.

De entiteiten die onder de circulaire vallen, omvatten overheidsinstellingen en -agentschappen, e-commerceplatforms, banken en aanbieders van financiële diensten, ziekenhuizen en zorgorganisaties, telecombedrijven met 200,000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministry of National Education (MoNE). Voor al deze organisaties is het niet bieden van zichtbare focusindicatoren op hun digitale interfaces een kwestie van niet-naleving van regelgeving, niet slechts een tekortkoming in bruikbaarheid.

Het Erişilebilirlik Logosu (Toegankelijkheidslogo), uitgegeven door het Ministry of Family and Social Services, fungeert als het officiële certificeringsmerk dat betrokken entiteiten kunnen tonen om conformiteit aan te geven. Het verkrijgen van het Toegankelijkheidslogo vereist het slagen voor een formele audit op WCAG 2.2 niveau AA. WCAG 2.4.7 is een van de AA-criteria die auditors zullen beoordelen, doorgaans via handmatige toetsenbordtests zoals beschreven in de testsectie hierboven. Een organisatie waarvan de site focusringen onderdrukt of geen zichtbare focus op aangepaste componenten implementeert, zal de audit die voor het logo vereist is niet doorstaan.

Voor Turkse e-commerceplatforms in het bijzonder heeft focuszichtbaarheid directe commerciële implicaties: toegankelijke sites bereiken een grotere gebruikersgroep, waaronder klanten met motorische beperkingen die uitsluitend via toetsenbord of schakeltoegang winkelen, en naleving van Presidential Circular 2025/10 beschermt organisaties tegen bestuurlijke maatregelen. Het vanaf het begin inbouwen van focus-visible-patronen in de componentenbibliotheek — in plaats van achteraf aan te passen na een audit — is de meest kosteneffectieve manier om het Erişilebilirlik Logosu te behouden en te voldoen aan de toegankelijkheidsverplichtingen van Turkije.