muse case IconEyes IconWinking Face IconFire IconRock IconAlien Icon
  • EN
muse case IconEyes IconWinking Face IconFire IconRock IconAlien Icon
BlogMai 15, 2026

Barrierefreiheit im Content: Die häufigsten Accessibility Fehler in der redaktionellen Arbeit

Person working focused at a desk in front of a monitor

Viele Barrieren entstehen nicht erst im Code. Sie entstehen bereits dort, wo Inhalte geplant, geschrieben, gepflegt und freigegeben werden: bei unklaren Überschriften, fehlenden oder wenig hilfreichen Alternativtexten, nichtssagenden Linktexten, Videoformaten ohne verlässliche Untertitel oder CMS-Workflows, die visuell funktionierende, aber semantisch schwache Strukturen zulassen.

Das ist relevant, weil Accessibility auch redaktionelle Entscheidungen betrifft: Welche Struktur bekommt ein Inhalt? Wie wird ein Bild beschrieben? Ist ein Link ohne visuellen Kontext verständlich? Wird ein Video so veröffentlicht, dass es auch ohne Ton nutzbar ist? Genau an diesen Punkten entscheidet sich, ob Inhalte für alle Menschen zugänglich sind oder ob vermeidbare Barrieren entstehen.

Der WebAIM Million Report 2026[1] macht das Ausmaß solcher Probleme sichtbar. WebAIM untersuchte im Februar 2026 die Startseiten der Top 1.000.000 Websites mit der WAVE Accessibility Engine. Dabei wurden nur automatisiert erkennbare Barrieren berücksichtigt; die Ergebnisse zeigen daher nicht alle Accessibility-Probleme, liefern aber einen belastbaren Überblick über häufige Muster.

53,1 % der untersuchten Startseiten hatten fehlende Alternativtexte für Bilder. 15,2 % enthielten mehrdeutige Linktexte wie „mehr“, „weiter“ oder „hier klicken“. 41,8 % übersprangen Überschriftenebenen, und 7,5 % der Seiten hatten gar keine Überschriften.[1] Ein Teil dieser Probleme entsteht in Templates, Komponenten oder Designsystemen. Viele dieser Fehler spiegeln jedoch redaktionelle Praxis wider, welche Texte Autorinnen und Autoren eintragen, welche Inhalte Redaktionen freigeben und welche Qualitätsprüfungen vor der Veröffentlichung tatsächlich stattfinden.

Barrierefreiheit sollte deshalb nicht erst am Ende eines Publishing-Prozesses geprüft werden. Sie gehört in die redaktionelle Arbeit selbst, in Briefings, CMS-Felder, Freigabeprozesse, Bildauswahl, Videoproduktion und Qualitätssicherung. Accessibility wird robuster, wenn Inhalte von Anfang an strukturiert, beschrieben und für unterschiedliche Nutzungssituationen aufbereitet werden.

Was gilt als Accessibility-Problem in der Content-Erstellung?

Für diesen Artikel bezeichnen wir als Content-Accessibility-Problem jede redaktionelle Entscheidung, die Informationen schwerer auffindbar, verständlich, navigierbar oder nutzbar macht. Das kann in der Struktur eines Inhalts liegen, in der Formulierung, in der Beschreibung von Medien oder im Publishing-Workflow.

Damit unterscheidet sich dieser Fokus von einem technischen Accessibility-Audit. Ein technisches Audit prüft vor allem Implementierungsdetails: Markup, Tastaturbedienung, Fokusführung, ARIA-Verwendung, Kontraste, Komponentenverhalten oder die Interaktion mit Browsern und assistiven Technologien. Dieser Artikel betrachtet stattdessen die Stellen, die Content Creators, Redaktionen, Content Designer, Marketing-Teams, Technical Writer und CMS-Verantwortliche direkt beeinflussen.

