This article is also available in English
Passend zum Thema: Unser Kollege Andreas Maier bietet das interaktive Training »Accessibility in der Praxis« mit anschließender Zertifizierung an.
Um den Inhalt einer Webanwendung barrierefrei zu vermitteln, lassen sich native HTML-Elemente und leicht erlernbare ARIA-Spezifikationen einsetzen. Der erste Teil der Serie beschrieb den Aufbau einer barrierefreien Website am Beispiel der fiktiven Versicherung “Crimson Assurance”. Die Kenntnis des Artikels hilft beim Verständnis dieses zweiten Teils, ist aber keine zwingende Voraussetzung.
Die Codebeispiele stellen auch hier nicht die einzige Umsetzungsmöglichkeit dar, sondern die Ideallösung im Rahmen der Beispielanwendung. Sie sollen die wichtigsten Elemente der barrierefreien Vermittlung von Inhalt einer Webanwendung erläutern und einen Einblick auf technischer Ebene geben. Die gezeigten Namen der Mitarbeitenden sind ebenso wie die Versicherung fiktiv.
Breadcrumb-Navigation
Der Hauptbereich jeder Seite der Webanwendung beginnt unter der Landmarke <main> mit einer Breadcrumb-Navigation. Ein Nutzer kann daran seine Position innerhalb der Websitestruktur erkennen und neben der Hauptüberschrift auch dort prüfen, ob er tatsächlich die gewünschte Seite aufgerufen hat. Über diese Navigation kann eine Nutzerin außerdem auf dem bisher gegangenen Pfad wieder bis zur Startseite zurückwandern. Neben einer leichteren Orientierung lassen sich darüber auch detailliertere Informationen über die Websitestruktur als in der Hauptnavigation vermitteln.
In Bezug auf Accessibility sollte eine Breadcrumb-Navigation deutlich als solche gekennzeichnet sein. Eine Bezeichnung wie “Sie sind hier:” liest man zu diesem Zweck häufig. Die Kennzeichnung sollte nicht nur für Screenreader sichtbar sein, sondern für alle, da die Sichtbarkeit der Kennzeichnung das rasche Auffinden der Navigation und damit der aktuellen Position ermöglicht.
Im Quellcode sollte sich der gesamte Bereich unter einer <nav>-Landmarke befinden. Wie die Hauptnavigation sollte auch diese <nav>-Landmarke per aria-label bezeichnet werden. In Crimson Assurance heißt diese Navigation “Navigationspfad”; die Bezeichnung ist visuell nicht sichtbar. “ARIA” steht für “Accessible Rich Internet Applications” und stellt eine Ergänzung von HTML dar, um UI-Elemente semantisch auszuzeichnen. Man sollte es nur verwenden, wenn HTML nicht bereits nativ die benötigte semantische Information bereitstellt.
Der Pfad sollte mit dem <ol>-Tag als sortierte Liste erscheinen. Die Liste ist mittels aria-label genauso wie die <nav>-Landmarke mit “Navigationspfad” bezeichnet. Der letzte Eintrag wird per aria-label="page" als aktuelle Seite gekennzeichnet.
Die redundante Bezeichnung der Landmarke und der Liste zeigen sowohl beim direkten Anspringen der Landmarke als auch beim direkten Anspringen der Liste unmittelbar, in welchem Bereich der Webseite man sich befindet.
Hier die Breadcrumb-Navigation auf der Kundenübersichtsseite von Crimson Assurance:
<nav aria-label="Navigationspfad">
<span>Sie befinden sich hier: </span>
<ol aria-label="Navigationspfad">
<li>
<a href=".../portal">Startseite</a>
</li>
<li>
<a href=".../portal">
Kundenübersicht
</a>
</li>
<li>
<a href=".../portal/customers/a2" aria-current="page">
Kundendeckblatt
</a>
</li>
</ol>
</nav>
Suchfelder
Crimson Assurance bietet eine Suche nach Kunden auf der Kundenübersichtsseite. Als Label des Suchfelds legt es per <label for=""> “Kundenname” fest. Die Verknüpfung mit dem Suchfeld erfolgt über die ID, die das Label eindeutig einem Element zuordnet. Ein Label lässt sich genau einem Element zuweisen und ein Element kann genau ein Label erhalten. Labels bieten eine eindeutige und von Hilfstechnologien erkennbare Beschriftung eines Elements.
Zudem ist das Label eines interaktiven Elements wie ein Eingabefeld anklickbar, um den Cursor in das Eingabefeld zu setzen. Ein Screenreader liest häufig ein Label in einer eigenen Zeile vor. Das Fokussieren eines Elements ist deutlich effizienter, da sich einfach diese Zeilen anklicken lassen, um den Fokus auf das entsprechende Eingabefeld zu setzen.
Auch wenn das Label in derselben Zeile vor einem Eingabefeld steht, ist es einfacher, an den Zeilenanfang zu springen und zu klicken, als zunächst das Eingabefeld zu fokussieren. Für motorisch beeinträchtigte Nutzer sind HTML-Labels sehr hilfreich, da sie den anklickbaren Bereich vergrößern. Die Syntax des Suchfelds mit dem Label “Kundenname” von Crimson Assurance lautet:
<form id="customer-search-form">
<label for="customer-search-input">Kundenname</label>
<input id=" customer-search-input">
</form>
Ein Suchfeld wird mit dem <input>-Type-Attribut search semantisch ausgezeichnet. Eine Hilfstechnologie kann diese Information an Nutzer übermitteln. Sie erfahren damit direkt, um welche besondere Art von Eingabefeld es sich handelt und welche Aktion darüber durchführbar ist.
Gerade bei einem Suchfeld auf einer persönlichen Webseite bietet sich Autovervollständigung an. Sie unterstützt einerseits Nutzerinnen mit Konzentrationsschwäche und beschleunigt andererseits generell Suchen nach häufig kontaktierten Kunden.
Ein Placeholder hingegen verbessert nicht explizit die Barrierefreiheit. Es wird im Gegenteil oft von dessen Einsatz abgeraten, da sämtliche Informationen, die dort als Unterstützung angeboten werden, besser im Label erscheinen sollten. Bei Crimson Assurance steht als Placeholder ein Kundenname als Beispiel für eine mögliche Eingabe. Da diese kein bestimmtes Format erfordert, ist der Placeholder eigentlich nicht notwendig. Er dient aber als Beispiel für die Verwendung eines Placeholders. Wenn ein Placeholder beispielsweise auf ein bestimmtes Datumsformat hinweisen soll, wäre dies besser im Label des Eingabefelds anzugeben. Somit ist bei der Eingabe eines falschen Formats auch bei einer Korrektur noch erkennbar, welches Format gewünscht ist. Da ein Placeholder nach einer Eingabe nicht erneut erscheint, ist man ansonsten gezwungen, sich an das benötigte Format zu erinnern.
Bei Crimson Assurance ist die Kundensuche die erste Hauptaktivität der Webseite “Kundenübersicht”, oberhalb der zweiten Hauptaktivität “Letzte Kunden”. Das Attribut autofocus des Suchfelds setzt den Cursor beim Laden der Seite direkt in das Suchfeld, so dass ein Nutzer unmittelbar nach dem Laden der Seite nach einem Kunden suchen kann, ohne das Suchfeld ansteuern zu müssen.
Die Syntax für das Suchfeld bei Crimson Assurance lautet:
<input type="search" autocomplete="on" placeholder="Johnnie Summers" autofocus>
Crimson Assurance zeigt Ergebnisse der Suche nach Kunden nach der Eingabe von mindestens zwei Zeichen in das Suchfeld. Die Liste gefundener Kunden wird dynamisch erstellt und ändert sich mit der Eingabe weiterer Buchstaben. Ein Screenreader erkennt zunächst nicht, dass sich in einem anderen als dem aktuell fokussierten Bereich Inhalte ändern. Ohne weitere Informationen, die die Anwendung an einen Screenreader übermittelt, muss eine Nutzerin ab der Eingabe von zwei Zeichen und jedem weiteren Zeichen das Suchfeld verlassen und prüfen, wie viele Kunden gefunden wurden; ein mühsames und nicht zufriedenstellendes Vorgehen.
Um einer Hilfstechnologie wie einem Screenreader zu vermitteln, dass sich ein Bereich einer Webseite dynamisch durch Aktivitäten der Nutzer verändert, können Entwickler dem sich ändernden Bereich das ARIA-Attribut aria-live mit dem Wert "assertive" zuweisen. aria-live markiert den Bereich einer Webseite, der sich dynamisch ändert und den ein Screenreader “beobachten” soll. Hierdurch ist es nicht nötig, die komplette Seite wiederholt neu zu laden und vorlesen zu lassen, um Änderungen verfolgen zu können.
Der Wert "assertive" spezifiziert, dass es sich bei den Änderungen um dringende Informationen handelt, die die Seite unmittelbar an die User übermitteln muss. Bei einer dynamischen Suche ist es beispielsweise sinnvoll, dass die Seite unmittelbar die Anzahl der Suchergebnisse mitteilt, während eine Nutzerin noch tippt beziehungsweise wenn sie das Tippen nur für sehr kurze Zeit stoppt, um die Anzahl der Suchergebnisse anzuhören.
Bei Crimson Assurance wird der Bereich der Suchergebnisse als dynamische Region ausgezeichnet und als "assertive" priorisiert. Ab dem zweiten getippten Buchstaben gibt die Seite sofort eine Meldung über die Anzahl der Suchergebnisse aus. Darüber hinaus werden sämtliche Suchergebnisse vorgelesen. Eine Nutzerin hat somit die Möglichkeit, sich sowohl die Anzahl der Suchergebnisse als auch die Suchergebnisse selbst vorlesen zu lassen, ohne den Cursorfokus ändern zu müssen. Genügt ihr die reine Anzahl der Suchergebnisse, so muss sie nicht die komplette Ausgabe der Suchergebnisse anhören, um weiter suchen zu können, sondern kann die Ausgabe jederzeit unterbrechen.
Filteroptionen
Bei Crimson Assurance ist das Filtern sowohl der eingegangenen Nachrichten als auch der ausgegangenen Nachrichten über mehrere Optionen möglich: durch eine Volltextsuche, nach Datum sortiert, nach gelesen oder ungelesen und mit der Option, ausschließlich ungelesene Nachrichten anzuzeigen. Damit Hilfstechnologien diese Gruppe von Filteroptionen als semantisch zusammengehörende Gruppe interpretieren, wird die Gruppe mit <fieldset> umschlossen. Unabhängig davon, ob man bei zeilenweisem Lesen von oben oder unten auf die Gruppe trifft, in das Suchfeld, zu der Auswahlliste mit den übrigen Filteroptionen oder auf die Checkbox mit der Option, nur ungelesene Nachrichten anzuzeigen, springt, erhält man somit immer die Meldung, dass man sich in einer Gruppe mit Filteroptionen befindet.
Hierfür wird neben <fieldset> zusätzlich <legend> angegeben, mit dem die Gruppe beschriftet wird. Bei Crimson Assurance ist die Filtergruppe beschriftet mit “Nachrichteneingang filtern”. Diese Beschriftung ist nicht sichtbar, sondern steht durch "sr-only" nur Hilfstechnologien zur Verfügung. Visuell ist bereits deutlich, dass es sich um eine Gruppe von Filtermöglichkeiten der Nachrichten handelt. Das Unsichtbarmachen der Beschriftung führt zu einer übersichtlicheren Seite.
Die Syntax bei Crimson Assurance lautet für das Filtern des Nachrichteneingangs:
<fieldset>
<legend class="sr-only">Nachrichteneingang filtern</legend>
<label for="inbox-search">Suche</label>
<input type="text" name="inbox-search" id="inbox-search" value="">
<label for="in-message-sort">Sortieren nach</label>
<select id="in-message-sort" name="inbox-sort">
<option value="date-desc" selected>
Datum (Neueste zuerst)
</option>
<option value="date-asc">
Datum (Älteste zuerst)
</option>
<option value="unread-first">
Status (Ungelesene zuerst)
</option>
<option value="unread-last">
Status (Gelesene zuerst)
</option>
</select>
<input id="only-show-unread" name="only-show-unread" type="checkbox"
value="true">
<label for="only-show-unread">
Nur ungelesene Nachrichten anzeigen
</label>
<button type="submit">
Filtern
</button>
</fieldset>
Paginierungen
Die Beispiel-Website zeigt eingegangene und ausgegangene Nachrichten gleichzeitig an. Beides befindet sich auf derselben Webseite in zwei separaten Bereichen mit jeweiliger Filtermöglichkeit. Für beide Übersichten ist eine Paginierung mit zehn Nachrichten auf jeder Übersichtsseite implementiert. Für die Accessibility erfolgt die Paginierung durch Schaltflächen, die innerhalb eines Navigationsbereichs per <nav> gruppiert sind. Dieser Navigationsbereich ist mit aria-label="Durch eingegangene Nachrichten blättern" beziehungsweise mit aria-label="Durch ausgegangene Nachrichten blättern" beschriftet.
Zu Beginn dieser Navigationsbereiche erfährt eine Nutzerin, wie viele Seiten die Nachrichtenübersicht umfasst und auf welcher Seite sie sich aktuell befindet. Sichtbar sind hier die reinen Zahlen, beispielsweise “1 / 4”. Eine Hilfstechnologie soll ausgeben, worum es sich bei diesen Zahlen handelt, da dies nicht eindeutig über die visuelle Positionierung der Angabe in Relation zu den Suchergebnisseiten erkennbar ist. Diese zusätzliche Angabe erfolgt bei Crimson Assurance mit dem Kommando aria-description:
<p aria-description="Seite">1 / 4</p>
Die Schaltflächen “Nächste Seite”, “Vorherige Seite”, “Erste Seite” und “Letzte Seite” blättern durch die Nachrichtenübersicht. Sie werden abhängig von der aktuellen Seite ein- beziehungsweise ausgeblendet, so dass nur diejenigen Aktionen verfügbar sind, die zu einer Änderung der Seitenübersicht führen. So fehlen beispielsweise auf der ersten Seite die Schaltflächen “Vorherige Seite” und “Erste Seite”.
Die Beschriftungen der Schaltflächen sind nicht sichtbar, sondern werden per aria-label nur einer Hilfstechnologie mitgeteilt. Sichtbar sind Symbole, die den Schaltflächen per CSS zugewiesen werden. Auch hier schränkt eine Maßnahme für eine bessere Barrierefreiheit das Aussehen in keiner Hinsicht ein und erlaubt die kreative Ausgestaltung einer modernen Oberfläche.
Die Navigation über die verschiedenen Seiten der angezeigten Nachrichten wird unter jeder Seite, also im Fall von Crimson Assurance unterhalb der zehnten Nachricht, wiederholt. Das verhindert, dass man zunächst wieder das Paginierungsmenü aufsuchen muss. Wer Konzentrationsprobleme oder Orientierungsschwierigkeiten hat, profitiert hiervon ebenso wie Nutzer von Screenreadern, die an dieser Stelle blättern und effizient von unten nach oben durch die Nachrichten springen können, um einen Überblick zu erhalten und eine gesuchte Nachricht zu finden.
Damit ungelesene oder wichtige Nachrichten schnell auffindbar sind, verwendet Crimson Assurance Icons neben jeder Nachricht, die den entsprechenden Status angeben. Damit auch Hilfstechnologien diese Informationen auslesen können, erhalten die per CSS erzeugten Icons ein aria-label:
<span aria-label="Ungelesen"></span>
Umfangreiche Listenelemente
Jeder Kunde erscheint bei Crimson Assurance in einer eigenen Kachel mit Name, Adresse, Geburtsdatum und E-Mail-Adresse. Die Kacheln sind in einer ungeordneten Liste eingebunden. Hierdurch erfährt ein Screenreader-Nutzer die Anzahl der angezeigten Kunden. Die Liste der letzten Kunden beispielsweise ist per aria-label als “Letzte Kunden” bezeichnet. Ein Screenreader meldet durch die Listenstruktur und die Bezeichnung mit aria-label: “Letzte Kunden Liste mit 5 Einträgen”.
Da ein Sprung in diese Liste für einen Screenreader direkt möglich ist, erleichtern diese Angaben die Orientierung deutlich. Bei einem solchen Sprung liegt der Fokus auf dem ersten Element der Liste und die erste Zeile des ersten Elements wird ebenfalls angesagt. Im Beispiel lautet die Ausgabe: “Letzte Kunden Liste mit 5 Einträgen George Burke”.
Als weitere Besonderheit zur Erhöhung der Accessibility sind in Kundenkarten die jeweiligen E-Mail-Adressen per aria-describedby mit den Namen der entsprechenden Kunden verknüpft, da E-Mail-Adressen nicht immer den vollständigen Klarnamen des Adressaten beinhalten.
aria-describedby verweist auf die ID des Elements, mit dem es verknüpft wird. Im Beispiel erhält der Name die ID “customer-id-a2”. Auf diese ID verweist aria-describedby in dem E-Mail-Link. Liest nun ein Screenreader die E-Mail-Adresse aus, nennt er nach der E-Mail-Adresse den verknüpften Namen. Die Ausgabe lautet in diesem Beispiel: “E-Mail: [email protected] George Burke”. Ohne aria-describedby würde der Name nicht genannt.
Bei Crimson Assurance lautet der Code mit Listenbezeichnung und Verknüpfung:
<ul id="last-customers" aria-label="letzte Kunden">
<li>
<a
href=".../portal/de/customers/a2">
<h3 id="customer-id-a2">George Burke</h3>
<p>Musterstraße 12, 12345 Musterstadt</p>
<p>Geburtstag: 04.11.2000 </p>
</a>
<p>
<a href="mailto:[email protected]" aria-describedby="customer-id-a2">
E-Mail: [email protected]
</a>
</p>
</li>
...
</ul>
Pop-up-Menüs
Bei Crimson Assurance zeigt das Benutzermenü einem angemeldeten Benutzer in der Hauptnavigation die Anzahl der von ihm noch ungelesenen Nachrichten von Kolleginnen und Kollegen an. Bei Aktivierung der Schaltfläche zeigt das Menü eine Vorschau der ersten fünf ungelesenen Nachrichten. Darunter erscheinen bei einem Klick auf den Link Mehr Nachrichten alle ungelesenen Nachrichten in dem Nachrichtenfenster mit aktiviertem Filter “Nur ungelesene Nachrichten anzeigen”. Falls weniger als fünf ungelesene Nachrichten vorhanden sind, erscheint im Pop-up-Menü dennoch der Link “Mehr Nachrichten”, selbst wenn keine ungelesenen Nachrichten vorhanden sind. Auf der Nachrichtenseite besteht die Möglichkeit, sich alle Nachrichten anzeigen zu lassen.
Damit ein Screenreader erkennen kann, dass es sich hier um ein Pop-up handelt und ob die Übersicht der ungelesenen Nachrichten gerade gezeigt wird oder nicht, kommt das ARIA-Attribut aria-expanded mit den Werten true, falls das Pop-up ausgeklappt ist, und false, falls es eingeklappt ist, zum Einsatz. Sonst würde ein Screenreader-Nutzer nicht erfahren, dass ein Klick auf die Anzeige der Anzahl ungelesener Nachrichten weitere Informationen anzeigt. Der Screenreader würde das Pop-up für eine einfache Schaltfläche halten, die ihre Möglichkeit, aufgeklappt zu werden, nicht offenbart.
Durch aria-haspopup="true" erkennt ein Screenreader, dass es sich um ein aufklappbares Menü handelt, das im ausgeklappten Zustand anderen Inhalt überlagert. Um einem Screenreader zu melden, welche Liste das Öffnen des Menüs präsentiert, ist eine Bezeichnung der Liste im <ul>-Tag per aria-label notwendig. Die bei Crimson Assurance für die Liste verwendete Bezeichnung “Vorschau: ungelesene Nachrichten” macht in wenigen Worten deutlich, was die Liste zeigt. Dass sie nur die ersten fünf ungelesenen Nachrichten enthält, ist nicht in der Bezeichnung der Liste nötig. Ein Screenreader erkennt eine Liste mit sechs Einträgen, nämlich fünf ungelesene Nachrichten plus den Link “Mehr Nachrichten”, für den Aufruf sämtlicher ungelesener Nachrichten.
Der Code für den Aufruf der letzten fünf Nachrichten einer Nutzerin nach dem Öffnen des Buttons mit der Anzeige von zwei neuen Nachrichten und für die Anzeige dieser Nachrichten bei geöffneter Vorschau mit Nachrichtenbetreff und Datum in der Beispielanwendung:
<button aria-haspopup="true" aria-expanded="true">
<span>
2 neue Nachrichten
</span>
</button>
<section>
<ul aria-label="Vorschau: ungelesene Nachrichten">
<li>
<a href=".../postbox/de/messages/9/">
<h3 id="messages-id-9">
<span id="message-status-9" class="unread-icon"
aria-label="Ungelesen">
</span>
<span>
<span>Jo Spam</span>
<span>Vertrag E355</span>
<span>19.06.2022, 01:49</span>
</span>
</h3>
</a>
</li>
...
<a href=".../postbox/de/messages/inbox/">
Mehr Nachrichten
</a>
</ul>
</section>
Innerhalb des Benutzermenüs in jedem Header der Website befinden sich auch ein Avatar und der Name des aktuell angemeldeten Nutzers. Fehlt Ersterer, enthält dieser Bereich die Initialen. Da diese keinen inhaltsrelevanten Mehrwert bieten, sondern eher die Verständlichkeit erhöhen und das effiziente Erkennen von Informationen erschweren, versteckt Crimson Assurance sie per aria-hidden für den Screenreader.
Die Schaltfläche “Nutzername” öffnet beim Klick ein Menü, das die Option zum Abmelden bietet. Wie bei der Übersicht über die ungelesenen Nachrichten weist auch hier aria-expanded="true" beziehungsweise aria-expanded="false", auf ein ausklappbares Menü und seinen Zustand hin. Mit aria-haspopup erkennt der Screenreader, dass ein Klick auf den Button ein Untermenü öffnet, das anderen Inhalt überlagert.
In Crimson Assurance lautet der Code für die Schaltfläche und das Popup-Menü im geschlossenen Zustand für den fiktiven Nutzer Max Mustermann:
<li>
<button data-toggle="dropdown"
aria-haspopup="true"
aria-expanded="false">
Max Mustermann
</button>
<a
href=".../portal/de/logout">
Abmelden
</a>
</li>Tabellen
Eine Auswahl eines Kunden öffnet bei Crimson Assurance eine Webseite mit dessen Daten. Sie unterteilen sich in persönliche Daten mit Name, Adresse, Geburtsdatum, Telefonnummer, Beruf und E-Mail-Adresse und Daten zu dem aktuellen Bestand des Kunden, der sich aus Verträgen und Angeboten zusammensetzt. Verträge und Angebote werden jeweils übersichtlich in Tabellen dargestellt.
Ein Screenreader kann Tabellen direkt anspringen und sie analysieren. Darin kann man sich gut orientieren, indem man komplette Spalten oder komplette Zeilen liest oder von Zelle zu Zelle navigiert. Dafür muss eine Tabelle syntaktisch korrekt mit den nativen HTML-Elementen erstellt werden. Damit ein Screenreader sie als Tabelle erkennt, braucht sie ein umgebendes <table>-Tag. Die Angabe von <caption> erzeugt eine Tabellenüberschrift, die einer Screenreader-Nutzerin vorgelesen wird, wenn sie per Tastendruck direkt zu einer Tabelle springt. Ohne Tabellenüberschrift gäbe es nur eine Ansage wie “Tabelle mit 5 Zeilen und 4 Spalten”. Mit Überschrift gibt der Screenreader bei einer Tabelle mit Angaben zu Verträgen etwa folgendes aus: “Verträge Tabelle mit 5 Zeilen und 4 Spalten”.
In Crimson Assurance ist die Beschriftung innerhalb des <caption>-Tags nur für Hilfstechnologie sichtbar, da visuell bereits entsprechende Überschriften zeigen, ob es sich um die Tabelle mit Verträgen oder um diejenige mit Angeboten handelt. Eine zusätzliche Auszeichnung für Hilfstechnologien ist allerdings insbesondere für Screenreader nützlich, da bei einem Sprung direkt zu dieser Tabelle deutlich wird, welche Daten dort gezeigt werden. Visuell verbergen und nur für Hilfstechnologien sichtbar machen lässt sich diese Caption beispielsweise durch die Bootstrap-Klasse "sr-only".
Mit dem <thead>-Tag wird eine Gruppe von Spaltenüberschriften erstellt, das Tag <tbody> gruppiert den Tabelleninhalt in Zeilen und Zellen. Jede Spalte und jede Zeile einer Tabelle benötigt eine Überschrift, die mit dem Tag <th> definiert wird. Das Attribut scope innerhalb des <th>-Tags teilt einem Screenreader mit, ob es sich um eine Spalte oder eine Zeile handelt. scope=“col” markiert eine Spalte, scope="row" eine Zeile.
Sichtbare Auswirkungen hat diese Angabe nicht. Sie sorgt aber dafür, dass ein Screenreader bei jedem Zeilen- und Spaltenwechsel den Namen der Zeile beziehungsweise der Spalte nennt. Insbesondere in großen, komplexen Tabellen erleichtert das die Navigation und Orientierung enorm.
In Crimson Assurance ist die Tabelle mit der Übersicht über die Verträge eines bestimmten Kunden wie folgt strukturiert:
<table>
<caption class="sr-only">Verträge</caption>
<thead>
<tr>
<th scope="col">#</th>
<th scope="col">Sparte</th>
<th scope="col">Betrag</th>
<th scope="col">Währung</th>
</tr>
</thead>
<tbody>
<tr>
<td>4712</td>
<td>KFZ</td>
<td>32.4</td>
<td>EUR</td>
</tr>
...
</tbody>
</table>
