Katrin Kampfrath

Zwischen Content und Code. Wie die Programmierung bei der barrierefreien Redaktionsarbeit unterstützen kann

Eine barrierefreie Website entsteht in der Zusammenarbeit verschiedener Disziplinen. Programmierung, Design und Redaktion (Personen, die Inhalte pflegen) haben jeweils Wissen, das sie benötigen, um ihre Arbeit barrierefrei umzusetzen. Umso wichtiger ist es, auf die Schnittstellen zwischen den Disziplinen zu achten und das Potential zu nutzen, das darin steckt, das Wissen zu teilen. In unserem Artikel zeigen wir anhand von Überschriften und Alternativtexten, wie das Programmierteam im Content Management System die Redaktion dabei unterstützen kann, leichter barrierefreie Inhalte zu erstellen.

Die richtige Überschriftenstruktur

Ein Problem, welches wir oft erst im Nachhinein sehen, sind Seiten mit viel Text, die nicht ausreichend durch Überschriften strukturiert sind, bei denen die Überschriften in falscher Hierarchie-Reihenfolge stehen oder bei denen einzelne Textzeilen lediglich fett markiert sind. 

Es gibt verschiedene Gründe, warum dies passiert. Fehlendes Wissen ist sicher ein Grund, sei es in Bezug auf den Effekt für die Barrierefreiheit, sei es in Bezug auf die Formatierungsmöglichkeiten. Oft genug ist es aber auch eine ästhetische Entscheidung. Wo korrekterweise eine Überschrift 2. Ordnung stehen sollte, wird dann eine kleinere Überschrift verwendet oder der Text fett markiert. Wichtig zu beachten ist auch der Workflow in Redaktionen. Texte werden oft in Word-Dokumenten geliefert und dann von den Redakteur*innen aus dem Dokument kopiert und in die Website eingefügt. Dabei muss die Textformatierung ggf. nachkorrigiert werden.

Warum ist eine wenig oder falsch strukturierte Seite problematisch?

Screenreader-Nutzende haben verschiedene Wege, um sich auf einer Website zu orientieren. Ein Screenreader ist eine Software, die Inhalte der Website nicht-visuell wiedergibt, z.B. durch Sprachausgabe. Screenreader werden u.a. von Menschen mit einer Sehbehinderung verwendet.

Der mit Abstand am häufigsten genutzte Weg ist die Orientierung via Überschriften. Im WebAIM Screen Reader User Survey gaben 67,7% der Befragten an, dass sie auf langen Seiten anhand der Überschriften durch die Seite navigieren. Dieser Wert ist über die Jahre übrigens sehr stabil. 

Nicht für alle Probleme rund um die Informationsstruktur haben wir bislang Lösungen gefunden. Aber mit ein paar Tricks können wir die Redaktion bei ihrer Arbeit unterstützen.

Auswahl der Überschriften einschränken

Unsere erste Amtshandlung in der Entwicklung besteht darin, für jedes Seiten-Template die Überschrift 1. Ordnung (Level H1) automatisch aus dem Seiten-Titel zu generieren. Damit stellen wir als Agentur sicher, dass jede Seite den Seiten-Titel nicht nur im <title> Tag bekommt, sondern auch eine H1 auf der Seite existiert. 

Für die Redaktion bleiben folglich die Überschriften 2. bis 6. Ordnung (Level H2 bis H6) übrig, um Inhalte auf den Seiten zu strukturieren. In den Editoren reduzieren wir die möglichen Überschriften und entfernen die H1 aus der Auswahl. Bei den meisten Websites stellen wir sogar nur die Level H2 bis H4 bereit. 

Screenshot aus dem TYPO3 Backend. Unter Überschriften ist der Bereich “Typ” hervorgehobenen. Dort gibt es die Auswahl zwischen Überschrift 2, Überschrift 3, Überschrift 4 und Verborgen.
Eine reduzierte Auswahl der Überschriften für die Redaktion

(Ein Exkurs: Es wäre aus Barrierefreiheits-Sicht kein Fehler, auf einer Seite mehrmals eine H1 zu vergeben. Jedoch arbeiten wir nach dem Prinzip, dass der Bedarf nach einer neuen H1 ein Hinweis ist, dass es sich um ein neues Thema handelt. Im Kontext einer Website empfehlen wir, eher eine neue Seite anzulegen. Oft sind sind die verschiedenen Themen dann auch schneller über das Hauptmenü der Website zu finden.)

Darstellung und Semantik der Überschriften trennen 

In einigen Projekten geben wir die Möglichkeit, bei den Überschriften zwischen dem semantischen und dem dargestellten (visuellen) Level zu unterscheiden. Damit reagieren wir unter anderem auf die Begebenheit, dass Redakteur*innen durchaus auch nach ästhetischen Gesichtspunkten die Überschriften bearbeiten. 

Im Screenshot sehen wir, wie eine Seite im CMS Neos im Backend bearbeitet wird. Ausgewählt ist eine Überschrift mit den dazugehörigen Einstellungen. Als semantisches Level ist die H2 gewählt und wird im HTML als H2 gesetzt. Das dargestellte Level ist eine H4 und damit wird der Stil einer H4 angewendet. Das HTML sieht im Ergebnis so aus: <h2 class=”copy-h4”>Ihr Aufgabenbereich</h2>.