Typische Content-Accessibility-Probleme sind zum Beispiel:

  • Seitentitel, die die Seite nicht eindeutig identifizieren. Ein Titel wie „Details“ oder „Neue Seite“ hilft weder in Browser-Tabs noch in Suchergebnissen oder Screenreader-Kontexten. WCAG 2.4.2 verlangt, dass Seitentitel Thema oder Zweck der Seite beschreiben.[2]
  • Überschriften, die fehlen, vage bleiben oder nur visuelles Styling erzeugen. Überschriften strukturieren Inhalte. Sie ermöglichen Orientierung, schnelles Scannen und Navigation über assistive Technologien. Wenn Text nur groß und fett formatiert wird, aber keine semantische Überschrift ist, geht diese Struktur verloren. WCAG 1.3.1 verlangt, dass visuell vermittelte Struktur programmatisch bestimmbar oder textlich verfügbar ist; WCAG 2.4.6 verlangt aussagekräftige Überschriften und Labels.
  • Linktexte, die das Ziel oder die Handlung verschleiern. „Hier klicken“, „mehr“ oder „weiter“ funktionieren oft nur für Menschen, die den visuellen Kontext problemlos erfassen. Besser sind Linktexte, die das Ziel oder die Aktion benennen, etwa „Preisliste als PDF herunterladen“ oder „Mehr über barrierefreie Bildbeschreibungen lesen“. WCAG 2.4.4 verlangt, dass der Zweck eines Links aus dem Linktext oder seinem programmatisch bestimmbaren Kontext erkennbar ist.[3]
  • Bildbeschreibungen, die fehlen, redundant sind oder am Zweck des Bildes vorbeigehen. Ein guter Alternativtext beschreibt nicht einfach jedes sichtbare Detail. Er vermittelt die Information, die das Bild im jeweiligen Kontext trägt. Ein dekoratives Bild braucht keine inhaltliche Beschreibung; eine Infografik, ein Produktbild oder ein erklärender Screenshot dagegen schon. WCAG 1.1.1 verlangt Textalternativen für nicht-textliche Inhalte, die denselben Zweck erfüllen; rein dekorative Inhalte sollen so umgesetzt werden, dass assistive Technologien sie ignorieren können.[4]
  • Videos und Audioinhalte, die ohne passende Captions, Transkripte oder Medienalternativen veröffentlicht werden. Captions sind nicht nur für gehörlose oder schwerhörige Menschen relevant. Sie helfen auch in lauten Umgebungen, bei ausgeschaltetem Ton, beim schnellen Nachlesen oder beim Erfassen komplexer Inhalte. Für voraufgezeichnete Audio- oder Videoinhalte verlangt WCAG 1.2.1 geeignete Alternativen[5]; für voraufgezeichnete Audioinhalte in synchronisierten Medien verlangt WCAG 1.2.2 Captions[6].
  • Anweisungen, die Vorwissen voraussetzen oder wichtige Anforderungen auslassen. Hinweise wie „Klicken Sie auf den grünen Button rechts“ sind problematisch, wenn Farbe oder Position die einzige Orientierung liefern. Ebenso kritisch sind Formulare, die ein bestimmtes Format erwarten, dieses Format aber nicht erklären. WCAG 1.3.3 verlangt, dass Anweisungen nicht ausschließlich auf sensorischen Merkmalen wie Farbe, Form, Größe, Position oder Klang beruhen[7]; WCAG 3.3.2 verlangt Labels oder Anweisungen, wenn Inhalte Benutzereingaben erfordern.[8]
  • Dichte, jargonlastige Sprache, die unnötig hohe kognitive Anforderungen stellt. Nicht jeder schwere Satz ist automatisch ein WCAG-Verstoß. Trotzdem kann komplexe, unklare oder voraussetzungsreiche Sprache für Menschen mit kognitiven und Lernbehinderungen eine echte Barriere sein. Die W3C-COGA-Guidance beschreibt solche Anforderungen als wichtigen Teil zugänglicher Inhalte, auch wenn diese Empfehlungen über die formalen WCAG-Konformitätsanforderungen hinausgehen.[9]

Content definiert Struktur, Orientierung, Anweisungen, Bedeutung und oft auch den eigentlichen Zweck einer Seite. Das Markup kann korrekt sein. Die Komponenten können funktionieren. Der Publishing-Workflow kann Nutzerinnen und Nutzer trotzdem ausschließen, wenn Inhalte vage, irreführend, unvollständig oder nur für eine bestimmte Wahrnehmungsweise verständlich sind.

Titel, Überschriften und Dokumentstruktur

