Webrichtlijn 73 t/m 78: Anatomie en toegankelijkheid van een tabel
Gebruik het th (table header) element voor het beschrijven van een kolom of rij in een tabel met relationele informatie. (R-pd.11.2) Groepeer rijen met alleen th (table header) cellen met het thead (table head) element. Groepeer de rest van de tabel met het tbody (table body) element. (R-pd.11.3) Gebruik het scope attribuut voor het associëren van tabellabels (th cellen) met kolommen of rijen. (R-pd.11.4) Gebruik het header [sic] en id element [sic] voor het associëren van tabellabels (th cellen) met individuele cellen in complexe tabellen. (R-pd.11.5) Geef afkortingen voor tabellabels (th cellen) via het abbr (abbreviation) attribuut wanneer de lengte van de inhoud van het tabellabel zodanig van lengte is dat herhaling in een spraakbrowser irritatie kan wekken. (R-pd.11.6) Gebruik het caption element of heading markup voor het geven van een koptekst boven een tabel. (R-pd.11.7)
Iedereen zal de elementen tr, th en td wel kennen. Maar wanneer gebruik jij thead, tbody (expliciet) en tfoot? Het voorbeeld waarbij een thead bij een print (op papier dus) meerdere keren terugkomt kennen we ondertussen wel, dus die telt niet ;o)
"Een rij met alleen th cellen" is toch iets wat een stuk software zonder problemen automatisch als thead kan zien? Is dit misschien de reden waarom tabellen op zoveel verschillende manieren in elkaar geklust worden? Aan de goede tutorials ligt het niet, toch?
In onze oneindige zoektocht naar toegankelijkheid is het simpelweg gebruiken van th elementen natuurlijk niet genoeg. Een tabel "toegankelijk maken" moet namelijk wel moeilijk en op zichzelf al een niet bepaald toegankelijk klusje zijn. scope, headers, id en abbr attributen (ja, de Webrichtlijnen bevatten in R-pd.11.5 2 fouten, foei!) maken tabellen niet echt leuk om te bewerken. Zeker als die 4 eigenschappen geen invloed hebben op iets wat de content manager ziet. Als een tabel zo complex is dat je deze extra informatie mee moet geven, is het dan niet handiger (voor iedereen) om de data in de tabel anders te presenteren? En is het extra werk echt wel nodig?
Waarom zou je <th abbr="Werkzaamheden Randstad">Werkzaamheden in de Randstad en omstreken</th> gebruiken, in plaats van <th>Werkzaamheden Randstad</th>, met eventueel title="Werkzaamheden in de Randstad en omstreken"? Waarom wel rekening houden met "spraakbrowsers", maar niet met smalle schermen (of designs)?
Waarom is het summary attribuut trouwens niet in een Webrichtlijn verwerkt? Voelden ze soms al nattigheid m.b.t. de toekomst en HTML 5? Voor iedereen die de ontwikkeling rondom HTML 5 niet volgt: summary en abbr zitten er (nog) niet in. Wat is jouw mening hierover?
En voor alle slimme CMS'en die automatisch headers, id, scope en summary ("tabel bevat 5 rijen en 6 kolommen") attributen toevoegen om punten op de Webrichtlijnentoets te scoren: hou daar eens mee op ;-)
Reacties
- 1 Koen Willems op 11-02-2009 om 00:14 uur:
- Mwah ... om nou van een fout te spreken :-)
Maar goed: scherp opgemerkt!
Tja, tabellen. Van alle onderwerpen rond accessibility vind ik persoon tabellen altijd het lastigst, zeker als je voor de taak staat webredacteuren daar een goede instructie over te geven.
Daar komt inderdaad bij dat de headers-, id- scope- en abbr-attributen in de gangbare user agents niet zichtbaar zijn, waardoor het voor een gemiddelde webredacteur al snel acacadabra wordt.
Ik los dat zelf op door in de door mij gebruikte WYSIWYG-editor die attributen wel zichtbaar te maken.
Een ander punt is de gebrekkige ondersteuning voor tabellen in de beschikbare open source editors.
Die is in het algemeen belabberd.
Heel onlangs heb ik in totaal 9 patches voor FCKeditor in elkaar geprutst in de hoop dat dat een bijdrage zal leveren (zie http://www.fckeditor.net/forums/viewtopic.php?f=11&t=10726&start=58).
Misschien moeten we maar eens een avondje wijden aan tabellen? - 2 Sander A op 11-02-2009 om 08:23 uur:
- Enige maanden geleden kreeg ik het verzoek van een klant om de tabellen in hun webapplicatie weer als vanouds te maken, want een van hun gebruikers had er na de laatste wijzigingen problemen mee. Wat bleek: de man gebruikte een screen reader en deze kon niet overweg met het scope attribuut dat ik juist m.n. voor screen reader gebruikers had toegevoegd ;-(
De bewuste screen reader legde met het scope attribuut niet enkel de associatie tussen de th en de kolom (wat de bedoeling was), maar las de table ook gelijk maar kolomsgewijs voor!
Ik meen dat het de screen reader Supernova betrof, maar ook andere readers bleken na een korte zoektocht op het web niet goed overweg te kunnen met dit attribuut. Heb het er toen dus maar weer uit gesloopt. - 3 Krijn op 13-02-2009 om 13:00 uur:
- @Koen: header is vast een tikfoutje in de richtlijn. Op http://www.webrichtlijnen.nl/richtlijnen/#r-pd-11-5 wordt 'element' gebruikt, en op http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/tabellen/relationele-informatie/toegankelijkheid/#r-pd-11-5 'attribuut'. Zijn deze twee puntjes makkelijk recht te zetten?
Verder ontwijk je de vragen uit de post wel een beetje :) Natuurlijk kun je diep in de nacht editors patchen en overdag redacteuren bijbrengen hoe ze al die ingewikkelde meuk toe kunnen voegen. Maar is dat het allemaal wel waard? - 4 Jules op 17-02-2009 om 18:47 uur:
- @krijn element is al aangepast in attribuut. Nu nog ff headers aanpakken.
- 5 Jules op 18-02-2009 om 11:02 uur:
- @Krijn - ik heb nu ook overal in onze site header aangepast in headers