Neuigkeiten

Aktive Projekte

Zuletzt aktualisiert am 31. Oktober 2026

In Arbeit

v3: Eine vollständige QS-Suite

27. September 2026

Vorstellung auf der DrupalCon Europe 2026

Wichtige neue Funktionen

• Testkern mit Sa11y zusammengeführt. Das neue, gemeinsam entwickelte Regelwerk ergänzt die zentralen Inhaltstests um Entwicklertests, Kontrastprüfung und Lesbarkeitsbewertung.
• Unterstützung für mehrere Sprachen
• Builder für benutzerdefinierte Prüfungen
• Dashboard-Verwaltungswerkzeuge
• Ein Werkzeug zum Crawlen der Website, das neue Ergebnisse hinzufügt.
• Ermöglicht es bestimmten Rollen, die Hinweise einzelner Tests (ist dieses PDF barrierefrei?) seitenweit zu verwerfen.
• Getrennte Konfiguration: rollenbasierte Tests und Berichtsansichten, getrennt nach Entwicklern und Inhaltsverantwortlichen.

Und, was für die Zukunft des Projekts vielleicht am wichtigsten ist:

• Eine Förderung eingeworben, um diese Trägerorganisation zu gründen, die bestehende Nutzer unterstützt und die Arbeit an künftigen Projektideen finanziert.

v2: Verwerfen von Hinweisen & Berichte

2. März 2023

Vor zwei Jahren haben wir den Barrierefreiheitsprüfer Editoria11y vorgestellt: ein sofort einsetzbares Website-Plugin für Drupal, das Autoren automatisch und unmittelbar Feedback gibt und hilfreiche Tipps zur Verbesserung ihrer Inhalte liefert.

Wir glaubten, damit einen ungedeckten Bedarf zu treffen. Alle vorhandenen Optionen setzten Schulung und konsequente Nutzung voraus, und die Erfahrung hatte uns gezeigt, dass es kein effizienter Lösungsweg ist, Tausende von Autoren in einer großen Organisation zu schulen und zu überwachen. Damit ein Programm Erfolg hat, so unsere Überzeugung, muss es weitgehend automatisiert sein und Autoren höflich eine „Just-in-Time-Schulung“ bieten, sobald es typische Fehler erkennt.

Es hat funktioniert.

In Princeton hat es die Richtung meiner Kommunikation weitgehend umgekehrt. Auf Plattformen, auf denen es installiert war, verschickten wir keine immer gleichen E-Mails mehr an Autoren, in denen wir um Alternativtexte oder bessere Links und Überschriften baten, sondern erhielten Fragen von Autoren, wie sie ihre Texte verbessern könnten, damit sie nicht mehr so oft markiert werden.

Außerhalb von Princeton fiel die Reaktion euphorisch aus:

In sich geschlossene Tipps schreiben

Bei den Tipps in v1 setzten wir auf das Prinzip „Zusammenfassung und Details“: eine kurze Erklärung des Problems und ein Link zu weiteren Details.

Das war eine Verbesserung gegenüber Werkzeugen, die für Entwickler geschrieben sind: Die Tipps waren kurz und klar. Doch die Frage, wohin der Link führen sollte, blieb ein ständiges Problem. Mehrere Nutzer aus Behörden und Hochschulen sahen sich veranlasst, die Tipps anzupassen und die Links zur Dokumentation von Princeton zu entfernen, was für sie zusätzliche Arbeit bedeutete. Also haben wir die Standardtipps so umgeschrieben, dass sie für sich allein stehen und die Beispiele gleich mitliefern.

Die Unterscheidung zwischen roten Hinweisen (eindeutige Probleme) und gelben Warnungen (mögliche Probleme) erwies sich als verwirrend und zuweilen als nervig.

Also haben wir die gelben Warnungen in „manuelle Prüfungen“ umgewandelt, um ihre Bedeutung klarer zu machen, und Schaltflächen hinzugefügt, mit denen Autoren Hinweise verwerfen können. „Ignorierte“ Hinweise werden nur für die Person ausgeblendet, die darauf klickt; „als OK markierte“ Hinweise werden für alle Redakteure der Website ausgeblendet. Website-Administratoren können jeweils festlegen, wer dazu berechtigt ist.

Ein Dashboard erstellen

Website-Betreiber klagten häufig, das Werkzeug finde zwar hervorragend Probleme überall auf der Website, aber es gebe keine Möglichkeit, einen seitenweiten Bericht anzuzeigen.