Seitentitel und Überschriften sind keine Formatierungsdetails. Sie entscheiden mit darüber, ob Menschen eine Seite schnell einordnen, überfliegen und gezielt nutzen können.

Ein guter Seitentitel macht klar, auf welcher Seite man sich befindet, in Browser-Tabs, im Verlauf, in Suchergebnissen und im Screenreader-Kontext. Gute Überschriften zeigen, wie ein Inhalt aufgebaut ist. Sie helfen beim Scannen, beim Springen zu relevanten Abschnitten und beim Verstehen der inhaltlichen Hierarchie.

Gerade deshalb entstehen hier viele vermeidbare Barrieren. Typische Beispiele sind generische Titel wie „Overview“, „Resources“ oder „Update“, Überschriften, die zwar interessant klingen, aber das Thema nicht benennen, oder Zwischenüberschriften, die fehlen, weil die Seite visuell „übersichtlich genug“ wirkt. Ebenso problematisch ist Text, der im CMS nur fett oder größer formatiert wird, statt als echte Überschrift ausgezeichnet zu sein. Wiederholen sich Überschriften wie „Weitere Informationen“ oder „Details“ mehrfach auf derselben Seite, verliert die Gliederung ebenfalls an Wert.

Das Problem ist nicht nur technisches Markup. Es ist Informationsarchitektur. Eine Überschrift ist ein Versprechen: Sie sagt, was im nächsten Abschnitt kommt. Wenn sie vage, austauschbar oder irreführend ist, wird eine Seite schwerer navigierbar, auch dann, wenn das HTML formal korrekt ist.

Die praktische Regel ist einfach: Titel identifizieren die Seite. Überschriften beschreiben den Inhalt und die Struktur. Wer nur Titel und Überschriften überfliegt, sollte trotzdem verstehen, worum es geht, welche Abschnitte es gibt und wo die gesuchte Information wahrscheinlich steht.

Linktexte

Linktexte sind kleine Texte mit großer Verantwortung. Sie sagen Nutzerinnen und Nutzern, wohin ein Link führt, welche Aktion folgt und ob sich das Ziel für sie lohnt. Genau deshalb sind sie keine dekorative Mikrocopy, sondern ein zentraler Teil der Orientierung.

Trotzdem entstehen in redaktionellen Workflows immer wieder mehrdeutige Links:

  • „click here“
  • „read more“
  • „learn more“
  • „more“
  • verlinkte Bilder ohne brauchbare Textalternative

Solche Formulierungen funktionieren meist nur, wenn der visuelle Kontext mitgelesen wird: die Card, der Absatz davor, das Bild daneben. Das ist fragil. Screenreader-Nutzende können sich Links als Liste ausgeben lassen und sie außerhalb des sichtbaren Layouts durchgehen. Menschen mit Sprachsteuerung sind auf benennbare Linkziele angewiesen. Und auch alle, die eine Seite nur schnell scannen, profitieren davon, wenn Links ihr Ziel klar benennen.

Gute Linktexte müssen nicht lang sein. Sie müssen nur Bedeutung tragen. „Accessibility-Checkliste herunterladen (PDF, 2 MB)“ ist deutlich hilfreicher als „Download here“. „Mehr über barrierefreie Bildbeschreibungen lesen“ ist stärker als „Mehr erfahren“.

Die praktische Regel: Ein Link sollte auch ohne den umgebenden Absatz verständlich bleiben. Nicht jeder Link muss alle Details enthalten, aber Nutzerinnen und Nutzer sollten vor dem Aktivieren wissen, was sie erwartet.

Das macht gute Linktexte zu mehr als einer Compliance-Frage. Sie verbessern Orientierung, Vertrauen und Aufgabenerfolg — für Menschen mit Behinderungen und für alle anderen ebenfalls.

Alternativtexte für Bilder

Alternativtext wird in vielen Workflows wie ein Pflichtfeld behandelt: ausfüllen, speichern, veröffentlichen. Das Ergebnis sind oft Texte, die formal vorhanden sind, aber wenig helfen. Guter Alt-Text entsteht nicht dadurch, dass ein Bild irgendwie beschrieben wird. Er entsteht, wenn klar ist, welche Aufgabe das Bild im Inhalt erfüllt.

