Barrierefreiheit für Redakteurinnen und Redakteure

Ein erheblicher Teil aller Barrieren entsteht nicht im Code, sondern im Redaktionssystem – durch Überschriften, die nur fett formatiert sind, Bilder ohne Alternativtext, Linktexte wie „mehr erfahren“ und Tabellen ohne Kopfzeile. Diese Fehler kann keine Entwicklerin für dich beheben, weil sie mit jedem neuen Beitrag neu entstehen. Sechs Gewohnheiten decken den größten Teil davon ab.

Diese Seite sortiert das Wissen dieser Website nach Zuständigkeit: Was liegt tatsächlich in der Hand der Redaktion, was gehört der Entwicklung, und wo endet die Verantwortung? Sie erklärt die Themen nicht neu, sondern zeigt, welche davon dich betreffen – und verlinkt jeweils dorthin, wo es ausführlich steht.

Das Wichtigste in Kürze

• Überschriften sind Struktur, kein Schriftgrad. Nutze die Formatvorlagen des Editors, nie „fett und größer“.
• Jedes inhaltstragende Bild braucht einen Alternativtext, jedes dekorative ein leeres. Beides ist eine redaktionelle Entscheidung.
• Linktexte müssen aus sich heraus verständlich sein – „mehr erfahren“ verletzt WCAG 2.4.4 (Stufe A).
• Tabellen brauchen eine Kopfzeile und dürfen nicht zum Layouten dienen.
• Videos brauchen Untertitel, Audio ein Transkript. Automatische Untertitel sind ein Entwurf, keine Lösung.
• Bedeutung darf nie nur über Farbe transportiert werden – „die roten Felder“ ist keine Angabe.
• Ein PDF ist selten die zugänglichere Wahl. Wo HTML möglich ist, ist HTML besser.
• Nicht deine Aufgabe: Fokusringe, ARIA, Tastaturbedienung, Kontrastwerte der Designvorlage.

Warum die Redaktion der wirksamste Hebel ist

Die jährliche WebAIM-Auswertung von einer Million Startseiten findet seit Jahren dieselben fünf häufigsten Fehler: zu geringer Kontrast, fehlende Alternativtexte, leere Links, fehlende Formularbeschriftungen und fehlende Dokumentsprache. Drei davon entstehen regelmäßig im Redaktionssystem, nicht im Template.

Das hat eine unangenehme und eine angenehme Seite. Die unangenehme: Eine einmal barrierefrei gebaute Website bleibt es nicht von selbst – jeder neue Beitrag kann sie wieder kaputt machen. Die angenehme: Diese Fehler brauchen keine Entwicklungszeit, keinen Ticket-Workflow und kein Budget. Sie brauchen sechs Gewohnheiten.

Die sechs Gewohnheiten

1. Überschriften über die Formatvorlage setzen. Der Editor bietet „Überschrift 2“, „Überschrift 3“ und so weiter an. Genau eine H1 je Seite, keine Ebene überspringen. Was dahintersteckt, steht unter Überschriften-Hierarchie; geprüft wird es über 1.3.1 Info und Beziehungen. Der Grund ist praktischer, als er klingt: Über 70 Prozent der Screenreader-Nutzenden navigieren zuerst über Überschriften – deine Überschriftenliste ist ihr Inhaltsverzeichnis.

2. Alternativtexte schreiben, nicht Dateinamen stehen lassen. Ein Alt-Text beschreibt nicht das Bild, sondern seine Funktion an dieser Stelle. Dasselbe Foto braucht in einem Produktkatalog einen anderen Text als in einem Reisebericht. Die Entscheidungslogik steht unter Alt-Texte richtig schreiben, und für Zweifelsfälle gibt es die Alt-Text-Entscheidungshilfe.

3. Linktexte aus sich heraus verständlich formulieren. „Mehr erfahren“ steht in einer Linkliste zehnmal untereinander und sagt nichts. 2.4.4 Linkzweck im Kontext verlangt, dass der Zweck erkennbar ist. Praktischer Test: Lies nur die Linktexte deines Beitrags hintereinander – ergeben sie eine sinnvolle Liste?

4. Tabellen als Daten behandeln. Eine Tabelle braucht eine Kopfzeile, und sie ist kein Layoutwerkzeug. Wie das im Detail aussieht, steht unter Tabellen semantisch aufbauen. Wenn dein Editor keine Kopfzeile anbietet, ist das ein Ticket an die Entwicklung – und zwar ein berechtigtes.

5. Medien mit Textalternative veröffentlichen. Videos brauchen Untertitel, reine Audiobeiträge ein Transkript. Automatisch erzeugte Untertitel sind ein guter Entwurf und eine schlechte Veröffentlichung: Namen, Fachbegriffe und Zahlen sind genau die Stellen, an denen sie falsch liegen. Die Anforderungen im Einzelnen stehen unter Untertitel, Transkripte & Audiodeskription.

6. Verständlich schreiben. Kurze Sätze, aktive Formulierungen, Fachbegriffe beim ersten Auftauchen erklärt. Das ist Einfache Sprache, und sie kostet kein Budget – siehe Kognitive Barrierefreiheit. Die stark regulierte Leichte Sprache ist etwas anderes und wird eingekauft, nicht nebenbei geschrieben.

