Statamic barrierefrei: Saubere Ausgabe ohne Plugin-Zoo

Die kurze Antwort: Statamic gibt Ihnen kein HTML vor. Es gibt keinen Theme-Markt, keinen visuellen Builder, der Markup erzeugt, und keine Plugins, die sich ins Frontend schreiben. Statamic ist ein CMS auf Laravel; die Templates, aus denen die Seite entsteht, schreibt das Projektteam selbst. Das Control Panel ist die Oberfläche für Redaktion, Nutzer, Rechte und Einstellungen ^[4], das Frontend ist eigener Code. Dieser Artikel ist eine Orientierung, keine Rechtsberatung.

Für die Barrierefreiheit kehrt das die Verantwortung um. Bei einem Baukasten-System fragt man: Welches Theme, welcher Builder, welches Plugin ist barrierefrei? Bei Statamic fragt man: Ist unser Markup barrierefrei? Die Frage ist unbequemer, aber ehrlicher, denn sie hat eine Adresse. Und sie lässt sich mit Werkzeugen beantworten, die im Projekt laufen, nicht erst auf der Live-Seite.

Zur Kennzahl oben: WebAIM misst für Startseiten, die mit dem Framework Astro gebaut sind, 9,0 automatisch erkennbare Fehler, 84 % unter dem Schnitt von 56,1 ^[1]. Das ist kein Statamic-Wert; eine Statistik zur Barrierefreiheit von Statamic-Seiten gibt es nicht. Der Astro-Wert zeigt aber, was schlanke, serverseitig erzeugte Ausgabe erreicht, und Astro ist genau das Frontend, das wir für Statamic-Projekte einsetzen können, wenn eine statische Auslieferung passt. WebAIM selbst zieht aus seinem Bericht den Schluss, dass Barrierefreiheit im großen Maßstab bessere Praxis und einfachere Systeme braucht ^[1]. Statamic ist so ein einfacheres System, wenn man es so baut.

Volle Kontrolle heißt volle Verantwortung, und ein paar Dinge erledigt kein CMS von allein:

• Bard-Inhalte. Der Fließtext-Editor erzeugt sauberes HTML, aber die Überschriften-Ebenen wählt die Redaktion. Eine H4 unter einer H2 bleibt ein Fehler, egal wie gut das Template ist. Hilfreich ist, im Blueprint nur die Ebenen anzubieten, die an dieser Stelle sinnvoll sind.
• Asset-Container. Der Standard-Blueprint eines Containers enthält ein Alt-Text-Feld ^[5]. Pflicht wird es erst, wenn Sie im Blueprint eine Validierungsregel setzen ^[6]. Dann lässt sich kein Bild ohne Alt-Text speichern, und das Template gibt den Text als alt-Attribut aus ^[5]. Dekorative Bilder brauchen eine eigene Regel, etwa ein Feld „dekorativ“, das ein leeres alt erzeugt.
• Formulare. Statamic bringt Formularverarbeitung mit, die Ausgabe im Frontend schreiben Sie. Labels, Pflichtfeld-Kennzeichnung, Fehlermeldungen als Text beim Feld und Fokus auf den ersten Fehler sind Ihre Aufgabe. Was dabei zu beachten ist, steht unter Formulare und Cookie-Banner.
• PDFs. Hochgeladene Dokumente sind Inhalte wie alle anderen. Entweder sie sind getaggt und geprüft, oder sie werden HTML-Seiten; siehe Barrierefreie PDF-Dokumente.
• Kontrast. Farben kommen aus dem Design-System, nicht aus dem CMS. Werden sie dort einmal mit geprüften Verhältnissen angelegt, stimmen sie überall; die Grenzwerte und einen Prüfer finden Sie unter Kontrast, Farben, Schrift.

Die Seite, die Sie gerade lesen, ist so gebaut: Statamic als Backend für Inhalte, Pakete und diese Artikel, ein Astro-Frontend, das daraus statische Seiten erzeugt. Jedes Element im Quelltext stammt aus einer Komponente des Projekts. Der erste Tabstopp ist ein Skip-Link „Zum Inhalt springen“, der Fokus ist auf Links und Buttons mit einem deutlichen Rahmen sichtbar, Animationen und Übergänge werden abgeschaltet, wenn das Betriebssystem reduzierte Bewegung wünscht, und jedes Formularfeld hat ein sichtbar verbundenes Label. Nichts davon kommt aus einem Plugin.

Wir nennen hier bewusst keine Messwerte. Ein Prüfergebnis gilt für den Tag, an dem es erhoben wurde, und eine Seite ändert sich. Wenn Sie den Stand sehen wollen, öffnen Sie den Quelltext, drücken Sie die Tabulatortaste und lassen Sie einen Screenreader mitlesen. Das ist der Test, der zählt, und derselbe, den wir für Projekte unserer Agenturkunden machen. Was auf WordPress zu beachten ist, steht unter WordPress barrierefrei; eine Prüfliste für beide Systeme ist die Checkliste.