Een toegankelijk hamburgermenu

De hamburger is niet alleen iconisch als gerecht. Ook in de digitale wereld is het ‘hamburgermenu’ een bekende term, namelijk voor het responsieve navigatiemenu dat te herkennen is aan drie horizontale streepjes.

Het hamburgermenu kom je op websites voornamelijk tegen bij een mobiele weergave, en heel soms ook al in de standaardweergave. Ook binnen een WCAG-onderzoek kom ik een hamburgermenu regelmatig tegen, vaak op het moment dat de pagina’s herschaald worden (succescriteria 1.4.4 en 1.4.10) om een meer ingezoomde versie van de pagina te kunnen bekijken.

Er zijn dan vaak verschillende dingen die mis gaan rondom de toegankelijkheid van dit menu, waardoor niet iedereen het menu kan waarnemen, begrijpen of gebruiken. In dit artikel ga ik in op de meest voorkomende toegankelijkheidsproblemen bij een hamburgermenu, en hoe deze op te lossen.

Veelvoorkomende problemen bij een hamburgermenu

In dit artikel bespreek ik de volgende veelvoorkomende toegankelijkheidsproblemen bij een hamburgermenu:

  • Het doel van de knop om het menu te openen is onduidelijk

  • De status van die knop (geopend of gesloten) kan niet worden bepaald

  • De toetsenbordbediening werkt niet zoals het hoort

  • De gebruikte kleuren zijn niet goed waarneembaar

Lees snel verder!

Doel van de knop is onduidelijk

Het mobiele menu wordt vaak achter een knop geplaatst met daarop het icoon van drie horizontale strepen. Visueel begrijpen mensen daarmee al snel dat hiermee een navigatiemenu geopend kan worden. Alleen is het ook belangrijk om rekening te houden met mensen die door de website navigeren terwijl zij de pagina’s niet zien. Ook voor hen moet het doel van de knop duidelijk zijn.

Ik kijk in dat geval naar de toegankelijkheidsnaam van de knop. Het is belangrijk dat hierin wordt beschreven dat het gaat om een menu.

Knop naar het menu op de website van Cardan, met bijbehorende code. De toegankelijkheidsnaam van de knop is "Menu".

Zie ik hier in een onderzoek geen goede toegankelijkheidsnaam, dan kan dat de volgende afkeuringen opleveren:

  • Succescriterium 1.1.1: er is geen goed tekstalternatief voor het icoon beschikbaar, waardoor de informatie niet voor iedereen waarneembaar is.

  • Succescriterium 2.4.6: er is geen goed label voor de knop, waardoor het doel van de knop niet voor iedereen te begrijpen is.

  • Succescriterium 4.1.2: als de toegankelijkheidsnaam leeg is, wordt dit ook hier afgekeurd omdat voor dit interactieve element geen naam bepaald kan worden.

Voorbeeld van een knop naar een menu, met bijbehorende code waaruit blijkt dat de knop geen toegankelijkheidsnaam heeft.

De oplossing is afhankelijk van hoe de knop precies is geprogrammeerd, maar kan bijvoorbeeld bestaan uit het geven van een beschrijvend tekstalternatief via het alt-attribuut op een img-element, de title- en desc-elementen op een svg-element, het toevoegen van content aan pseudo-elementen of het gebruiken van een aria-label op de knop.

Let er daarbij ook op dat je bij het geven van een naam aan de knoppen dezelfde taal als de pagina gebruikt. Dit zie ik nog wel eens misgaan bij standaardknoppen zoals een knop om het menu te sluiten. Deze krijgt dan bijvoorbeeld de naam “Close menu”, terwijl het een Nederlandse website is. Een label als “Menu sluiten” is dan beter.

Status van de knop kan niet worden bepaald

Om hierop verder te bouwen, is het ook van belang om te kunnen bepalen of het menu is geopend of niet. Visueel zie je dat meteen, maar ook als je de pagina niet ziet is het goed om dit te weten te krijgen zodat je begrijpt wat er gebeurt of waar je bent. In WCAG-termen zeggen we ook wel dat de status van de knop bepaald moet kunnen worden. Ook dit kun je aflezen uit de code. Bijvoorbeeld met het gebruik van een aria-expanded attribuut, of vanuit de naamgeving van de knop (zoals “menu openen” versus “menu sluiten”).

Knop naar het navigatiemenu, met bijbehorende code. Het menu is gesloten. De knop heeft de toegankelijkheidsnaam "Hoofdnavigatiemenu openen" en het aria-expanded attribuut heeft de waarde "false".
Knop bij ditzelfde navigatiemenu, met bijbehorende code. Het menu is geopend. De knop heeft de toegankelijkheidsnaam "Hoofdnavigatiemenu sluiten" en het aria-expanded attribuut heeft de waarde "true".

Wat ik in onderzoeken vaak mis zie gaan, is dat er geen enkele manier is om die status te bepalen. Dus bijvoorbeeld het aria-expanded attribuut ontbreekt en dit wordt ook niet duidelijk uit de naam van de knop. En het gebeurt ook nog wel eens dat er wel een aria-expanded attribuut aanwezig is, maar dat deze altijd de waarde “false” houdt (wat aangeeft dat het menu gesloten is), terwijl dit zou moeten veranderen naar “true” op het moment dat het menu wordt geopend.

