
Stel u een fysiotherapiepraktijk voor met een nette tarieventabel op de site: behandelingen links, bedragen per soort verzekering in de kolommen ernaast. Ziend bekeken in één oogopslag te begrijpen. Een schermlezer leest hem voor als: “Intake, 45, 38, 0, Behandeling, 38, 32, 0, …”. Welk getal bij welke verzekering hoort, is niet te volgen. Het verschil tussen zo’n rij getallen en een toegankelijke tabel zit in een paar elementen die in de code ontbreken.
Hoe een schermlezer een tabel leest
Een schermlezergebruiker kan zich met sneltoetsen door een tabel bewegen: cel voor cel, rij voor rij, kolom voor kolom. Bij elke cel kan de schermlezer vertellen bij welke rij- en kolomkop die hoort. “Behandeling, Basisverzekering, 38 euro.” Dat lukt alleen als de tabel in de code duidelijk maakt welke cellen kopcellen zijn.
Zonder die informatie is elke cel een losse waarde. De gebruiker moet onthouden in welke kolom hij zit en wat bovenaan stond. Bij drie kolommen is dat lastig, bij acht onmogelijk.
WCAG-succescriterium 1.3.1 Info en relaties (niveau A) vraagt dat de structuur die visueel zichtbaar is, ook in de code staat. Bij een tabel betekent dat: kopcellen moeten als kopcellen zijn gemarkeerd.
De bouwstenen van een toegankelijke tabel
Kopcellen met th
Een kopcel is een <th>, een gewone cel een <td>. Met het attribuut scope geeft u aan of de kop voor een kolom of een rij geldt:
<table>
<caption>Tarieven per behandeling, per verzekering</caption>
<thead>
<tr>
<th scope="col">Behandeling</th>
<th scope="col">Zonder aanvullende verzekering</th>
<th scope="col">Met aanvullende verzekering</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Intake</th>
<td>45 euro</td>
<td>0 euro</td>
</tr>
</tbody>
</table>
De eerste cel van elke rij is hier ook een kopcel, met scope="row". Dan zegt een schermlezer bij de cel “0 euro” zowel “Intake” als “Met aanvullende verzekering”.
Een bijschrift met caption
Het <caption>-element is de titel van de tabel. Een schermlezer leest hem voor bij het binnengaan van de tabel, zodat de gebruiker weet waar de tabel over gaat voordat hij de cellen in gaat. Het bijschrift is ook zichtbaar, en helpt ziende bezoekers net zo goed.
Eenvoud boven alles
Tabellen met samengevoegde cellen, meerdere rijen kopcellen of geneste tabellen zijn voor schermlezers zwaar. Het kan technisch wel, met de attributen headers en id, maar het is foutgevoelig. Vaak is het beter om een complexe tabel op te splitsen in twee eenvoudige tabellen.
Geen tabellen voor de lay-out
Vroeger werden hele websites in tabellen opgebouwd: een kolom voor het menu, een voor de inhoud. Dat zien we nog af en toe terug, vooral in oude e-mailtemplates en in zelfgemaakte pagina’s waar een tabel werd gebruikt om een foto naast tekst te zetten.
Een schermlezer kondigt zo’n tabel aan als “tabel met 2 kolommen en 1 rij” en laat de gebruiker er cel voor cel doorheen gaan, terwijl er geen gegevens in staan. Gebruik voor opmaak de kolommen- of groepsblokken van de editor, of CSS. Een tabel is alleen voor gegevens die echt een rij-kolomverband hebben.
Moet het in een oud e-mailtemplate toch, geef zo’n tabel dan role="presentation", zodat hulpmiddelen hem niet als gegevenstabel behandelen.
Tabellen op mobiel
Een tabel met vijf kolommen past niet op een telefoonscherm van 375 pixels breed. Wat dan?
WCAG-criterium 1.4.10 Reflow vraagt dat inhoud bij een breedte van 320 CSS-pixels bruikbaar blijft zonder in twee richtingen te scrollen. Daar is een uitzondering op voor inhoud die voor gebruik of betekenis een tweedimensionale opmaak nodig heeft, en gegevenstabellen zijn het bekendste voorbeeld. Een tabel die zelf horizontaal scrolt terwijl de rest van de pagina netjes meebeweegt, is dus toegestaan.
Doe dat wel netjes:
<div class="tabel-scroll" role="region" aria-label="Tarieven" tabindex="0">
<table>...</table>
</div>
.tabel-scroll {
overflow-x: auto;
}
De tabindex="0" zorgt dat toetsenbordgebruikers de scrollbare zone kunnen bereiken en met de pijltjestoetsen kunnen scrollen. Het label vertelt een schermlezer wat het gebied is. Geef ook visueel een hint dat er meer is, bijvoorbeeld een schaduw aan de rechterrand.
Een andere aanpak is de tabel op smalle schermen om te bouwen tot een lijst met kaarten, waarin elke rij een blok wordt met de kolomkoppen als labels. Dat kan prettig lezen, maar test dan goed of de tabelstructuur voor schermlezers behouden blijft. Sommige CSS-technieken halen de tabelbetekenis weg.
Tabellen in de WordPress-blokeditor
Het standaard tabelblok in WordPress kan een kopsectie en een bijschrift toevoegen. Zet in de instellingen van het blok “Kopsectie” aan en vul de bovenste rij met de kolomkoppen. Die worden dan <th>. Gebruik het bijschriftveld onder de tabel voor een korte titel.
Wat het standaardblok niet goed kan, zijn rijkoppen in de eerste kolom. Heeft u die echt nodig, dan kunt u het blok als HTML bewerken, of een tabelplugin gebruiken die het ondersteunt. Controleer bij zo’n plugin wel wat er in de code terechtkomt: niet elke tabelplugin produceert toegankelijke HTML.
Plak ook geen tabel als afbeelding. Een screenshot van een Excel-overzicht is voor een schermlezer niet te lezen en schaalt slecht mee bij zoomen.
Snel testen
- Bekijk de code met “Inspecteren”: staan er
<th>-elementen in de bovenste rij? - Is er een
<caption>of een duidelijke kop direct boven de tabel? - Maak het browservenster smal of zoom in tot 400 procent: is de tabel nog te gebruiken?
- Ga met een schermlezer de tabel in en beweeg met de tabelsneltoetsen. Hoort u bij elke cel de juiste kop?
Tabellen komen ook voor in documenten zoals pdf’s, met dezelfde aandachtspunten; zie pdf's toegankelijk maken. Tabellen hebben ook een plek in een goede kopstructuur, met een kop erboven die zegt waar de tabel over gaat. Het totaalbeeld staat in uw website toegankelijk maken.
Vraag een gratis websitecheck aan. Binnen één werkdag weet u waar uw website staat.