Das Grundprinzip ist einfach: Textalternativen sollen die Information oder Funktion ersetzen, die sonst nur über das Bild zugänglich wäre. Ein dekoratives Bild muss nicht beschrieben werden. Ein informatives Bild braucht die relevante Aussage. Ein funktionales Bild, etwa ein verlinktes Icon, braucht ein verständliches Linkziel. Und bei komplexen Darstellungen wie Diagrammen oder Infografiken reicht ein kurzer Alt-Text meist nicht aus; die eigentliche Aussage gehört zusätzlich in den umgebenden Text, in eine Tabelle oder in eine ausführlichere Beschreibung.

In der Praxis scheitert das selten an böser Absicht. Häufig fehlt nur die redaktionelle Entscheidung. Autorinnen und Autoren beschreiben, was auf dem Bild zu sehen ist, statt zu klären, warum es an dieser Stelle steht. Stockfotos bekommen unnötige Beschreibungen und erzeugen Rauschen. Diagramme werden mit einem Einzeiler veröffentlicht, der die Kernaussage auslässt. Verlinkte Bilder übernehmen Dateinamen, leere Platzhalter oder generische Begriffe. CMS-Felder behandeln alle Bilder gleich, obwohl ein dekoratives Hero-Bild, ein Produktfoto, ein Icon-Link und eine Infografik unterschiedliche Aufgaben haben.

Der WebAIM Million Report 2026 zeigt, wie verbreitet diese Probleme weiterhin sind. Auf den untersuchten Startseiten hatten 16,2 % aller Bilder keinen Alternativtext. Weitere 10,8 % der vorhandenen Alternativtexte wurden als fragwürdig oder repetitiv eingestuft. Besonders kritisch: 45 % der Bilder ohne Alternativtext waren verlinkt. In solchen Fällen fehlt oft nicht nur die Bildbeschreibung, sondern auch ein verständlicher Name für das Linkziel.

Die bessere redaktionelle Frage lautet daher nicht: „Was sieht man auf dem Bild?“ Sondern: Was würde fehlen, wenn dieses Bild nicht sichtbar wäre?

Wenn nichts fehlt, ist das Bild wahrscheinlich dekorativ. Wenn etwas fehlt, muss die Textalternative genau diese Bedeutung transportieren.

Multimedia-Accessibility ist Publishing-Arbeit

Video, Webinare, Podcasts und Social Clips sind längst normale Content-Formate. Damit gehört auch ihre Barrierefreiheit in den normalen Publishing-Prozess. Captions, Transkripte und Beschreibungen wichtiger visueller Informationen sind keine nachträgliche Veredelung. Sie entscheiden darüber, ob ein Inhalt überhaupt vollständig zugänglich ist.

Die häufigsten Fehler entstehen nicht erst im Player, sondern im Workflow. Podcasts werden ohne Transkript veröffentlicht. Videos bekommen automatisch erzeugte Captions, die niemand prüft. Sprecherwechsel, wichtige Geräusche oder relevante visuelle Informationen fehlen. Transkripte werden irgendwo verlinkt, aber nicht dort, wo Nutzerinnen und Nutzer sie erwarten würden. Oder sie geben nur das Gesprochene wieder und lassen aus, was im Bild passiert.

Gerade automatische Captions zeigen, warum Medien-Accessibility redaktionelle Qualitätssicherung braucht. Sie können ein guter Ausgangspunkt sein. Sie sind aber kein fertiges Ergebnis, solange sie nicht kontrolliert und korrigiert wurden. Fehler in Captions sind nicht nur Schönheitsfehler. Sie können Namen verfälschen, Fachbegriffe unkenntlich machen, Anweisungen verändern oder die Aussage eines Satzes ins Gegenteil drehen.

Transkripte verdienen denselben Stellenwert. Sie helfen nicht nur gehörlosen und schwerhörigen Menschen. Sie sind auch nützlich für Menschen, die lieber lesen, Inhalte schnell durchsuchen, Zitate finden, Fachbegriffe nachschlagen oder Medien ohne Ton nutzen möchten. WAI empfiehlt deshalb, Transkripte leicht auffindbar zu platzieren — idealerweise auf derselben Seite wie das Medium oder direkt darunter verlinkt.