Is de status niet goed aangegeven, dan wordt dit afgekeurd bij:

  • Succescriterium 4.1.2: de status kan niet (goed) worden bepaald.

  • Succescriterium 1.3.1: de informatie zoals deze visueel beschikbaar is, is niet op diezelfde manier beschikbaar voor hulpsoftware.

Bediening werkt niet zoals het hoort

In WCAG-onderzoeken merk ik bij de hamburgermenu’s toch wel vaak dat deze menu’s niet met toegankelijkheid in het achterhoofd zijn gemaakt. De hamburgermenu’s komen vaak voort uit een mobiele weergave en worden ook op die manier getest. Alles werkt als je erop klikt met je vingers (of dus nu met de muis), maar op het moment dat je afhankelijk bent van toetsenbordbediening kom je al snel in de problemen.

Het grootste probleem: de knop om het hamburgermenu te openen kan niet met toetsenbordbediening worden geopend. Als je afhankelijk bent van de toetsenbordbediening, betekent dit dus dat je geen toegang hebt tot de informatie uit het navigatiemenu. Dit wordt afgekeurd bij succescriterium 2.1.1 en komt ofwel omdat de knop helemaal geen toetsenbordfocus kan ontvangen, ofwel omdat de knop vervolgens niet “reageert” op de toetsenbordbediening (maar bijvoorbeeld alleen op een mouse-event).

Ook als het hamburgermenu in theorie wél met het toetsenbord bediend kan worden, levert de toetsenbordbediening vaak nog problemen op. Denk hierbij aan:

  • Succescriterium 2.4.3: de focusvolgorde is niet juist. Bijvoorbeeld:

    • Als het menu niet is geopend, komt de toetsenbordfocus tóch op de interactieve elementen in het menu, terwijl die op dat moment niet zichtbaar zijn en dus geen focus zouden moeten ontvangen.

    • Of het hamburgermenu werkt wel goed, maar er zijn ook nog onzichtbare links uit het navigatiemenu van de standaardweergave die focus krijgen, terwijl deze links op dat moment helemaal niet op de pagina beschikbaar zijn.

    • Het openen en sluiten van het menu brengt de focus niet naar een logische plek. Zo gaat de focus na het openen van het menu soms eerst verder op de achterliggende pagina, in plaats van direct naar de inhoud van het menu.

  • Als de toetsenbordfocus op interactieve elementen komt die niet zichtbaar zijn, bijvoorbeeld omdat ze achter het geopende hamburgermenu staan, kan dit ook problemen opleveren bij succescriteria 2.4.7 en 2.4.11. Het is niet duidelijk waar de toetsenbordfocus is gebleven, wat verwarrend kan zijn voor gebruikers.

Een goede oplossing voor een deel van deze problemen is bijvoorbeeld om te zorgen dat de toetsenbordfocus vastgehouden wordt binnen het hamburgermenu zolang deze is geopend. Als het hamburgermenu wordt geopend, gaat de toetsenbordfocus direct naar dit menu. Pas als het menu wordt gesloten (bijvoorbeeld via een sluitknop of via de Esc-toets), gaat de toetsenbordfocus weer verder op de achterliggende pagina. Het sluiten van het hamburgermenu brengt de focus terug op een logische plek op de achterliggende pagina, namelijk de knop waarmee het menu ook geopend kan worden.

Gebruikte kleuren zijn niet goed waarneembaar

Tot slot ook nog wat aandachtspunten rondom de visuele weergave. Ook in het navigatiemenu is het van belang dat alle informatie goed waarneembaar is. Let daarbij op het gebruik van kleuren:

  • Succescriterium 1.4.3: zorg dat alle teksten in het menu voldoende contrast hebben (minimaal 3,0:1 voor grote tekst en minimaal 4,5:1 voor normale tekst). Dit geldt ook bij hover of toetsenbordfocus.

  • Succescriterium 1.4.11: zorg dat alle informatieve niet-tekstuele content, zoals het icoon van de drie horizontale strepen of het icoon van een kruis, voldoende contrast hebben met de achtergrond (minimaal 3,0:1). Dit geldt ook bij hover of toetsenbordfocus.

Icoon dat het hamburgermenu aangeeft heeft een lichtgrijze kleur (`rgb(153, 153, 153)`) op een lichtblauwe achtergrond (`rgb(234, 242, 246)`), met een te laag contrast van 2,5:1.
  • Succescriterium 1.4.1: zorg dat de toetsenbordfocus niet alleen door middel van kleur wordt aangegeven (bijvoorbeeld dat het icoon een andere kleur krijgt of dat in het uitgeklapte menu de link met focus alleen een andere achtergrondkleur krijgt). Zorg bijvoorbeeld voor een duidelijke rand om het item dat focus krijgt (met voldoende contrast).

Samen een hamburger bouwen?

Hamburgers komen in veel smaken en sauzen, en dat geldt ook voor hamburgermenu’s op websites. Er is dus niet één gouden implementatie, maar met de tips uit dit artikel weet je in ieder geval wat enkele belangrijke aandachtspunten zijn om een toegankelijk hamburgermenu te bieden. Twijfel je of jouw hamburgermenu toegankelijk is en kom je er zelf niet helemaal uit, aarzel dan niet om om hulp te vragen. Ik help je graag!

Gerelateerde artikelen