Beginnen Sie mit einem nativen HTML-Element und einer logischen Reihenfolge des Inhalts; fügen Sie ARIA nur für fehlende Semantik hinzu. Benennen Sie die Bedienelemente des Editors und machen Sie sie per Tastatur zugänglich, sperren Sie den Block nicht in einer Fokusfalle ein und verhindern Sie, dass Redakteure unzulässige Kontraste oder Hierarchien erstellen. Testen Sie Editor und Frontend ohne Maus und mit einem Screenreader. Prüfen Sie auch Zoom, lange Übersetzungen und eingeschränkte Bewegung. Ein automatischer Audit ersetzt nicht die manuelle Interaktion.
Die Barrierefreiheit von Gutenberg-Blöcken betrifft zwei Oberflächen. Besucher nutzen das HTML auf der öffentlichen Seite, während Redakteure mit den Bedienelementen im Editor arbeiten. Ein Block kann auf der Website korrekt aussehen, beim Einfügen jedoch keinen verständlichen Namen haben, den Fokus verlieren oder eine Maus erfordern. Umgekehrt kann er im Editor komfortabel sein und eine nicht-semantische oder nicht bedienbare Ausgabe erzeugen.
Ein barrierefreier Block entsteht nicht, indem man am Ende der Entwicklung einige ARIA-Attribute hinzufügt. Er braucht eine semantische Grundlage, begrenzte und benannte Einstellungen, eine vorhersehbare Tastaturbedienung, ein Fokusmanagement und Tests dynamischer Zustände. Diese Anleitung behandelt die Blockkomponente und redaktionelle Schutzmechanismen und ergänzt damit die allgemeine Barrierefreiheit der Website sowie den umfassenderen Entwurf eigener Gutenberg-Blöcke.
Definieren Sie die Semantik vor der visuellen Variante
Bestimmen Sie die Bedeutung der Komponente: Navigation, Liste, Hinweis, Karte mit Link oder bedienbares Disclosure-Element. Verwenden Sie ein natives Element, das das erwartete Verhalten bereits mitbringt. Ein anklickbares div ersetzt keinen button, und eine nach Schriftgröße gewählte Überschrift ersetzt keine logische Ebene im Dokument. CSS verändert dann das Erscheinungsbild, ohne dass die Semantik verloren geht.
Entscheiden Sie, welche Texte Inhalt und welche barrierefreie Beschriftung sind. Ein Icon ohne Text benötigt einen Namen für das Bedienelement, ein dekoratives Bild soll ignoriert werden und ein informatives Bild braucht einen aussagekräftigen Alternativtext. Ein Block sollte den Namen nicht automatisch doppelt aus sichtbarem Text und aria-label zusammensetzen.
Gestalten Sie die Bearbeitungssteuerung mit WordPress-Komponenten
Verwenden Sie unterstützte Editor-Komponenten, die Beschriftung, Fokus und Tastaturverhalten bereitstellen. Jeder Toggle, jedes Select und jedes Textfeld hat ein sichtbares oder programmatisch verfügbares Label sowie einen Hilfetext zur Auswirkung. Ein Icon-Button braucht einen verständlichen Namen, der die Aktion beschreibt, nicht die Form des Icons.
Die Bedienreihenfolge folgt der Logik der Aufgabe. Nach dem Einfügen, Duplizieren, Verschieben und Entfernen bleibt der Fokus an einer vorhersehbaren Stelle. Schränken Sie verschachtelte Blöcke nicht so ein, dass die Auswahl des übergeordneten Elements oder das Verlassen der Komponente per Tastatur unmöglich wird. Ein Fehler in den Einstellungen wird per Text mitgeteilt und mit dem zugehörigen Bedienelement verknüpft.
- Benannte Eingabefelder und Icon-Schaltflächen
- Vorhersehbarer Fokus nach einer Änderung
- Tastatursteuerung der Verschachtelung
- Textfehler im Zusammenhang mit der Konfiguration
Begrenzen Sie Varianten, die eine Barriere schaffen können
Redakteure sollten keine beliebige Text- und Hintergrundfarbe wählen können, wenn die Kombination beim Kontrast versagen kann. Bieten Sie freigegebene Tokens oder Farbpaare an und zeigen Sie bei dynamischer Auswahl eine Prüfung an. Beschränken Sie ebenso nicht unterstützte Größen, Animationen und die Überschriftenhierarchie entsprechend dem Kontext, den der Block erkennen kann.
Ein verpflichtender Alternativtext ist nicht für jedes Bild richtig; der Block sollte es ermöglichen, einen dekorativen Zweck zu kennzeichnen und den Unterschied zu erklären. Ein automatisch aus dem Dateinamen erzeugter Name hilft oft nicht weiter. Verlangen Sie bei Links einen verständlichen sichtbaren Text und weisen Sie auf mehrere gleiche allgemeine Links ohne Kontext hin.
Setzen Sie dynamisches Verhalten um, ohne den Fokus zu verlieren
Öffnet ein Block einen Dialog, wird der Fokus hineinverschoben, bleibt dort, solange der Dialog geöffnet ist, und kehrt nach dem Schließen zum auslösenden Element zurück. Ein Disclosure-Element aktualisiert aria-expanded und die Verknüpfung mit dem Panel. Ein Karussell braucht Bedienelemente, eine Möglichkeit, die Bewegung anzuhalten, und darf den Inhalt nicht so schnell wechseln, dass Nutzer ihn nicht lesen können.
Kündigen Sie Statusmeldungen über eine angemessene Live-Region an, ohne Nutzer zu überfluten. Laden, Erfolg und Fehler müssen auch ohne Farbe erkennbar sein. JavaScript erhält bei der Initialisierung den nativen Inhalt oder einen sicheren Fallback. Die Hydration darf die Tab-Reihenfolge nicht ändern und keine doppelten, nur visuell verborgenen Bedienelemente erzeugen.
Testen Sie den Block isoliert und auf der gesamten Seite
Testen Sie im Editor das Einfügen über den Inserter, die Suche nach dem Namen, das Ändern aller Einstellungen, Rückgängig machen, Duplizieren, Verschieben und Entfernen ausschließlich per Tastatur. Gehen Sie auch Fehler- und Leerzustände mit eingeschaltetem Screenreader durch. Automatische Regeln erfassen einen Teil der Probleme, prüfen aber weder die Verständlichkeit noch die Reihenfolge der Interaktion.
Fügen Sie im Frontend mehrere Instanzen des Blocks zwischen Überschriften, Formularen und Navigation ein. Testen Sie Zoom, schmale Viewports, hohen Kontrast, reduzierte Bewegung und lange Übersetzungen. Nehmen Sie die Prüfung in die Regressionstests und die Dokumentation für Redakteure auf. Die Barrierefreiheit kann durch die Änderung eines Tokens oder eines gemeinsamen Skripts beeinträchtigt werden, auch ohne Anpassung des Blocks selbst.
Häufige Fragen
Reicht es, einem Gutenberg-Block ARIA-Attribute hinzuzufügen?
Nein. Verwenden Sie zuerst korrektes natives HTML und das erwartete Tastaturverhalten. ARIA ergänzt fehlende Semantik, behebt aber weder einen fehlerhaften Fokus noch eine falsche Reihenfolge oder ein klickbares div.
Muss auch die Administration des Blocks getestet werden?
Ja. Redakteure nutzen möglicherweise Tastatur, Zoom oder einen Screenreader. Inserter, Inspector Controls, Verschachtelung und Fehlerzustände müssen genauso zugänglich sein wie die öffentliche Ausgabe.
Sollte der Alternativtext eines Bildes immer Pflicht sein?
Nein. Ein informatives Bild braucht einen aussagekräftigen Alternativtext, ein dekoratives sollte eine leere Alternative haben und ignoriert werden. Der Editor muss es Redakteuren ermöglichen, den Zweck korrekt anzugeben.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
