Een toegankelijk menu dat werkt met toetsenbord en screenreader

“Ons menu werkt toch gewoon?” Dat klopt meestal, zolang u met de muis over de items beweegt. Probeer het eens met alleen de Tab-toets. Bij veel websites gebeurt dan een van twee dingen. Of de submenu’s blijven dicht en de pagina’s daarin zijn onbereikbaar. Of elk submenu klapt open zodra de focus erlangs komt, zodat u door zestig links moet tabben voordat u bij de inhoud bent. Een toegankelijk menu zit daar tussenin: het opent wat u wilt openen en laat de rest met rust.

Waar het misgaat: submenu’s op hover

Het klassieke WordPress-menu toont een submenu als de muis over het hoofditem beweegt. Dat gebeurt met CSS (:hover) of met een stukje script. Voor toetsenbordgebruikers bestaat “erover bewegen” niet. Sommige thema’s vangen dat op met :focus-within, waardoor het submenu opent zodra een link erin focus krijgt. Dat werkt, maar leidt tot het tweede probleem: alles klapt open en dicht terwijl iemand alleen naar de volgende hoofdpagina wil.

Ook muisgebruikers hebben last van hover-menu’s. Iemand met een trillende hand schiet net buiten het submenu en het verdwijnt. Daarom is een kleine vertraging bij het sluiten, of een menu dat opent op klik, voor veel mensen prettiger.

Het patroon dat wel werkt: een knop per submenu

De betrouwbaarste oplossing is eenvoudig. Het hoofditem blijft een gewone link naar zijn eigen pagina. Daarnaast staat een aparte knop die het submenu opent en sluit. Die knop vertelt met aria-expanded of het submenu open is.

<nav aria-label="Hoofdmenu">
  <ul>
    <li>
      <a href="/diensten/">Diensten</a>
      <button type="button" aria-expanded="false"
              aria-controls="sub-diensten">
        <span class="sr-only">Submenu Diensten</span>
      </button>
      <ul id="sub-diensten" hidden>
        <li><a href="/diensten/onderhoud/">Onderhoud</a></li>
        <li><a href="/diensten/support/">Support</a></li>
      </ul>
    </li>
  </ul>
</nav>

Bij een klik of Enter op de knop zet het script aria-expanded op true en haalt het hidden weg. Bij opnieuw klikken gebeurt het omgekeerde. Het pijltje dat u visueel toont, hoort bij de knop en hoeft verder geen eigen tekst.

Wilt u het hoofditem zelf als knop gebruiken, dus zonder eigen pagina, dan kan dat ook. Zorg dan dat de pagina’s onder dat item allemaal in het submenu staan, want het hoofditem leidt nergens heen.

Welke toetsen een menu moet ondersteunen

Voor een gewoon websitemenu is de lat lager dan veel mensen denken. U hoeft geen ingewikkeld applicatiemenu na te bouwen. Wat bezoekers verwachten:

Pijltjestoetsen zijn een extra, geen vereiste. Gebruik vooral niet role="menu" en role="menuitem" op een gewone sitenavigatie. Die rollen zijn bedoeld voor applicatiemenu’s zoals in een tekstverwerker. Een screenreader verwacht dan pijltjestoetsbediening, en als die ontbreekt, raakt de gebruiker de weg kwijt. Een <nav> met lijsten en links is beter. Waarom die <nav> zo nuttig is voor screenreaders, leest u bij landmarks en de opbouw van een pagina.

Het mega-menu

Webshops en grotere organisaties gebruiken vaak een mega-menu: een breed paneel met kolommen, koppen en soms afbeeldingen. Voor toegankelijkheid gelden dezelfde regels, met een paar aandachtspunten:

• Koppen in het paneel zijn ook echt koppen of in elk geval duidelijke tekst, geen afbeeldingen met tekst erin.
• De volgorde in de code klopt met de volgorde op het scherm. Kolommen die met CSS anders staan dan in de HTML, laten de focus heen en weer springen.
• Het paneel past bij inzoomen. Op 200% of 400% zoom moet alles bereikbaar blijven, desnoods door over te schakelen naar het mobiele menu.
• Afbeeldingen in het paneel zijn meestal decoratief. Geef ze een lege alt, anders hoort een screenreadergebruiker elke productfoto twee keer.
• Niet te veel. Zeventig links in één paneel zijn voor iedereen zwaar, ook voor muisgebruikers.

De huidige pagina aangeven

Ziende bezoekers zien vaak aan een onderstreping of kleur in welk deel van de site ze zijn. Geef dat ook in de code door met aria-current="page" op de link van de huidige pagina. WordPress zet de klasse current-menu-item al standaard, maar het aria-attribuut niet in elk thema. Gebruik daarnaast niet alleen kleur om de actieve pagina aan te geven; een lijn of vet lettertype maakt het ook zichtbaar voor mensen die kleuren slecht onderscheiden.

Is uw menu een toegankelijk menu? Zo test u het

1. Klik in de adresbalk en druk op Tab. Komt u eerst langs een skiplink? Zo niet, overweeg er een toe te voegen; zie een skiplink toevoegen.
2. Tab door het menu. Ziet u steeds duidelijk waar de focus staat?
3. Open een submenu met Enter. Kunt u erin tabben en er met Escape weer uit?
4. Tab verder. Sluit het submenu zodra u eruit bent?
5. Maak het venster smal of zoom in tot 400%. Wordt het menu een hamburgermenu, en werkt dat ook? Daarover gaat het hamburgermenu op mobiel.

Op de pagina over bediening met het toetsenbord staat hoe u de rest van de site op dezelfde manier controleert.

Thema, plugin of maatwerk?

In WordPress komt het menu uit het thema of uit een paginabouwer. De standaardthema’s van WordPress zelf zijn redelijk op orde. Bij commerciële thema’s en mega-menuplugins verschilt het per product, en soms per versie. Vaak is het menu met een kleine aanpassing in het thema goed te krijgen: een knop toevoegen, aria-expanded laten meeschakelen en Escape afvangen. Soms is het verstandiger om een complexe menuplugin te vervangen. Dat hangt af van hoe de rest van de site gebouwd is.

Het menu is meestal het eerste waar een bezoeker mee werkt, dus een goede plek om te beginnen. Voor de volgende stappen is het overzicht voor een toegankelijke website een handig vertrekpunt.