Inhalte & Verständlichkeit

Barrierefreiheit wird häufig als rein technisches Thema missverstanden. In dieser unvollständigen Wahrnehmung muss nur der zugrundeliegende Code stimmen, um eine Oberfläche nutzbar und zugänglich für alle zu machen. Dabei ist ein großer Teil der Zugänglichkeit die Verständlichkeit von Interfaces, seinen Inhalten und Funktionen. Damit wird offensichtlich, dass die Zugänglichkeit neben einem technischen einen redaktionellen Aspekt besitzt.

Wenn das Projekt „E-Commerce Barrierefrei“ von „zugänglichen Mustern“ spricht, dann ist damit nicht nur z. B. barrierefreier Code in Komponentenform gemeint, sondern auch Strategien für verständliche Texte, angemessene Alternativinhalte und klare Anweisungen.

Doch sehen wir uns zunächst einmal an, was Barrierefreiheitsrichtlinien für digitale Projekte dazu zu sagen haben – denn diese Dokumente sind sehr häufig ein Konzentrat aus „Learnings“ im Umgang mit realen Barrieren (und sagen vor allem, wie man sie vermeidet):

Die zentrale Barrierefreiheits-Norm WCAG (Web Content Accessibility Guidelines) setzt sich aus vier Grundpfeilern zusammen: Wahrnehmbarkeit, Bedienbarkeit, Robustheit und eben auch – Verständlichkeit. Unter dieser Überschrift finden sich solche Aspekte wie Vorhersehbarkeit der Oberfläche (z. B. in Form von gleichbleibender und erwartbarer Navigation), das Erklären von Abkürzungen und ungewöhnlichen Wörtern, ein Fehlermanagement, welches deutlich und vor allem hilfreich sein muss, sollte es zu Fehlern bei der Dateneingabe durch Nutzende kommen.

Aber „Verständlichkeit“ lässt sich als roter Faden durch die komplette WCAG (und auch durch die komplette digitale Barrierefreiheit) sehen, und aus diesem Grund finden sich seine Bestandteile auch in anderen, sogenannten Erfolgskriterien (oder „Prüfschritten“) der „Web Content Accessibility Guidelines“:

Denkt man an „Alternativtexte“, so fallen einem als Erstes die Texte für Abbildungen ein, die den Kontext, die Informationen und nötigenfalls auch die Emotionen eines Bildes erläutern.

Aber das erste Erfolgskriterium der WCAG mit der Nummer 1.1.1 ist allgemeiner gefasst: So spricht es ganz abstrakt von Nicht-Text-Inhalten, die eine Alternativfassung in Form von Text haben müssen. Da diese den Inhalt (z. B. eine Karte, ein Video und in früheren Zeiten eine Flash-Einbindung) ersetzen können muss, ist es nötig, dass die Redaktion den Kontext des Nicht-Text-Objektes versteht, um eine gleichwertige Textalternative anzubieten. Hinweise, wie das für Bilder zu realisieren ist, bietet beispielsweise hier die britische BBC für eigene Redakteur*innen an (automatische Übersetzung aus dem Englischen). Hat man es eher mit einem Video zu tun, so ist die genaue Art der Einbindung entscheidend: passiert eine Einbindung (wie häufig bei z. B. YouTube-Videos) über einen <iframe>, so liefert das title-Attribut zugänglichen Namen und Alternativtext. Im Falle von beispielsweise direkter Einbindung als <video>-Element stehen die Attribute aria-label bzw. aria-labelledby für die gleichen Zwecke zur Verfügung. Eine Medienalternative, die den Inhalt eines Videos in Textform wiedergibt, kann beispielsweise so aussehen:

Ähnlich den Alternativtexten von Medien jeder Art besteht auch die Betitelung von Button- und Linkbezeichnern im Kern aus zwei Bestandteilen:

Während der erste Aspekt vor allem ein technischer ist, bietet der zweite eine redaktionelle Herausforderung an: Da Screenreader sich manchmal alle Schaltflächen oder Links in einem Dokument gesondert ausgeben lassen, ist es notwendig, dass diese ohne Kontext funktionieren und beschreibend sind. Zehnmal „weiterlesen“ ausgegeben zu bekommen klärt jeweils nicht über das jeweilige Linkziel auf, ist redundant und kann eine Verständnisbarriere darstellen. Übrigens gibt es durchaus Strategien, die visuelle Ausgabe der Links bei z. B. „weiterlesen“ zu belassen, den programmatisch bestimmbaren Bezeichner der Links für Screenreader-Nutzende aber deutlich beschreibender zu machen:

Aber die Redaktion muss auch wissen, dass häufig verwendete Linktexte wie „hier“ eine Barriere darstellen und zu vermeiden sind.

Zur Vertiefung bietet die Bayrische Architektenkammer hier einen gesonderten Artikel zum Thema an (sehen Sie den Ratschlag hier in der Praxis und wie man dennoch ein „hier“ unterbringen kann?)

