Focus verdwijnt achter je cookiebanner

De focus is het element dat op dat moment toetsenbordinvoer ontvangt. Met Tab verplaats je die door de interactieve elementen. Bij een cookiebanner zie je vaak drie fouten:

• Focus achter de banner: de banner bedekt een deel van de pagina, en de focus springt naar een link of knop die eronder zit en dus onzichtbaar is.
• Focus buiten de banner terwijl die open staat: de bezoeker kan met Tab de pagina doorlopen zonder ooit bij de banneractie te komen.
• Geen zichtbare indicator: de focus zit ergens, maar je ziet geen omlijning, waardoor je het spoor bijster raakt.

De toegankelijkheidstutorials van W3C leggen uit hoe je toegankelijke webinhoud maakt en verwijzen naar WCAG-succescriteria. Ze behandelen cookiebanners of toetsenbordfocus bij banners niet specifiek. Dit artikel is een eigen praktische controle voor één onderdeel dat veel sites hebben; ze bewijst geen WCAG-conformiteit.

Je hebt geen speciale tool nodig. Leg je muis opzij en volg deze volgorde in een gewone browser, in een schoon venster zodat de banner opnieuw verschijnt (bijvoorbeeld een privévenster; het exacte gedrag hangt af van je cookiebeheerder).

1. Laad de pagina en druk een keer op Tab. Noteer waar de focus eerst landt.
2. Blijf Tab indrukken en tel hoeveel stappen het duurt tot je een banneractie bereikt (accepteren, weigeren, instellingen).
3. Controleer bij elke stap of je de focus ziet.
4. Druk Shift plus Tab om terug te gaan. Verwacht: dezelfde volgorde in omgekeerde richting.
5. Bedien de banner met Enter of spatie. Verwacht: de banner sluit en de focus gaat naar een logisch punt, niet naar het begin van een onzichtbaar deel.
6. Herhaal het op een smal scherm of bij sterke inzoom, want daar bedekt een banner vaak meer.

Noteer per stap wat je zag. Wat een toetsenbordtest niet bewijst: dat het ook werkt met schermlezers of spraakbediening. Dat zijn aparte controles.

Gebruik deze matrix als werkvoorstel om het probleem te benoemen en door te geven aan wie je site beheert. Exacte instellingen in je cookietool verschillen per aanbieder; controleer die in de documentatie of bij de beheerder.

Vul elke rij met wat jij ziet. Meerdere rijen kunnen tegelijk gelden.

Een banner die laat of via zwaar JavaScript wordt ingeladen, kan ook de volgorde van de pagina beïnvloeden. De cursus Performance van web.dev behandelt onder meer het kritieke pad en resourcebelading, dus hoe en wanneer onderdelen van een pagina verschijnen. De cursus gaat niet over focus of toegankelijkheid. Het is een eigen aanname dat een banner die later wordt ingeladen, op een onbedoelde plek in de focusvolgorde kan belanden; controleer dat met de test hieronder.

Let daarom op het moment van verschijnen. Wordt de banner pas ingevoegd nadat de bezoeker al enkele keren op Tab drukte, dan staat de focus mogelijk al op een element verder op de pagina. Test dus ook met een trage verbinding (je browser kan dit nabootsen; waar je die instelling vindt, controleer je in de browserdocumentatie) en kijk of de banner en de focus nog kloppen.

Daarmee beweer ik niet dat snelheid zelf toegankelijkheid oplost. Het is een extra reden om de volgorde en timing van de banner te testen onder realistische omstandigheden.

Als je zelf niet aan de code werkt, geef dan concrete verzoeken door in plaats van enkel 'het werkt niet'. Een bruikbaar overdrachtsvoorbeeld:

• Beschrijf de test: 'Zonder muis, privévenster, na 6 keer Tab is de focus niet meer zichtbaar.'
• Vraag om een zichtbare focusindicator op alle banneracties.
• Vraag dat de banner, zolang hij open staat, vroeg in de tabvolgorde komt of de focus bij openen krijgt.
• Vraag dat de focus na sluiten naar een logisch punt gaat.
• Vraag een test op smalle schermen en bij inzoom.

Laat de beheerder of leverancier van je cookietool bevestigen welke van deze punten via instellingen kunnen en welke maatwerk vragen. Ik verzin geen menunamen of functies die je tool zou hebben; dat verschilt per product.

Behandel de banner als onderdeel van de pagina en niet als los blok dat 'er maar boven hangt'. Dan neem je toegankelijkheid mee bij elke wijziging aan de site.

Een fictief scenario met enkel invoer en verwachte controles; er zijn geen resultaten of cijfers bedacht. Een kmo heeft een banner onderaan het scherm die op mobiel een groot deel van de pagina bedekt.

Invoer: je opent de site in een privévenster op een smal scherm en gebruikt enkel het toetsenbord.

1. Eerste Tab. Verwacht: de focus landt zichtbaar op een element in of vlak bij de banner.
2. Tab tot aan 'weigeren'. Verwacht: je bereikt de actie binnen een redelijk aantal stappen en de omlijning blijft zichtbaar.
3. Enter op 'weigeren'. Verwacht: banner sluit; focus staat op een zichtbaar element.
4. Tab verder. Verwacht: je doorloopt de pagina in leesvolgorde, zonder te springen naar iets onzichtbaars.
5. Herhaal met 'instellingen'. Verwacht: een openend venster neemt de focus mee en geeft die terug bij sluiten.

Als één stap mislukt, noteer die stap en geef hem door. Wil je daarnaast zien welke zichtbare signalen je website publiek geeft, dan kan je die bekijken via Marketing Scan. Een publieke scan meet zichtbare signalen en kan geen toetsenbordgedrag of volledige toegankelijkheid bewijzen; daarvoor blijft handmatig testen nodig.