Screenshot im Neos Backend. Im Inhaltsbereich ist eine Überschrift markiert. Im Inspektor ist ein Bereich hervorgehoben, dort steht beim dazugehörigen Feld “Semantisches Level”: “H2” und neu bei “Dargestelltes Level”: “H4”. Die Überschrift im Inhaltsbereich hat eine kleinere Schrift.
Darstellung und Semantik einer Überschrift getrennt einstellen

Fest verbaute Überschriften-Levels mitteilen

Als Entwickler*innen sollten wir unser Wissen zu den Komponenten, also die Details der Umsetzung, für die Redaktion explizit mitteilen und, dass so nah am Element wie möglich.

Eine Option ist ein extra Hinweis am Namen der Komponente. In diesem Beispiel haben wir einen Bühnen-Element im CMS Typo3, bei dem der Titel der Seite automatisch als H1 verbaut ist. Die Redaktion wird nun direkt beim Bearbeiten der Bühne daran erinnert, dass sie selbst keine H1 zu setzen braucht. 

Screenshot aus dem TYPO3 Backend. An der Komponente “Bühne” steht der hervorgehobene Hinweis “Der Seitentitel wird automatisch als H1 genutzt”.
Hinweis zur Verwendung der Überschrift 1. Ordnung direkt an der Inhalts-Komponente

Eine weitere Option ist es, den Platzhalter-Text für einen Hinweis zu verwenden. Hier sehen wir ein Akkordeon im Neos-Backend. In Neos kann man im sogenannten Inline-Editor direkt in der Seite Inhalte bearbeiten. Damit kann man sich die Platzhalter-Funktion wie sonst bei Inputs zu Nutze machen. Unser Akkordeon verwendet eine H3 für die Titel und darauf wird direkt beim Bearbeiten hingewiesen. 

Screenshot aus dem Neos Backend. Hervorgehoben ist der Platzhaltertext für Überschriften. Im Platzhalter steht “Titel eingeben (H3)”.
Hinweis zum Überschriften-Level an der Inhalts-Komponente Akkordeon

Die richtigen Alternativtexte

Alternativtexte ermöglichen es, dass Nicht-Text-Inhalte wie z.B. Bilder, Grafiken oder Gifs für Menschen erfahrbar werden, die diese nicht sehen können. Screenreader übermitteln den hinterlegten Alternativtext über Sprachausgabe, Braille-Tastatur und Text. 

Bei der korrekten Formulierung unterstützen

Meist wissen Redaktionsteams, dass sie Alternativtexte setzen müssen, ihnen fehlen aber oft die Kenntnisse, wie ein Alternativtext geschrieben wird. Social Media-Plattformen, wie z.B. Twitter unterstützen, indem sie an der Stelle, wo der Alternativtext eingefügt wird, darüber informieren wozu ein Alternativtext dient und was Autor*innen bei der Formulierung beachten sollten.

Screenshot von Twitter. Bild zeigt die Ansicht, wie eine Beschreibung in Twitter hinzugefügt wird. Unter dem Feld “Beschreibung” ist ein Link “Was ist Alternativtext?”. Der Link ist hervorgehoben. Von dort weist ein Pfeil auf den Text “Du kannst deinen Fotos eine Beschreibung hinzufügen, die manchmal als Alternativtext bezeichnet wird. Dadurch werden sie auch z. B. für blinde oder sehbehinderte Nutzer zugänglich. Eine gute Beschreibung ist kurz gefasst, stellt aber treffend und ausreichend präzise dar, was deine Fotos zeigen, sodass der Kontext verständlich wird.”
Erläuterung zum Alternativtext bei Twitter

Insbesondere, wenn Personen in der Redaktion unregelmäßig arbeiten und es häufig Wechsel beim Personal gibt, ist so eine Unterstützung auch im CMS sinnvoll. Die Hilfe kann als Platzhaltertext, Erläuterungstext oder mit verlinkten Hilfen erfolgen.

Screenshot vom TYPO3-Backend. Das Feld für den Alternativtext wird angezeigt. Unter dem Label der Hinweis: "Bilder müssen Textalternativen haben, die die Informationen oder Funktionen des Bildes beschreiben. Diese Feld sollte nur für rein dekorative Bilder leer sein."
Erläuterung zum Alternativtext in einem Typo3-Projekt

Einheitliche Begriffe verwenden

Ein weiterer Schritt, um die Redaktion zu unterstützen, ist die korrekte, einheitliche und am besten allgemeingültige Bezeichnung der Felder im Backend. Twitter nutzt einmal den Linktext “Beschreibung hinzufügen” und auf dem folgenden Screen “Was ist ein Alternativtext?”.

Zwei Screenshots von Twitter, in denen ein Post angelegt und eine Beschreibung hinzugefügt wird. Im ersten Bild ist der Link “Beschreibung hinzufügen” markiert. Im zweiten Bild ist der Link “Was ist Alternativtext?” markiert. Zwischen beiden Markierungen ist ein Pfeil.
Gegenüberstellung der nacheinanderfolgenden Screens bei Twitter