Für Content Operations ist die Konsequenz klar: Captions und Transkripte gehören in die Veröffentlichungskriterien. Ein Video ist nicht „fertig“, wenn Schnitt, Thumbnail und Beschreibung stehen. Es ist erst veröffentlichungsreif, wenn auch die zugängliche Textversion des Inhalts vorhanden, korrekt und auffindbar ist.

Klare Hinweise und Plain Language senken die kognitive Belastung

Content-Accessibility endet nicht bei Screenreadern, Tastaturbedienung oder Medienalternativen. Sie hängt auch davon ab, ob Menschen Informationen schnell verstehen und sicher anwenden können.

Das betrifft nicht nur „einfache“ Inhalte. Gerade komplexe Themen brauchen klare Sprache, gute Reihenfolge und eindeutige Hinweise. WAI empfiehlt für verständliche Inhalte unter anderem kurze Sätze, kurze Textblöcke, eindeutige Formulierungen und eine Struktur, die den Zweck einer Seite schnell erkennbar macht. Plain-Language-Guidance von CDC und Digital.gov verfolgt denselben Gedanken: Inhalte sollten so geschrieben sein, dass Menschen sie beim ersten Kontakt finden, verstehen und verwenden können.

Für Content-Teams hat das direkte Folgen. Akronyme sollten bei der ersten Verwendung ausgeschrieben werden. Lange Prozessbeschreibungen gehören in einzelne Schritte, nicht in dichte Absätze. Anforderungen sollten vor der Eingabe erklärt werden, nicht erst in der Fehlermeldung. Beispiele helfen, wenn ein Format missverstanden werden kann. Und konkrete Verben sind meist besser als abstrakte Organisationssprache: „Reichen Sie den Antrag bis 15. Juni ein“ ist verständlicher als „Eine fristgerechte Einreichung ist erforderlich“.

Das ist besonders wichtig für Menschen mit kognitiven und Lernbehinderungen, für Menschen, die in einer zweiten Sprache lesen, und für Nutzerinnen und Nutzer unter Stress, Müdigkeit oder Zeitdruck. Es verbessert aber auch die Nutzung für alle anderen: Wer schneller versteht, macht weniger Fehler, bricht seltener ab und findet leichter zum nächsten Schritt.

Plain Language wird oft missverstanden. Sie bedeutet nicht, ein Thema künstlich zu vereinfachen oder Fachlichkeit zu entfernen. Sie bedeutet, unnötige Komplexität aus dem Ausdruck zu nehmen. Ein medizinischer Hinweis, eine rechtliche Bedingung oder eine technische Anleitung darf präzise bleiben. Sie sollte nur nicht schwerer verständlich sein, als der Inhalt es verlangt.

In Accessibility-Begriffen ist dichte Sprache deshalb mehr als eine Stilfrage. Sie kann zur Barriere werden, wenn Menschen Anweisungen, Fristen, Leistungen, Formulare oder Produktentscheidungen verstehen müssen. Klare Sprache ist keine Vereinfachung des Inhalts. Sie ist ein Teil davon, ob der Inhalt nutzbar ist.

Fazit

Barrierefreie Content-Erstellung ist keine Spezialdisziplin neben dem eigentlichen Schreiben. Sie gehört zum redaktionellen Handwerk: Menschen sollen Informationen finden, verstehen und sicher danach handeln können.

Deshalb verdienen Content-Entscheidungen dieselbe Aufmerksamkeit wie semantisches HTML oder Komponentenverhalten. Ein technisch sauberes Interface hilft wenig, wenn Titel vage bleiben, Links ihr Ziel verschleiern, Bilder ihre Bedeutung verlieren oder Medien nur für Menschen mit Ton und Bild vollständig zugänglich sind.

Der wichtigste Perspektivwechsel lautet: Accessibility wird nicht am Ende hinzugefügt. Sie entsteht dort, wo Inhalte geplant, strukturiert, beschrieben und veröffentlicht werden.

[object Object]

Flo Winkler

Software Engineer

Vorheriger & Nächster Artikel
get in touch

Überzeugt, dass wir die Richtigen für Ihr Projekt sind? Jetzt gemeinsam starten!

Contact form emoji illustration

Jetzt Anfrage starten

Kontaktieren Sie uns per Mail und wir werden uns umgehend bei Ihnen melden.

Art der Anfrage (optional)