Ressourcen

Dieser Bereich ist die Werkzeugkiste der Website: fünf Werkzeuge, die direkt im Browser laufen, dazu erprobte Code-Bausteine, Checklisten, ausfüllfertige Vorlagen, ein Glossar und eine kommentierte Tool-Liste. Während die anderen Bereiche das Warum erklären, geht es hier ums Ausprobieren, Nachschlagen und Mitnehmen.

Das Wichtigste in Kürze

• Alle Bausteine hier folgen denselben Prinzipien wie der Rest der Seite: natives HTML zuerst, so wenig ARIA wie möglich, und jedes Beispiel stammt aus einem echten Einsatz statt aus der Theorie.
• Die Snippets sind framework-frei. Kein Build-Schritt, keine Abhängigkeit – kopieren, einfügen, an das eigene CSS anpassen.
• Der Bereich ist seit August 2026 zweigeteilt: Werkzeuge zum Etwas-Tun (Struktur-Check, Kontrast-Check, Alt-Text-Entscheidungshilfe, Komponenten-Baukasten, BFSG-Schnelltest) und Nachschlagen zum Etwas-Finden (Snippets, Checklisten, Glossar, Vorlagen, Tool-Listen).
• Zwei Werkzeuge nehmen eine URL entgegen: Der Struktur-Check prüft die Auszeichnung gegen zwölf eindeutig entscheidbare WCAG-Punkte, der Kontrast-Check misst die tatsächlich gerenderten Farbwerte.
• Zwei weitere laufen ganz ohne Server: Die Alt-Text-Entscheidungshilfe klärt in drei Fragen, was ins alt gehört, der Komponenten-Baukasten stellt acht schwere Muster im Variantenvergleich mit Testprotokoll bereit.
• Die Muster-Barrierefreiheitserklärung gibt es in zwei Fassungen – eine für Unternehmen nach BFSG, eine für öffentliche Stellen nach BITV – jeweils mit Ausfüllhinweisen.
• Das Glossar klärt die Begriffe, die in Ausschreibungen und Angeboten regelmäßig durcheinandergehen: Accessibility Tree, Landmark, Rolle, Konformitätsstufe, BITV, EN 301 549.
• Die Tool-Liste benennt auch die Grenzen: Kein automatisches Werkzeug prüft, ob ein Alternativtext passt oder ob eine Fehlermeldung verständlich ist.
• Was hier steht, ersetzt keine Prüfung. Es verkürzt den Weg dorthin.

Was du hier findest

In der Snippet-Bibliothek sammle ich Code-Bausteine zum Kopieren: ein visuell verstecktes Label, einen Skip-Link, ein barrierefreies Icon-Button-Muster, <details> als Akkordeon, einen <dialog> und mehr – jeweils mit kurzer Erklärung, warum sie so und nicht anders aufgebaut sind. Diese Begründung ist der eigentliche Punkt: Ein kopiertes Snippet, dessen Aufbau man nicht versteht, überlebt die erste Designänderung nicht.

Die Cheat-Sheets und Checklisten verdichten das, was man immer wieder braucht, auf eine überfliegbare Form – gedacht für den Moment kurz vor dem Livegang, nicht fürs Lernen.

Fünf Werkzeuge beantworten häufige Fragen direkt im Browser. Der BFSG-Schnelltest klärt in vier Fragen, ob ein Angebot überhaupt unter das Gesetz fällt – die häufigste Frage, die mir gestellt wird, und eine, die sich ohne Jurist beantworten lässt, solange es nur um den Anwendungsbereich geht. Der Struktur-Check und der Kontrast-Check nehmen beide eine URL entgegen: der eine prüft die Auszeichnung, der andere die tatsächlich gerenderten Farbwerte. Damit fallen genau die Fälle auf, die man beim Abtippen aus dem Designentwurf übersieht – Text auf einem Verlauf, ein Hover-Zustand, eine Farbe, die im Dark Mode kippt. Und zwei Werkzeuge kommen ganz ohne Server aus: Die Alt-Text-Entscheidungshilfe klärt, ob ein Bild eine Beschreibung braucht, der Komponenten-Baukasten zeigt für acht schwere Muster, was die Wahl zwischen nativ und ARIA jeweils kostet.