Solche Sprünge in der Wortwahl verunsichern und können dazu führen, dass Personen komplett auf eine Eingabe verzichten. Auch Angaben im Backend des CMS sind häufig sehr viel technischer, in einer anderen Sprache oder aufgrund von Voreinstellungen ganz anders als das, was in der Kommunikation verwendet wird.

Zu Alternativtexten verpflichten

Wenn wir das Redaktionsteam auf fehlende Alternativtexte hinweisen, bekommen wir oft die Antwort, dass sie schlicht vergessen wurden. Eine naheliegende Lösung dafür ist, den Alternativtext als verpflichtendes Element vorzusehen. Sobald die Redaktion ein Bild auf eine Seite einsetzt, kann das Speichern verhindert werden und ein Hinweis erscheint, dass die betreffende Eigenschaft erforderlich ist.

Screenshot vom Neos Backend. Im Inhaltsbereich ist ein Bild. Rechts im Inspektor zeigt ein Pfeil auf das Feld “Alternativer Text” und dem rot hervorgehobenen Tooltip “Diese Eigenschaft ist erforderlich”.
In einem Neos-Projekt wird der Alternativtext als erforderliches Feld markiert

(Exkurs: Sollte der Alternativtext zentral im Medienbereich gepflegt werden, ist so eine Verpflichtung auch möglich. Jedoch sollten Alternativtexte im abhängig vom Kontext sein und damit direkt an der Stelle gepflegt werden, an der das Bild jeweils eingesetzt wird. Das gleiche Bild an verschiedenen Stellen einer Website genutzt, kann andere Alternativtexte verlangen.)

Die Verpflichtung zu Alternativtexten hat auch Nachteile. Laut der Web Content Accessibility Guideline (WCAG) 2.1 braucht nicht jedes Bild einen Alternativtext (WCAG-Erfolgskriterium 1.1.1. Non-text Content). U.a. kann bei dekorativen Bildern auf den Alternativtext verzichtet werden. Daher sollte, bevor eine Verpflichtung gesetzt wird, die Art und Implementierung der Bilder auf der Website geprüft werden. Andererseits gaben in einer Umfrage des Deutschen Blinden- und Sehbehindertenverband e.V. zu Alternativtexten in Sozialen Medien (welche sich jedoch von Bildern auf Websites unterscheiden) 69% der Befragten an, dass grundsätzlich jedes Bild auf Facebook, Instagram und Twitter eine Bildbeschreibung haben soll.

Ein Beispiel wo Richtlinie und Alltag auseinander gehen.

Der zweite Nachteil einer Verpflichtung ist, dass die Redaktion dadurch gestresst werden kann und dann z.B. die Bildunterschrift in den Alternativtext kopiert oder nichtssagende Alternativtexte pflegt. Eine Entscheidung für die Verpflichtung muss mit der Redaktion besprochen werden, damit keine Frustration und falsche Erwartungen entstehen. Als ein Kompromiss kann z.B. ein Hinweis auf den Alternativtext erfolgen, aber ein Speichern ohne Alternativtext trotzdem ermöglicht werden.

Erwartbares Verhalten vorsehen

Ein weiteres Thema, das zu fehlerhaften Alternativtexten führt, ist dass der Redaktion die Auswirkungen ihrer Arbeit nicht bewusst ist oder, dass das CMS kein erwartbares Verhalten zeigt. Wenn wir Schulungen zu Systemen machen, die von anderen Teams eingerichtet wurden, fällt immer wieder auf, dass die Programmierung Fallbacks (Alternativlösungen) einbaut, die zu Barrieren führen können. So wurde z.B. in einem CMS bei nicht ausgefülltem Alternativtext automatisch der Titel der Bilddatei eingesetzt. Ein Dateititel ist kein korrekter Alternativtext. Ein leerer Alternativtext im Backend sollte zu einem leeren Alt-Attribut führen. Denn dieses signalisiert den Nutzenden, dass es sich um ein dekoratives Bild handelt. Auch wenn die Hilfe gut gemeint ist, führt sie zu mehr Barrieren.

Wissen teilen

Digitale Barrierefreiheit lässt sich nur in der Zusammenarbeit aller Teams bewerkstelligen. Im Austauschen der verschiedenen Disziplinen können wir Menschen dazu befähigen ihre Arbeit besser, schneller, selbständiger und einfacher zu gestalten. Dabei hilft es an Aufgaben zu erinnern, sie zu erläutern, Wissen zu vermitteln sowie die Prozesse zu vereinfachen.

Gigi Entienne schrieb in ihrem Artikel über Strategien der Barrierefreiheit “Accessibility ist not necessarily about doing more work, it’s often about making better decisions”. Mit wenigen Anpassungen entlastet das Programmierteam die Redaktion und kann dabei helfen bessere Entscheidungen zu treffen und eine barrierefreie digitale Welt zu gestalten.

Weiterführende Links

Co Authors :