Digitaal toegankelijke tablist?

De 3 onmisbare ARIA-rollen voor tablists

Om een schermlezer te laten begrijpen hoe jouw tabbladen werken, gebruiken we WAI-ARIA. Dit is een set extra codes die je toevoegt aan je HTML. Een goed toegankelijke tablist bestaat altijd uit drie lagen, die elk een eigen ARIA-rol krijgen:

• role="tablist" (de container): Dit is het element waar alle tab-knoppen in zitten. Zodra een screenreader hier aankomt, weet de gebruiker dat hij een lijst met tabbladen binnengaat.
• role="tab" (de knop): Dit is het tabblad zelf, oftewel de knop waar je op klikt. Gebruik hiervoor bij voorkeur een <button>-element. Al deze knoppen moeten binnen de tablist staan.
• role="tabpanel" (de inhoud): Dit is het blok met de tekst of afbeeldingen die bij het tabblad horen.

Tip: Twijfel je welk ARIA-label je nodig hebt voor andere knoppen of menu’s? Gebruik dan de gratis ARIA-label generator van Audit House.

Belangrijke ARIA-attributen: koppel alles aan elkaar

Naast de rollen is het belangrijk om de knoppen en de inhoud aan elkaar te koppelen. Dit doe je met deze drie verplichte attributen:

• aria-selected: Geeft aan of het tabblad open is (true) of dicht (false). Dit attribuut pas je via JavaScript aan zodra iemand van tabblad wisselt. Er mag altijd maar één tabblad tegelijk op true staan.
• aria-controls: Dit attribuut zet je op de knop. Het bevat het ID van het bijbehorende tekstpaneel. Hierdoor kan ondersteunende software de relatie tussen knop en inhoud begrijpen.
• aria-labelledby: Dit zet je op het tekstpaneel. Het wijst terug naar het ID van de knop. Zo weet de screenreader altijd welke titel bij de inhoud hoort.

Toetsenbordnavigatie: gebruik pijltjestoetsen, niet de Tab-toets

De meest gemaakte fout door ontwikkelaars is het plaatsen van alle tab-knoppen in de normale tab-volgorde met tabindex="0".

Stel je voor: je hebt een menu met 30 tabbladen. Als je de Tab-toets gebruikt om te navigeren, moet je 30 keer op Tab drukken voordat je eindelijk bij de tekst bent. Dit is frustrerend en past niet bij hoe een toegankelijke tablist hoort te werken.

Een tablist telt als één geheel. Daarom gebruik je roving tabindex:

1. Alleen het actieve tabblad krijgt tabindex="0".
2. Alle andere tabbladen krijgen tabindex="-1".
3. De gebruiker gebruikt de pijltjestoetsen om tussen de tabbladen te wisselen.

Via JavaScript zorg je ervoor dat de focus logisch meeschuift naar het volgende of vorige tabblad. Op die manier blijft de bediening snel en overzichtelijk.

Tabbladen openen: automatisch of handmatig

• Automatisch openen: zodra de focus op een nieuw tabblad komt, opent de inhoud direct. Dit werkt goed als alle inhoud al op de pagina staat.
• Handmatig openen: de gebruiker verplaatst eerst de focus met de pijltjestoetsen en activeert daarna met Enter of Spatiebalk. Dit is veiliger als inhoud nog geladen moet worden.

Praktijkvoorbeeld: een toegankelijke tablist

Bekijk de basis HTML-structuur van een toegankelijke tablist. Let goed op hoe de ID’s, ARIA-attributen en de tabindex met elkaar samenwerken.

<div class="tabs-container">
  <!-- 1. De Tablist container -->
  <div role="tablist" aria-label="Informatie overzicht">
    
    <!-- Actieve tab (tabindex="0") -->
    <button id="tab-1" role="tab" aria-selected="true" aria-controls="panel-1" tabindex="0">
      Introductie
    </button>
    
    <!-- Inactieve tab (tabindex="-1") -->
    <button id="tab-2" role="tab" aria-selected="false" aria-controls="panel-2" tabindex="-1">
      Specificaties
    </button>
  </div>

  <!-- 2. De bijbehorende Tabpanelen -->
  <div id="panel-1" role="tabpanel" tabindex="0" aria-labelledby="tab-1">
    <h3>Introductie</h3>
    <p>Hier staat de inhoud van het eerste tabblad.</p>
  </div>

  <div id="panel-2" role="tabpanel" tabindex="0" aria-labelledby="tab-2" hidden>
    <h3>Specificaties</h3>
    <p>Hier staat de inhoud van het tweede tabblad. Het 'hidden' attribuut verbergt dit paneel.</p>
  </div>
</div>

Test zelf het werkende voorbeeld van deze toegankelijke tablist.

De 3 meest gemaakte WCAG-fouten bij tablists

Bij Audit House komen we tijdens onze WCAG-audits vaak dezelfde problemen tegen. Voorkom deze drie valkuilen in jouw code:

1. Geen pijltjestoets-navigatie: gebruikers moeten te vaak op Tab drukken of lopen vast in de component. Dit raakt succescriteria 2.1.1 en 2.4.3.
2. Ontbrekende ARIA-statussen: als aria-selected niet goed wordt bijgewerkt, weet een screenreadergebruiker niet welk tabblad actief is. Dit raakt criterium 4.1.2.
3. Onzichtbare focus: als de focusstijl wordt uitgezet zonder goed alternatief, raken toetsenbordgebruikers de weg kwijt. Test daarom altijd je focusstijl en kleurcontrast.

Hoe test je of jouw tablist toegankelijk is

Vertrouw nooit uitsluitend op geautomatiseerde test-tools zoals Axe of Lighthouse. Deze tools missen veel programmeerfouten in interactieve componenten. Een tool ziet vaak wel of een attribuut aanwezig is, maar niet of de bediening logisch werkt voor een mens.

Handmatig testen is daarom noodzakelijk. Test je tablist altijd met het toetsenbord én met specifieke combinaties van screenreaders en browsers. Wil je dit liever uitbesteden aan gecertificeerde specialisten? Overweeg dan een volledig WCAG 2.2 onderzoek.

Gebruik voor het testen minimaal deze combinaties:

• NVDA met Firefox op Windows
• JAWS met Google Chrome op Windows
• VoiceOver met Safari op macOS of iOS

Aan de slag met jouw tabbladen

Een digitaal toegankelijke tablist bouwen vraagt om meer dan alleen een mooi visueel ontwerp. Het vereist dat je de juiste HTML-semantiek gebruikt én dat je via JavaScript het focusgedrag en de pijltjesnavigatie goed regelt.

Zorg er altijd voor dat je jouw componenten grondig test met en zonder muis. Zo voorkom je dat je een grote groep gebruikers onbedoeld buitensluit.