Was ausdrücklich nicht deine Aufgabe ist

Diese Abgrenzung erspart viele unnötige Diskussionen im Team:

• Kontrastwerte kommen aus der Designvorlage. Wenn die Sekundärfarbe durchfällt, ist das kein Redaktionsfehler – siehe Farbkontraste.
• Fokusringe, Tastaturbedienung und ARIA sind Entwicklungsthemen.
• Die Barrierefreiheitserklärung verantwortet die Organisation, nicht die Redaktion – auch wenn sie oft von dort geschrieben wird.
• Cookie-Banner und eingebettete Fremdsysteme liegen fast nie in deiner Hand. Melden reicht.

Was dagegen sehr wohl deine Aufgabe ist und gern vergessen wird: Fremdsprachige Wörter auszeichnen. Ein englischer Begriff mitten im deutschen Text wird sonst mit deutscher Aussprache vorgelesen – regelt 3.1.2 Sprache von Teilen. Die meisten Editoren bieten dafür eine Funktion, die niemand kennt.

So prüfst du deinen eigenen Beitrag

Fünf Minuten pro Beitrag, ohne Werkzeug:

1. Die Überschriftenstruktur ansehen. Viele Editoren haben eine Gliederungsansicht; sonst hilft der Struktur-Check. Ergibt die Folge ein Inhaltsverzeichnis?
2. Nur die Linktexte lesen. Ist jeder für sich verständlich?
3. Jedes Bild ansehen und fragen: Trägt es Information? Wenn ja, steht sie im Alt-Text? Wenn nein, ist der Alt-Text leer?
4. Nach Farbangaben suchen. Kommt „grün markiert“, „siehe rechts“ oder „der rote Kasten“ im Text vor, fehlt eine zweite Kennzeichnung – 1.4.1 Benutzung von Farbe.
5. Die Tabellen prüfen. Kopfzeile gesetzt? Keine verbundenen Zellen?

Wer einmal im Quartal fünf Minuten mehr investiert, hört sich einen Beitrag mit NVDA an. Das verändert die Schreibgewohnheiten nachhaltiger als jede Checkliste.

Häufiger Fehler in der Praxis

Die Überschriftenebene nach Optik wählen. „H3 sieht hier besser aus“ ist der häufigste Strukturfehler in Redaktionssystemen überhaupt. Die Größe gehört ins CSS, nicht in die Ebenenwahl.

Alt-Texte mit Schlagwörtern füllen. Ein Alt-Text ist keine SEO-Fläche. Was für Suchmaschinen zählt, ist derselbe gut geschriebene Satz – siehe Bild-SEO.

Leere Absätze als Abstand. Fünf leere Absätze zwischen zwei Kapiteln werden fünfmal als „leer“ angesagt.

PDFs hochladen, wo eine Seite gereicht hätte. Ein PDF ist ein zusätzliches Format mit eigenen Anforderungen; wenn es sein muss, dann nach PDF-Barrierefreiheit und aus einem sauberen Office-Dokument.

Häufige Fragen

Ich kann im Editor kein HTML bearbeiten – geht das trotzdem?

Ja, für alles auf dieser Seite. Überschriftenvorlagen, Alt-Text-Feld, Linktext, Tabellenkopfzeile und Untertitel sind Standardfunktionen jedes gängigen Systems. Wenn eine davon fehlt, ist das ein berechtigtes Ticket an die Entwicklung.

Muss wirklich jedes Bild einen Alt-Text haben?

Jedes Bild braucht ein alt-Attribut – aber nicht jedes einen Text. Dekorative Bilder bekommen ein leeres alt="", damit der Screenreader sie überspringt. Die Frage ist also nicht „Text oder nicht“, sondern „trägt dieses Bild Information“.

Wer haftet, wenn ein Beitrag nicht barrierefrei ist?

Rechtlich adressieren BFSG und BITV die Organisation, nicht einzelne Beschäftigte. Praktisch heißt das: Die Redaktion braucht Schulung und Zeit, keine Schuldzuweisung. Dieser Abschnitt erklärt die Rechtslage, ersetzt aber keine Rechtsberatung.

Reicht ein automatisches Prüfwerkzeug?

Für einen Teil. Werkzeuge finden fehlende Alt-Texte, sie können aber nicht beurteilen, ob ein Alt-Text die richtige Information trägt oder ob die Überschriftenfolge sinnvoll ist. Die Grenzen stehen unter Prüfwerkzeuge im Vergleich.

Verwandte Themen

• Barrierefreiheit im UX- und UI-Design – die Rolle, die dir die Vorlagen liefert
• Barrierefreiheit im Projekt steuern – wer Redaktionszeit für Barrierefreiheit einplant
• Cheat-Sheets & Checklisten – zum Ausdrucken neben den Bildschirm
• Wie Screenreader-Nutzer surfen – warum Überschriften so viel Gewicht haben

Quellen

• The WebAIM Million – die fünf häufigsten Fehler auf einer Million Startseiten
• Writing for Web Accessibility – die redaktionellen Grundregeln (W3C WAI)
• WebAIM Screen Reader User Survey #10 – Navigationsverhalten, u. a. Überschriften