Die Muster-Barrierefreiheitserklärung liefert ausfüllfertige Vorlagen für Unternehmen und öffentliche Stellen. Der wichtigste Teil daran sind die Ausfüllhinweise: Eine Erklärung, die vorhandene Lücken benennt und einen Zeitplan nennt, steht besser da als eine, die pauschal Konformität behauptet – im Zweifel auch rechtlich.

Wenn ein Begriff unterkommt, den ich an anderer Stelle als bekannt voraussetze, hilft das Glossar: von ARIA über die Dokument-Outline bis zu WCAG, kurz und ohne Fachchinesisch. Und unter Tools stehen die Programme und Dienste, mit denen ich prüfe – von axe und WAVE über Lighthouse bis zu Screenreadern wie NVDA, jeweils mit einer Einordnung, was sie zuverlässig finden und was nicht.

Wie ich diese Sammlung nutze

Nicht als Lernmaterial, sondern als Abkürzung. Der typische Ablauf sieht so aus: Beim Bauen greife ich zum Snippet, weil ich das Muster kenne, aber die genaue Attributschreibweise nicht auswendig weiß. Kurz vor dem Livegang gehe ich die Checkliste durch. Wenn eine Farbe strittig ist, lasse ich den Kontrast-Check über die Staging-URL laufen, statt Werte aus dem Entwurf abzutippen. Und wenn im Kundengespräch ein Begriff fällt, den alle unterschiedlich verstehen, schicke ich den Glossareintrag.

Was bewusst nicht hier steht: vollständige Komponenten mit Styling, fertige Themes, Bibliotheken zum Einbinden. Solche Pakete lösen ein Problem und schaffen zwei neue – eine Abhängigkeit und die Illusion, das Thema sei damit erledigt. Die Bausteine hier sind absichtlich klein genug, dass man sie liest, bevor man sie einsetzt.

Ein Hinweis zur Erwartung: Kein Werkzeug auf dieser Seite ersetzt eine Prüfung. Der BFSG-Schnelltest klärt den Anwendungsbereich, keine Rechtsfrage im Einzelfall. Der Kontrast-Check misst Kontraste, keine Konformität. Und eine Checkliste, die abgehakt ist, bedeutet, dass die geprüften Punkte stimmen – nicht, dass eine Seite barrierefrei ist. Das klingt kleinlich, verhindert aber die häufigste Enttäuschung: dass jemand ein grünes Ergebnis für ein Zeugnis hält.

Häufige Fragen

Darf ich die Snippets in kommerziellen Projekten verwenden?

Ja, ohne Einschränkung und ohne Namensnennung. Es handelt sich um kurze, naheliegende Umsetzungen etablierter Muster – daran besitzt niemand sinnvoll Rechte. Was ich empfehle: die Erklärung mitlesen, bevor der Code ins Projekt wandert, und beim Anpassen prüfen, ob die Begründung noch trägt.

Sind die Beispiele auf ein bestimmtes Framework ausgelegt?

Nein, sie sind bewusst reines HTML, CSS und – wo nötig – etwas JavaScript ohne Abhängigkeiten. In React, Vue oder Svelte übersetzt sich das direkt; nur die Attributschreibweise ändert sich, in React etwa htmlFor statt for. Die Semantik bleibt in jedem Fall dieselbe.

Wie aktuell sind die Angaben zu Recht und Fristen?

Jede Seite trägt ein sichtbares Änderungsdatum, und Aussagen, die sich ändern können, sind im Text mit ihrem Stand versehen. Bei Rechtsthemen gilt zusätzlich: Ich bin Webdesigner, kein Jurist – die Texte ordnen die Lage aus der Praxis ein und ersetzen keine Beratung.

Warum gibt es kein fertiges Barrierefreiheits-Plugin?

Weil es das nicht geben kann. Ob eine Überschriftenebene stimmt, ob ein Alternativtext den Bildinhalt beschreibt oder ob eine Reihenfolge sinnvoll ist, hängt vom Inhalt ab – nicht vom Code drumherum. Werkzeuge, die pauschale Barrierefreiheit versprechen, legen in der Regel eine Schicht über die Seite, während die eigentlichen Probleme im Markup bestehen bleiben.

Ich vermisse eine Ressource – kann ich etwas vorschlagen?

Gern. Ich erweitere die Sammlung, wenn mir im Projektalltag etwas begegnet, das ich beim nächsten Mal nicht wieder zusammensuchen möchte – Vorschläge von außen gehören ausdrücklich dazu. Ein kurzer Hinweis über die Kontaktseite genügt.