Die Neuentwicklung bietet die Option, Ergebnisse zurück in die Datenbank der Website zu synchronisieren. Website-Betreiber können die Ergebnisse jetzt nach Seite oder Problem durchsuchen, prüfen, welche Probleme ignoriert oder als OK markiert wurden – und das Problem wiederherstellen, wenn sie anderer Meinung sind!

V2-Codetour für Entwickler

V2 war fast eine komplette Neuentwicklung. Zu den neuen Funktionen gehören:

• Durch den Wegfall der jQuery-Abhängigkeit lässt sich der Prüfer auf mehr Plattformen installieren und arbeitet doppelt so schnell.
• Der Prüfer lässt sich jetzt so konfigurieren, dass er mehrere voneinander unabhängige Teile der Seite untersucht (z. B. den Artikelinhalt und die Fußzeile).
• Der Prüfer kann jetzt auch Elemente im Shadow DOM testen, das von verschiedenen Webkomponenten und JavaScript-Bibliotheken verwendet wird.
• Zahlreiche neue Parameter erleichtern die Integration in Plattformen, etwa das automatische Ignorieren aller Probleme auf bestimmten Seiten für bestimmte Benutzer, die für den Inhalt dieser Seite nicht verantwortlich sind, die Ergebnisse aber bei Bedarf trotzdem ansehen möchten.
• Der Prüfer wird jetzt mit mehreren Basis-Themes und Parametern zum Anpassen der Farben ausgeliefert.
• Automatisierte Tests helfen, Code-Regressionen zu vermeiden.

A11yTalks 2024

11. Juni 2024

Drupal GovCon 2023

27. Oktober 2023

DrupalCamp NJ 2023

28. März 2023

v1: Hilfe direkt im Inhalt

11. März 2021

Hochgradig barrierefreie Webinhalte zu erstellen ist kompliziert und beginnt meist mit jeder Menge Schulung.

Vertraute Gewohnheiten müssen abgestellt werden:

• Tabellen sollten nicht dazu verwendet werden, Spalten vorzutäuschen
• Fließtext sollte weder zentriert noch im Blocksatz gesetzt werden
• Rein visuelle Formatierung (Schriftstärke und -größe) sollte nicht das einzige Mittel sein, um Nutzern Bedeutung zu vermitteln, denn manche hören die Inhalte oder lesen sie im „Lesemodus“

Neue Gewohnheiten müssen gefördert werden:

• Bilder brauchen Alternativtexte, die im Kontext aussagekräftig sind
• Seiten brauchen eine echte Struktur
• Links sollten aussagekräftige Bezeichnungen haben

Sicher führen wir manche Schulungen ein, weil wir neue Konzepte vermitteln. Doch irgendwann muss man sich fragen: Wie viel vom Bedarf an neuen Fähigkeiten rührt daher, dass die Konzepte neu sind, und wie viel daher, dass wir neue Erwartungen einführen, ohne unsere Werkzeuge anzupassen? Nur weil etwas neu ist, heißt das nicht, dass es nicht intuitiv sein kann.

Lehren aus der Geschichte der Rechtschreibung

Phase 1: Der Autor ist schuld

Seit den Anfängen der schriftlichen Überlieferung bis in die frühen 1980er-Jahre gaben wir dem Autor die Schuld, wenn er ein Wort falsch schrieb. Es lag in seiner Verantwortung, die Rechtschreibung zu beherrschen.

Wie verbesserte man seine Rechtschreibung? Das dürfte Ihnen bekannt vorkommen:

1. Man besuchte Schulungen, bei Privatlehrern oder im Klassenzimmer
2. Man bekam Listen, Richtlinien und Wörterbücher zum Lernen, eine Tradition, die bis zu den in Ton geritzten Keilschrift-Lexika des Altertums zurückreicht.

Phase 2: Das Wörterbuch ist schuld

Doch in den 1980er-Jahren änderte sich etwas – nennen wir es „Rechtschreibung, Phase 2“. Die beliebtesten Textverarbeitungsprogramme führten die Rechtschreibprüfung ein.

Und was geschah mit dem Schwarzen Peter? Fast über Nacht landete er beim Werkzeug:

• Sie wissen nicht, wie man ein Wort schreibt? Raten Sie und hoffen Sie auf einen Treffer. Gibt es keinen, ist das Wörterbuch schuld.
• Sie verwenden ein echtes Wort, das vom Wörterbuch markiert wird, weil es ihm unbekannt ist? Murren Sie kurz und entscheiden Sie, ob Sie die Unterstreichung ignorieren oder per Rechtsklick das Wort zum Wörterbuch hinzufügen.

