Vor dem Start einer Website wird geprüft: Kontraste, Tastaturbedienung, Screenreader-Ausgabe, am Ende ein Bericht mit Befunden und Prioritäten. Geprüft wird dabei das Ergebnis. Das Werkzeug, mit dem dieses Ergebnis jeden Tag neu entsteht, steht selten im Prüfumfang. Dabei entscheidet die Redaktionsoberfläche mit jeder Meldung, jedem Produkttext und jeder neuen Landingpage darüber, ob die geprüfte Qualität hält oder still verfällt. Für genau diese Lücke gibt es ein eigenes Regelwerk: die Authoring Tool Accessibility Guidelines, kurz ATAG 2.0, seit dem 24. September 2015 eine Empfehlung des W3C (W3C). Sie stellen zwei Fragen an ein Redaktionssystem, und beide gehören auf den Tisch, bevor die EN 301 549 in einem Vergabeverfahren daran erinnert.
Das Wichtigste in Kürze
- Ein WCAG-Audit bewertet die ausgelieferte Seite. Das Redaktionssystem, das sie täglich neu befüllt, bleibt in der Regel außerhalb des Prüfumfangs.
- ATAG 2.0 besteht aus zwei Teilen mit zusammen 8 Prinzipien (W3C): Teil A betrifft die Bedienbarkeit der Redaktionsoberfläche, Teil B die Unterstützung barrierefreier Ergebnisse.
- Teil A ist ein Arbeitsplatzthema. Wer eine Redaktionsstelle besetzt, schuldet nach § 164 Absatz 4 eine behinderungsgerechte Einrichtung des Arbeitsplatzes samt Geräten, soweit ihm das zumutbar ist (SGB IX).
- Teil B ist ein Qualitätsthema: Pflichtfeld statt Freitext beim Alternativtext, geführte Überschriftenebenen, Kontrastwarnung im Farbwähler, Tabellenassistent mit Kopfzellen.
- Die EN 301 549 führt Autorenwerkzeuge in Kapitel 11.8 mit fünf Anforderungen von 11.8.1 bis 11.8.5 (EN 301 549) und bringt den Gedanken damit in die europäische Norm.
- Ein Teil der Leitplanken lässt sich per Erweiterung nachziehen, der Rest sitzt im Kern des Systems. Deshalb gehört die Frage in die Auswahl und nicht erst in die Nachbesserung.
Geprüft wird die Website, selten das Werkzeug
Der Ausgangsbefund ist bekannt: Auf 95,9 Prozent der untersuchten Startseiten fanden sich im Jahr 2026 maschinell erkennbare Verstöße gegen die WCAG (WebAIM Million), und 96 Prozent aller gefundenen Fehler fielen in nur sechs Kategorien (WebAIM Million) - zu geringer Textkontrast, fehlende Alternativtexte, leere Verweise, unbeschriftete Formularfelder, leere Schaltflächen und fehlende Sprachauszeichnung. Auffällig an dieser Liste ist, wo die Fehler entstehen. Es sind überwiegend keine Architekturfehler, sondern Entscheidungen, die in einem Eingabefeld getroffen werden: ein Bild ohne Beschreibung, ein Verweis mit dem Text mehr, eine Überschrift, die nur fett aussieht.
Deshalb greift ein einmaliger Prüfdurchlauf zu kurz. Eine Website, die im Frühjahr sauber war, kann nach einigen Wochen Redaktionsarbeit wieder Barrieren enthalten, ohne dass jemand im Team etwas falsch machen wollte. Was bei der Prüfung von Kundenportalen hinter dem Login für den Prüfumfang gilt, gilt hier für die Zeitachse: Der Prüfbericht beschreibt einen Zustand, das Redaktionssystem erzeugt einen Verlauf. Wer beides zusammenbringen möchte, muss das Werkzeug selbst betrachten - seine Oberfläche und die Leitplanken, die es der Redaktion anbietet.
Zwei Fragen, die im Auswahlverfahren fehlen
ATAG 2.0: zwei Teile, zwei Verantwortungen
ATAG 2.0 ist wie die WCAG aufgebaut: Prinzipien, Leitlinien, Erfolgskriterien und drei Konformitätsstufen von A bis AAA (W3C). Der Unterschied liegt im Gegenstand. Die WCAG beschreiben Inhalte, ATAG beschreibt das Werkzeug, mit dem Inhalte entstehen - vom Redaktionssystem über das Shop-Backend bis zum Newsletter-Editor, zum Formularbaukasten und zum Wiki im Intranet. Als Autorenwerkzeug gilt jede Software, deren Ausgabe später von anderen Menschen im Web gelesen wird. Das ist ein weiter Begriff, und er trifft in den meisten Unternehmen mehr Systeme als zunächst erwartet.
Die beiden Teile stehen nebeneinander und lösen unterschiedliche Probleme. Teil A umfasst vier Prinzipien und wendet die vertrauten Anforderungen auf die Oberfläche des Werkzeugs selbst an: wahrnehmbare Bearbeitungsansichten, bedienbare Bearbeitungsansichten, verständliche Bearbeitungsansichten und eine Benutzeroberfläche, die den geltenden Richtlinien folgt (W3C). Teil B umfasst ebenfalls vier Prinzipien und hat kein Gegenstück in den WCAG: Automatische Vorgänge sollen barrierefreie Inhalte erzeugen, Autoren sollen bei der Erstellung unterstützt werden, vorhandene Inhalte sollen sich verbessern lassen, und die Funktionen dafür sollen sichtbar im Arbeitsablauf liegen statt in einem Untermenü (W3C).
| Frage | ATAG Teil A | ATAG Teil B |
|---|---|---|
| Worauf es zielt | die Oberfläche des Werkzeugs | das Ergebnis der Arbeit |
| Wer profitiert | Redakteurinnen und Redakteure mit Behinderung | alle Besucher der Website |
| Typischer Befund | Werkzeugleiste ohne Tastaturzugang | Alternativtext als optionales Freitextfeld |
| Prüfweg | manuelle Bedienung mit Tastatur und Sprachausgabe | Testbeitrag anlegen und den erzeugten Code lesen |
| Rechtlicher Anker | Arbeitsplatzgestaltung nach SGB IX | EN 301 549, Kapitel 11.8, und Vergabeunterlagen |
| Nachrüstbarkeit | begrenzt, sitzt oft im Kern des Systems | in Teilen über eigene Erweiterungen möglich |
Diese Trennung hilft im Alltag, weil sie unterschiedliche Zuständigkeiten benennt. Teil A ist ein Thema für Personalarbeit, Beschaffung und Interessenvertretung: Es geht darum, wer überhaupt in der Redaktion arbeiten kann. Teil B ist ein Thema für Entwicklung, Redaktionsleitung und Qualitätssicherung: Es geht darum, was am Ende auf der Website steht. Ein System kann in einem Teil gut abschneiden und im anderen schwach sein, und beide Fälle kommen häufig vor. Deshalb lohnt es sich, die Teile getrennt zu prüfen und getrennt zu bewerten.
Teil A: die Redaktionsoberfläche ist ein Arbeitsplatz
Wer Inhalte pflegt, verbringt damit Stunden am Tag. Für Menschen mit Behinderung ist das Redaktionssystem deshalb keine Website, die man auch wieder verlassen kann, sondern das Werkzeug ihres Berufs. In Deutschland lebten Ende 2023 rund 7,9 Millionen schwerbehinderte Menschen (Statistisches Bundesamt), eine ältere Schätzung für das Jahr 2002 nennt etwa 1,2 Millionen blinde und sehbehinderte Menschen (DBSV), und weltweit leben nach Schätzungen 1,3 Milliarden Menschen mit einer erheblichen Behinderung (WHO). Ein Teil dieser Menschen arbeitet in Kommunikation, Marketing und Verwaltung, also genau dort, wo Redaktionssysteme benutzt werden. § 164 Absatz 4 verpflichtet Arbeitgeber, Arbeitsplätze einschließlich Maschinen und Geräten behinderungsgerecht einzurichten, soweit ihnen das zumutbar ist (SGB IX). Ein Redaktionssystem, das sich ohne Maus kaum bedienen lässt, steht dieser Pflicht im Weg.
Die Befunde ähneln sich über Systeme hinweg, weil Redaktionsoberflächen ähnliche Bauteile verwenden. Auffällig ist, dass es selten am Editor für den Fließtext scheitert. Die Hürden liegen in den Randbereichen: in der Medienverwaltung, in Baumstrukturen für Seitenhierarchien, in Vorschaufenstern und in den kleinen Meldungen, die den Arbeitsstand mitteilen. Sechs Stellen tauchen in Prüfungen besonders regelmäßig auf.
Werkzeugleiste
Formatierungen, Bausteine und Sonderzeichen liegen häufig auf Schaltflächen ohne Tastaturzugang oder in Menüs, die sich nur mit gedrückter Maustaste öffnen. Prüfschritt: den kompletten Editor einmal ausschließlich mit Tabulator und Eingabetaste bedienen.
Medienbibliothek
Hochladen per Ziehen und Ablegen ist bequem, darf aber nicht der einzige Weg sein. Ohne alternative Schaltfläche und ohne beschriftete Dateiliste bleibt die Bildpflege für Tastaturnutzer verschlossen.
Baumnavigation
Seitenbäume brauchen passende Rollen sowie Zustände für geöffnet, geschlossen und ausgewählt. Fehlen sie, hört eine Sprachausgabe eine Liste aus Verweisen ohne Hierarchie und ohne Angabe der Position.
Vorschaufenster
Die Live-Vorschau steckt oft in einem eingebetteten Rahmen ohne Titel. Ein unbenannter Rahmen ist für eine Sprachausgabe ein Raum ohne Namen, und der Wechsel hinein bleibt unerklärt.
Autospeichern
Meldungen wie Entwurf gespeichert erscheinen visuell und verschwinden wieder. Ohne höfliche Live-Region bleibt der Hinweis für die Sprachausgabe stumm, und der Arbeitsstand bleibt unklar.
Fehlerdialoge
Beim Speichern mit unvollständigen Pflichtfeldern springt der Fokus häufig an den Seitenanfang oder bleibt im Hintergrund liegen. Der Dialog gehört in den Fokus, der Fehler an das betroffene Feld, der Rückweg muss erreichbar bleiben.
Diese sechs Punkte klingen speziell, sind aber in wenigen Stunden prüfbar. Der Weg dorthin führt über Tastaturnavigation in der Praxis, über korrekt gesetzte ARIA-Rollen, Zustände und Live-Regionen und über barrierefreie Fehler- und Statusmeldungen. Wer diese drei Themen im Frontend beherrscht, erkennt sie im Backend wieder: Die Bauteile sind dieselben, nur die Erwartung an sie ist eine andere, weil hier gearbeitet und nicht gelesen wird.
Die Oberfläche entscheidet über die Besetzbarkeit
Teil B: Leitplanken statt guter Vorsätze
Teil B geht von einer nüchternen Annahme aus: Eine Redaktion ist keine Prüfstelle. Sie schreibt, kürzt, bebildert und veröffentlicht unter Zeitdruck. Führt der bequemste Weg im Werkzeug zu einem barrierefreien Ergebnis, entstehen barrierefreie Inhalte auch dann, wenn gerade an anderes gedacht wird. Führt der bequemste Weg an der Anforderung vorbei, hilft auch eine gute Schulung nur begrenzt, weil sie gegen die Oberfläche arbeiten muss. Die Zahlen stützen diese Annahme: Auf 83,9 Prozent der Startseiten fand sich Text mit zu geringem Kontrast (WebAIM Million), und 16,2 Prozent aller untersuchten Bilder hatten keinen Alternativtext (WebAIM Million).
Am Alternativtext lässt sich das gut zeigen. Ein optionales Freitextfeld ohne Erklärung erzeugt drei Ergebnisse: leere Felder, Dateinamen und Beschreibungen, die den Zweck des Bildes verfehlen. Ein Pflichtfeld mit einer bewussten Entscheidung daneben - beschreibend oder dekorativ - erzeugt eine andere Praxis. Wer dekorativ wählt, bekommt ein leeres alt-Attribut im Code statt einer Notlösung, und das ist an dieser Stelle genau richtig. Wie ein tragfähiger Alternativtext aussieht, steht im Beitrag zu barrierefreien Bildern und Alt-Texten; das Werkzeug muss die Entscheidung nur einfordern und erklären.
- Alternativtext als Pflichtfeld, daneben eine bewusste Auswahl für dekorative Bilder statt eines still bleibenden leeren Felds
- Überschriftenebenen, die sich nicht überspringen lassen: Nach einer H2 bietet das Werkzeug die H3 an und weist auf Sprünge hin
- Formatvorlagen statt visuell fett gemachter Pseudo-Überschriften, damit Struktur aus Auszeichnung entsteht und nicht aus Schriftgrad
- Warnung bei Linktexten wie hier oder mehr, verbunden mit dem Vorschlag, das Ziel des Verweises zu benennen
- Kontrastwarnung im Farbwähler, die beim Setzen von Text- und Hintergrundfarbe das Verhältnis direkt anzeigt
- Tabellenassistent, der Kopfzellen verlangt und Zellen zuordnet, statt ein Raster aus leeren Feldern anzulegen
- Vorlagen und Bausteine, die ausschließlich barrierefreien Code erzeugen, vom Akkordeon bis zur Bildergalerie
- Sprachauszeichnung für fremdsprachige Passagen, damit die Sprachausgabe nicht in der falschen Aussprache bleibt
Die vorletzte Zeile dieser Liste ist die wirksamste. Wenn die Bausteine im Werkzeug aus einem geprüften barrierefreien Design-System stammen, ist ein großer Teil der Arbeit erledigt, bevor die Redaktion beginnt. Dasselbe gilt für die Farbpalette: Sind im Farbwähler nur Kombinationen hinterlegt, die den Anforderungen an Farbkontraste genügen, verschwindet ein ganzer Fehlertyp aus dem Alltag. Auch komplexe Bauteile wie Datentabellen gehören in einen Assistenten, weil die Zuordnung von Kopfzellen von Hand selten gelingt.
Von ATAG zur EN 301 549 und zum BFSG
ATAG 2.0 selbst ist eine Empfehlung ohne unmittelbare Rechtswirkung. Der Weg in die Verbindlichkeit führt über die europäische Norm. Die EN 301 549 behandelt in Kapitel 9 Webinhalte, in Kapitel 10 Dokumente und in Kapitel 11 Software; darin liegt mit Kapitel 11.8 ein eigener Abschnitt für Autorenwerkzeuge mit fünf Anforderungen (EN 301 549): 11.8.1 zur verwendeten Technologie, 11.8.2 zur Erstellung barrierefreier Inhalte, 11.8.3 zum Erhalt der Barrierefreiheitsinformationen bei Umwandlungen, 11.8.4 zur Unterstützung bei der Reparatur und 11.8.5 zu Vorlagen. Der Gedanke aus ATAG Teil B steht damit in derselben Norm, auf die sich das deutsche Recht bezieht.
Für die Praxis ergeben sich daraus zwei Wege in die Pflicht. Der erste führt über die öffentliche Beschaffung: Wer Software an öffentliche Auftraggeber liefert, findet die EN 301 549 in den Vergabeunterlagen wieder, und Kapitel 11.8 gilt dort mit. Der zweite führt über das Barrierefreiheitsstärkungsgesetz, das seit dem 28. Juni 2025 gilt und den europäischen Rechtsakt zur Barrierefreiheit in deutsches Recht überführt (EU-Richtlinie 2019/882). Wer ein Redaktionssystem an Kunden ausliefert, verkauft die Voraussetzung für deren Pflichterfüllung gleich mit. Welche Angebote im Einzelnen betroffen sind, steht in der Übersicht zu den BFSG-Anforderungen; Kleinstunternehmen mit weniger als 10 Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz sind bei Dienstleistungen ausgenommen (BFSG).
Wie eng Werkzeug und Ergebnis zusammenhängen, zeigt sich auch bei barrierefreien Lernplattformen: Kursautoren arbeiten dort mit dem Autorenwerkzeug der Plattform, und jeder Kurs erbt dessen Grenzen. Dieselbe Vererbung gilt für Shop-Backends, Newsletter-Editoren und Formularbaukästen. Wer das Werkzeug prüft, prüft deshalb nicht ein System, sondern alles, was künftig damit entsteht.
Zwei Rollen, zwei Pflichten
Prüfraster für Auswahl und Nachrüstung
Ein belastbares Bild entsteht in wenigen Stunden. Legen Sie einen Testbeitrag an, der alles enthält, was Ihre Redaktion typischerweise braucht: Überschriften über zwei Ebenen, ein Bild, eine Tabelle, einen Verweis, ein Zitat und ein eingebettetes Video. Bedienen Sie das System dabei einmal ausschließlich mit der Tastatur und einmal mit einer Sprachausgabe. Lesen Sie danach den erzeugten Quelltext. Zehn Schritte reichen für eine Entscheidungsgrundlage, die auch in einem Vergabeverfahren trägt.
- Anmeldung, Übersichtsseite und Editor ausschließlich mit Tabulator und Eingabetaste bedienen
- Prüfen, ob der Tastaturfokus sichtbar bleibt und keine Falle entsteht, die sich nur mit der Maus verlassen lässt
- Ein Bild hochladen, ohne es mit der Maus in die Ablagefläche zu ziehen
- Den Seitenbaum mit einer Sprachausgabe öffnen und schließen und dabei auf Rollen sowie Zustände achten
- Einen Pflichtfehler auslösen und beobachten, wohin der Fokus springt und ob die Meldung angesagt wird
- Im Testbeitrag eine Überschriftenebene überspringen und prüfen, ob das System darauf hinweist
- Ein Bild ohne Alternativtext speichern und sehen, ob das Werkzeug nachfragt oder still zustimmt
- Einen Verweis mit dem Text mehr anlegen und darauf achten, ob eine Warnung erscheint
- Im Farbwähler eine schwache Kombination setzen und die Kontrastanzeige beobachten
- Den erzeugten Quelltext lesen: Überschriftenebenen, Listen, Tabellenkopf, Sprachauszeichnung und leere alt-Attribute
Aus den Befunden entsteht die eigentliche Frage: Was lässt sich nachziehen, und was sitzt so tief im System, dass ein Wechsel die ehrlichere Antwort wäre? Als Faustregel gilt: Alles, was zwischen Eingabe und Speicherung stattfindet, lässt sich häufig über Erweiterungen, eigene Feldkonfigurationen und eigene Bausteine nachrüsten. Alles, was die Grundstruktur der Oberfläche betrifft, gehört dem Hersteller und wird zur Anforderung an ihn.
| Baustelle | Über eigene Erweiterungen | Beim Hersteller angesiedelt |
|---|---|---|
| Alternativtext als Pflichtfeld | meist über die Feldkonfiguration lösbar | selten erforderlich |
| Formatvorlagen und Bausteine | über eigene Vorlagen im Projekt umsetzbar | selten erforderlich |
| Kontrastwarnung im Farbwähler | über eine eingeschränkte Palette lösbar | nur für die freie Farbwahl |
| Tastaturbedienung der Werkzeugleiste | kaum sinnvoll nachzubauen | Anforderung oder Systemwechsel |
| Rollen und Zustände im Seitenbaum | in Teilen über Anpassungen möglich | überwiegend beim Hersteller |
| Fokusführung in Dialogen | in eigenen Dialogen umsetzbar | für Standarddialoge beim Hersteller |
Diese Einordnung verändert Gespräche mit Herstellern. Statt einer allgemeinen Frage nach Barrierefreiheit liegt eine Liste mit nachvollziehbaren Kriterien auf dem Tisch, und aus der Antwort wird ein Termin. In der barrierefreien Webentwicklung bauen wir die nachrüstbaren Punkte als Leitplanken direkt in das vorhandene System ein, statt sie in eine Richtlinie zu schreiben, die im Laufwerk liegt und gelesen werden müsste.
Aus einmal aufräumen wird laufend prüfen
Ein Redaktionssystem mit Leitplanken senkt die Fehlerquote, ersetzt die Kontrolle aber nicht. Neue Inhalte, neue Vorlagen und Aktualisierungen des Systems verschieben den Zustand laufend. Ein BFSG-Monitoring prüft deshalb nicht einmalig, sondern in festen Abständen, und es prüft bevorzugt das, was neu hinzugekommen ist. Damit verschiebt sich der Aufwand von großen Aufräumaktionen zu kleinen, planbaren Korrekturen, die im Redaktionsalltag Platz haben.
Der zweite Baustein ist die Rollenteilung. Die Redaktion braucht Antworten auf inhaltliche Fragen: Wann ist ein Bild dekorativ, wie beschreibt man ein Diagramm, wie formuliert man einen Verweis? Dafür gibt es unsere Schulungen für Redaktion und Entwicklung und den Beitrag zur Schulung des Redaktionsteams. Die Entwicklung braucht etwas anderes: verlässliche Bausteine, geprüfte Vorlagen und eine Oberfläche, die den korrekten Weg zum bequemen Weg macht. ATAG trennt diese beiden Zuständigkeiten sauber, und genau deshalb ist die Richtlinie im Projektalltag nützlich.
Eine Redaktionsoberfläche, die den korrekten Weg zum bequemsten macht, erzeugt mehr Barrierefreiheit als jede Richtlinie im Intranet.
Der Einstieg ist überschaubar. Ein Audit der Redaktionsoberfläche ist ein eigener Prüfauftrag mit klarem Umfang: Anmeldung, Editor, Medienverwaltung, Seitenbaum, Dialoge und Vorschau nach Teil A, dazu ein Testbeitrag und der erzeugte Quelltext nach Teil B. Das Ergebnis ist eine priorisierte Liste mit der Angabe, was sich im Projekt lösen lässt und was an den Hersteller geht. Wie ein solcher Prüfauftrag abläuft, zeigt die Übersicht unserer Leistungen - und wer bereits einen Prüfbericht für die Website hat, kann die Oberfläche mit demselben Verfahren nachziehen.
Quellen und Studien