Wie im Formular-Modul schon formuliert, sind Formulareingaben ganz wesentlich für E-Commerce-Kontexte und wichtiger Teil der Kommunikation mit Kund*innen in spe, denn sie fragen beispielsweise Produkt- oder Dienstleistungsvariationen, Liefer- und Bezahldaten ab. Und gleichbedeutend mit der Fähigkeit, klare Fragen im zwischenmenschlichen Zusammenhang zu stellen, sind auch verständliche Bezeichner-Texte für Eingabefelder für das Verständnis der Oberfläche (und was sie von einem will) wichtig. Wie vieles in diesem Modul hat auch dieser Aspekt mit einer Gestaltung seiner Inhaltsstrategie (oder „Content Design“) zu tun, und dass ein wichtiger Bestandteil von ihr eben auch die Optimierung auf Verständlichkeit (und das auch bei z. B. nicht-visueller Nutzung der Oberfläche) wird.

Hier finden Sie ein automatisch ins Deutsche übersetzte Verständnis(sic!)-Dokument, das die WCAG-Anforderung nach klaren Bezeichnern (2.4.6) tiefergehend erläutert.

In die gleiche Bresche der verständlichen Kommunikation mit der oder dem Nutzenden schlagen auch verständliche und hilfreiche Fehlermeldungstexte. Betrachtet man diese abstrakt und sieht sie im Beispiel eines menschlichen Austauschs, wiederholen diese die Ursprungsfrage erneut in anderen Worten und weisen darauf hin, wie eine „ungültige“ Antwort zukünftig vermieden werden kann.

Daraus ergibt sich, dass Fehlermeldungstexte (wenn es eine Fehlerbehandlung gibt) klar und hilfreich sein müssen, etwas, das WCAG-Erfolgskriterium 3.3.3 ausdrücklich abfragt und auch auf dem Spielfeld der Redaktion liegt.

Zum Start könnten Sie diese (automatische) Übersetzung einer Zusammenfassung des Problems (natürlich inklusive Lösungsvorschlägen) an Ihre Redaktion weitergeben.

Eine Optimierung von Dokumententiteln kennen Sie vermutlich aus dem SEO-Zusammenhang – oder wie wichtig dieser wird, sollte man ein Dokument als Lesezeichen ablegen.

Alle genannten Aspekte dienen aber auch einer besseren Zugänglichkeit, gerade was das Verständnis dieses Titels angeht. Fast immer sind Dokumententitel das Erste, was Screenreader-Nutzende von einem Dokument erfahren, und entsprechend beschreibend und ankündigend müssen diese sein. Deswegen ist es nicht nur ein Barrierefreiheits-Best-Practice mit dem Namen des Dokuments oder sonstigen Zustands („Views“) zu beginnen und erst dann den Namen der Webpräsenz zu nennen:

Die Kolleg*innen von Gehirngerecht Digital fassen die Wichtigkeit guter Dokumententitel hier noch einmal kurz zusammen.

Während bei gutem Webdesign die Struktur eines HTML-Dokumentes bereits grafisch klar und verständlich wird, ist es bei nicht-visueller Nutzung etwas herausfordernder, das Interface verständlich zu machen. Hält man sich z. B. grafisch an Konventionen zur Gestaltung eines Fußbereiches, wird tendenziell durch Design-Entscheidungen klar, dass hier unter anderem Kontaktinformationen, rechtliche Links und Verweise auf Social-Media-Präsenzen zu erwarten sind.

Anders sieht es allerdings aus, wenn man die grafische Ausgabe eines Dokuments unberücksichtigt lässt und dennoch sein Verständnis sicherstellen will. Dazu gibt es HTML-Elemente wie <header>, <main> und <footer>, die ein Dokument ähnlich (wenn auch abstrahiert) strukturieren können, wie es einer grafischen Ausgabe gelingen kann. Diese richtige und klare Verwendung der sogenannten ARIA-Landmarks ist ebenfalls kein rein technisches Thema (auch wenn es vielleicht auf den ersten Blick so scheint, weil wir von HTML-Auszeichnungen reden), sondern erfordert eine kleine Planungsstrategie, die wichtig für die Barrierefreiheit, aber nicht eindeutig grafischer Gestaltung oder Webentwicklung zuzuordnen ist.

Wie viele Aspekte der Web-Barrierefreiheit ist das elementare Thema „Verständlichkeit“ eines, das sich als department-übergreifend herausstellt und die Fehleinschätzung, dass Zugänglichkeit ein rein technisches Thema ist, beendet. Vielmehr muss man - will man Barrieren abbhauen - eine Haltung entwickeln, die alle Beteiligten an einem Webprojekt einbezieht.

Dieser (wie so häufig automatisch übersetzte) Artikel fasst noch mal alle Aspekte der Verständlichkeit im Kontext der Web-Barrierefreiheit zusammen und nennt weitere WCAG-Erfolgskriterien.