Hat die Rechtschreibprüfung all unsere Rechtschreibfehler beseitigt? Sicher nicht. Aber sie hat geholfen. Und sie hat einen Großteil der Last und der Verantwortung vom Autor auf die Maschine verlagert.

Doch das war noch nicht das Ende …

Phase 3: Das Autorenwerkzeug ist schuld

In den letzten Jahren kam ein weiterer Fortschritt hinzu: Computer haben begonnen, die Rechtschreibung für uns zu übernehmen:

• Vorhersagealgorithmen versuchen, das nächste Wort, die nächste Wendung, vielleicht sogar eine ganze Antwort auf eine Textnachricht zu erraten.
• Autoformat-Werkzeuge versuchen, Sternchen, Zahlen und Buchstaben in Listen umzuwandeln, Kurzcodes in Sonderzeichen und Emojis und so weiter.
• Diktierwerkzeuge versuchen, den Sinn zu erfassen, um zwischen gleich klingenden Wörtern zu wählen.

Und wer bekommt die Schuld, wenn das schiefgeht? Das Werkzeug!

Social-Media-Aggregatoren lieben den peinlichen „Das habe ich so nicht gemeint!“-Screenshot.

Editoria11y ist ein Schritt in Richtung Phase 2

In unseren Schulungen sprechen wir viel über das Testen und stellen mehrere wirklich gute Prüfwerkzeuge vor. Keines davon findet alles: Vorgaben wie „Konzepte nicht über farbliche oder räumliche Bezüge erklären“ muss ein Mensch prüfen, und Werkzeuge finden in der Regel knapp die Hälfte der tatsächlichen Probleme einer Website. Doch viele typische Fehler in redaktionellen Inhalten erkennen sie sehr zuverlässig.

Allerdings gibt es drei Probleme:

1. Die meisten sind manuelle Werkzeuge. Der Content-Ersteller muss gelernt haben, sie zu benutzen, muss beim Schreiben daran denken, dass es sie gibt, und muss daran denken, sie am Ende auch auszuführen. Diese drei Schwachstellen sorgen im Zusammenspiel dafür, dass viele (die meisten?) Inhalte ungeprüft bleiben.
2. Sie markieren zu viel. Sie markieren nicht nur Fehler, die dem Autor gerade unterlaufen sind, sondern auch Farbprobleme des Designers, technische Probleme des Entwicklers, Strukturelemente zu Informationszwecken und so weiter. Das erhöht die Anforderungen an die Schulungen: Autoren müssen nicht nur das Werkzeug verstehen, sondern auch lernen, eine ganze Liste von Fehlalarmen oder durchaus echten Problemen zu ignorieren, deren Behebung heute, beim Schreiben genau dieses Artikels, nicht ihre Aufgabe ist.
3. Die automatisierten Werkzeuge folgen meist dem Muster „Website crawlen, Dashboard besuchen“. Auch das setzt voraus, dass ein Autor geschult wurde, das Dashboard zu besuchen, und auch daran denkt.

Also machte sich Princeton daran, etwas Neues zu schaffen: einen in die Website integrierten, automatischen Prüfer, der sich nur typische redaktionelle Fehler ansieht.

Automatisch ist … schwierig.

1. Automatische Prüfer müssen dezent sein: Sind sie zu aufdringlich, unterbrechen und frustrieren sie den Autor. Sind sie zu höflich, werden sie schnell zum Hintergrundrauschen, das niemand mehr beachtet.
2. Automatische Prüfer müssen sehr schnell sein: Wenn die Seite ruckelt oder stockt, während sie laufen, werden Autoren sie als lästig empfinden und abschalten.
3. Automatische Prüfer brauchen einsteigerfreundliche Tipps. Viele Autoren hören hier zum ersten Mal von den Tags, der Struktur und der Sprache, die ihre Inhalte barrierefreier machen. Hinweise müssen in einfacher, nicht-technischer Sprache verfasst sein und praktische Ratschläge zur Verbesserung der Inhalte geben.

Also begannen wir mit dem Werkzeug, das diesen Zielen am nächsten kam: Sa11y von der Toronto Metropolitan University. Wir übernahmen seine Testarchitektur und seinen benutzerfreundlichen Ansatz mit Informationspanel und Tooltips und verbrachten ein halbes Jahr damit, das Werkzeug so anzupassen, dass die Tests immer automatisch liefen. Dabei optimierten wir die Leistung, überarbeiteten die Tooltips und schufen eine lange Liste von Konfigurationsoptionen, mit denen Entwickler es schnell an jede Plattform anpassen können.

So sieht es heute aus:

