Toegankelijke tabs: tabbladen op een webpagina die iedereen bedient

Tabbladen zijn verleidelijk. Een productpagina met “Beschrijving”, “Specificaties” en “Reviews” naast elkaar ziet er opgeruimd uit, en de pagina wordt een stuk korter. Toch is dit een van de onderdelen waar we bij controles het vaakst iets vinden. Niet omdat tabs per definitie ontoegankelijk zijn, maar omdat er een vast patroon bij hoort dat veel thema’s maar half volgen. Wie toegankelijke tabs wil, moet dat patroon kennen. En moet zich eerlijk afvragen of tabbladen op die plek de beste keuze zijn.

Eerst de vraag: heeft u tabbladen nodig?

Tabbladen verbergen inhoud. Een bezoeker ziet maar één paneel tegelijk en moet weten dat de andere bestaan. Dat werkt goed als de panelen echt los van elkaar staan en de meeste mensen maar één ervan nodig hebben. Bijvoorbeeld: prijzen voor particulieren en voor bedrijven, of instructies voor Windows en voor Mac.

Het werkt minder goed als:

• de meeste bezoekers alle panelen willen lezen;
• er belangrijke informatie in een tweede of derde tab staat, zoals verzendkosten of retourvoorwaarden;
• de panelen kort zijn, zodat ze onder elkaar ook prima passen;
• er meer tabs zijn dan op een telefoonscherm naast elkaar passen.

In die gevallen zijn gewone koppen met de tekst eronder vaak beter. Ze zijn eenvoudiger te bouwen, werken met Ctrl+F, worden geprint en zijn voor screenreadergebruikers goed te scannen met de koppensneltoets. Op mobiel klappen veel thema’s tabbladen al om naar een accordeon; daarover gaat het artikel over uitklapblokken en FAQ's.

Het patroon voor toegankelijke tabs

Kiest u wel voor tabbladen, dan verwacht een screenreader een bepaalde opbouw. Die is vastgelegd in de ARIA Authoring Practices van het W3C:

<div class="tabs">
  <div role="tablist" aria-label="Productinformatie">
    <button role="tab" id="tab-1" aria-selected="true"
            aria-controls="paneel-1">Beschrijving</button>
    <button role="tab" id="tab-2" aria-selected="false"
            aria-controls="paneel-2" tabindex="-1">Specificaties</button>
  </div>
  <div role="tabpanel" id="paneel-1" aria-labelledby="tab-1"
       tabindex="0">...</div>
  <div role="tabpanel" id="paneel-2" aria-labelledby="tab-2"
       tabindex="0" hidden>...</div>
</div>

Wat deze code doet:

• role="tablist" vertelt dat het om een groep tabbladen gaat, met een naam via aria-label.
• Elke tab is een knop met role="tab". Met aria-selected weet de screenreader welke actief is.
• Alleen de actieve tab zit in de normale tabvolgorde. De andere krijgen tabindex="-1".
• Elk paneel heeft role="tabpanel" en verwijst terug naar zijn tab.

De toetsen die erbij horen

Hier zit de grootste valkuil. Zodra u role="tab" gebruikt, verwacht een ervaren screenreadergebruiker dat hij met de pijltjestoetsen tussen de tabs wisselt, niet met Tab. Het patroon is:

U kunt kiezen of een tab direct wordt geactiveerd zodra de focus erop komt, of pas na Enter. Direct activeren is prettig als de panelen meteen geladen zijn. Moet er iets worden opgehaald, kies dan voor handmatig, anders laadt elke pijltjesdruk een nieuw paneel.

Gebruikt een thema wel de rollen maar niet de pijltjestoetsen, dan is het resultaat slechter dan helemaal geen rollen. De screenreader kondigt een tablijst aan, de gebruiker drukt op pijl rechts en er gebeurt niets. Op de pagina over toetsenbordbediening van uw website leest u hoe u zulke patronen in het algemeen nakijkt.

Linken naar een specifieke tab

Een detail dat vaak ontbreekt: wat gebeurt er als iemand een link deelt naar de informatie in de derde tab? Bij veel thema’s komt de ontvanger gewoon op de eerste tab uit en moet hij zelf zoeken. Laat het script bij het laden kijken naar het anker in de adresbalk, bijvoorbeeld #specificaties, en open dan direct de juiste tab. Dat helpt iedereen, maar vooral mensen die met een screenreader of vergroting werken en niet in één oogopslag zien dat er meer tabbladen zijn. Zet de focus daarbij niet automatisch in het paneel; laat de bezoeker de pagina gewoon van boven lezen.

Zichtbaar ontwerp

Ook ziende bezoekers moeten kunnen zien welke tab actief is. Doe dat niet alleen met kleur. Een onderstreping, een rand die doorloopt in het paneel of een vet lettertype werkt voor mensen die kleuren slecht onderscheiden. Zorg dat de focus goed zichtbaar is, ook op de actieve tab. En test hoe de tabs zich gedragen bij inzoomen: bij 400% zoom passen vier tabs vaak niet meer naast elkaar. Laat ze dan netjes doorlopen op een tweede regel of omschakelen naar koppen, in plaats van ze horizontaal te laten scrollen.

Tabs in WordPress-thema’s en paginabouwers

WooCommerce toont productinformatie standaard in tabbladen. Elementor, Divi en andere bouwers hebben een eigen tabs-element. De kwaliteit verschilt per versie, en eerdere problemen zijn soms in latere updates opgelost. Controleer daarom zelf, met de stappen hieronder, in plaats van uit te gaan van wat u ergens heeft gelezen.

Werkt het tabs-element van uw bouwer niet goed, dan zijn er drie routes: de inhoud omzetten naar koppen, overstappen op een ander element, of het gedrag met wat extra script aanvullen. Het laatste is het meeste werk en kan breken bij een update. De eerste route is vaak de beste.

Snel testen

1. Tab naar de tabbladen. Komt de focus op de actieve tab?
2. Druk op pijl rechts. Gaat de focus naar de volgende tab, en wordt het juiste paneel getoond?
3. Druk op Tab. Komt u in het paneel, of springt u naar de volgende tab?
4. Luister met een screenreader: hoort u iets als “Specificaties, tab, 2 van 3, geselecteerd”?
5. Bekijk de pagina op 400% zoom en op een smalle telefoon.

Valt het tegen, overweeg dan of koppen niet eenvoudiger zijn. Een goed opgebouwde pagina met heldere tussenkoppen doet vaak hetzelfde werk; lees daarvoor hoe u koppen logisch opbouwt. Hoe tabbladen passen in de rest van de toegankelijkheid van uw site, leest u in onze uitleg over een toegankelijke website.