Wenn ein Autor bei seiner Website angemeldet ist, zeigt der Umschalter von Editoria11y auf jeder Seite Anzahl und Art der Probleme an (bestanden, manuelle Prüfungen erforderlich, wahrscheinliche Probleme gefunden). Per Klick lassen sich Hervorhebungen und Tipps direkt im Inhalt einblenden. Ist der Fehler neu, weil der Autor gerade eine soeben bearbeitete Seite ansieht, öffnet sich das Panel automatisch.

Stand März 2021 bedeutet das, dass mehr als 400 Websites von Princeton automatisch Folgendes prüfen:

• Eine gute Dokumentgliederung
  • Übersprungene Überschriftenebenen
  • Leere Überschriften
  • Sehr lange Überschriften
  • Verdächtig kurze Blockzitate, die eigentlich Überschriften sein könnten.
• Textalternativen
  • Bilder ohne Alternativtext
  • Bilder mit einem Dateinamen als Alternativtext
  • Bilder mit sehr langem Alternativtext
  • Alternativtext mit redundanten Wörtern wie „Bild von“ oder „Foto von“
  • Bilder in Links, deren Alternativtext offenbar das Bild statt des Linkziels beschreibt
  • Eingebettete Visualisierungen, die in der Regel eine Textalternative benötigen
• Aussagekräftige Links
  • Links ohne Text
  • Links, die mit einem Dateinamen beschriftet sind
  • Links, die nur mit allgemeinem Text beschriftet sind: „Hier klicken“, „Mehr erfahren“, „Herunterladen“ usw.
  • Links, die sich ohne Symbol für externe Links in einem neuen Fenster öffnen
• Allgemeine Qualitätssicherung
  • Sicherstellen, dass die Listenformatierung verwendet wird statt Sternchen, Zahlen und Buchstaben
  • GROSSE MENGEN TEXT IN GROSSBUCHSTABEN
  • Tabellen ohne Kopfzellen und Tabellen mit Dokumentüberschriften („Überschrift 3“) anstelle von Tabellenkopfzellen (<th>)
  • Links zu PDFs und anderen Dokumenten, mit der Erinnerung, den Download auf Barrierefreiheit zu prüfen oder ein alternatives, barrierefreies Format bereitzustellen
  • Eingebettete Videos, mit der Erinnerung, Untertitel hinzuzufügen
  • Eingebettete Audiodateien, mit der Erinnerung, ein Transkript bereitzustellen
  • Eingebettete Social-Media-Inhalte, mit der Erinnerung, Alt-Elemente anzugeben

Wir haben die JavaScript-Bibliothek für die Community veröffentlicht, eine sofort einsetzbare Drupal-Integration erstellt und mit der Arbeit an einer sofort einsetzbaren WordPress-Integration begonnen.

Auf dem Weg zu Phase 3: Standardmäßig barrierefrei

In vielerlei Hinsicht ist Editoria11y eine Notlösung. Die meisten Fehler, die es findet, entstanden, weil wir neue Erwartungen an Autoren gestellt haben („Geben Sie Ihren Inhalten eine gute Struktur“), ihnen aber Werkzeuge an die Hand gegeben haben, die das Gegenteil förderten.

Der Weg nach vorn besteht darin, das Erstellen barrierefreier Inhalte einfacher und so automatisch wie möglich zu machen. Wie das aussieht, ist noch nicht klar, aber wahrscheinlich gehört dazu Folgendes:

• Überdenken, welche Optionen überhaupt verfügbar sind. Beispiel: Wenn wir Nutzern ständig sagen, dass sie Text im Web nicht im Blocksatz setzen sollen, ist es dann nicht an der Zeit, die Schaltfläche „Blocksatz“ in den Ruhestand zu schicken?
• Die Standardoptionen überdenken. Beispiel: Die Standardtabelle hat in den meisten Content-Management-Systemen keine Kopfzellen. Der Nutzer muss wissen, dass er auf „Eigenschaften“ klicken und Barrierefreiheitsfunktionen hinzufügen muss; vielleicht ist es Zeit, das umzukehren?
• Über vorausschauende Formatierung und „Hinweise während der Arbeit“ nachdenken. Wenn ein Nutzer eine ganze Zeile fett formatiert, können wir ihm dann vorschlagen, daraus eine Überschrift zu machen? Wenn ein Nutzer eine Überschrift auswählen will, können wir dann erraten, welche Überschriftenebenen er brauchen könnte, statt ihm sechs Optionen anzubieten? Können wir zu schwierigen Konzepten eine Just-in-Time-Schulung anbieten?