Ressourcen · Nachschlagen
Cheat-Sheets & Checklisten
Die ausführlichen Artikel dieser Website erklären das Warum. Diese Seite ist für die Momente, in denen man das Warum schon kennt und nur noch schnell nachsehen will: Welches Element wofür? Welcher Kontrast reicht? Was muss vor dem Launch noch geprüft werden?
Das Wichtigste in Kürze
- Neun Spickzettel auf einer Seite: Semantik, Überschriften, Formulare, Kontrast, Tastatur, POUR, Rechtsstrang, Launch-Audit und SEO – jeder mit Rückverweis auf den Artikel mit der Begründung.
- Die AA-Kontrastwerte in einem Satz: 4,5 : 1 für normalen Text, 3 : 1 für großen Text ab 24 px – oder ab 18,7 px, wenn er fett gesetzt ist – sowie für Bedienelemente und aussagekräftige Grafiken.
- Der Tastatur-Check hat vier Punkte: alles erreichbar, Fokus sichtbar, Reihenfolge logisch, keine Falle. Er findet in fünf Minuten mehr als jedes automatische Werkzeug.
- Der Rechts-Check unterscheidet die beiden Stränge: Unternehmen fallen unter das BFSG, öffentliche Stellen unter BITV bzw. Landesrecht. Der technische Maßstab – WCAG AA über die EN 301 549 – ist in beiden derselbe.
- Das Kurz-Audit vor dem Launch hat sechs Schritte und beginnt bewusst mit dem Werkzeug, aber endet bei der inhaltlichen Prüfung: Tools finden rund ein Drittel.
- Checklisten ersetzen kein Verständnis. Sie verhindern Flüchtigkeitsfehler – und genau dafür sind sie hier.
- Die Seite ist zum Ausdrucken gebaut; ein paar dieser Listen hängen bei mir tatsächlich neben dem Monitor.
Semantik-Spickzettel: welches Element wofür?
| Brauche ich … | … nehme ich |
|---|---|
| den Kopfbereich / die Hauptnavigation | <header>, <nav> |
| den zentralen, einzigartigen Inhalt | <main> (genau einmal) |
| einen für sich stehenden Beitrag | <article> |
| einen thematischen Abschnitt mit Überschrift | <section> |
| ergänzenden Randinhalt | <aside> |
| den Fußbereich | <footer> |
| eine Aktion (etwas passiert) | <button> |
| einen Verweis (es geht woanders hin) | <a href> |
| eine Aufzählung / Reihenfolge | <ul> / <ol> |
| Begriff-Erklärung-Paare | <dl> |
| Bild mit Bildunterschrift | <figure> + <figcaption> |
| reinen Layout-Container ohne Bedeutung | <div> / <span> |
Im Detail: Struktur-Elemente, article vs. section und div vs. span.
Überschriften-Check
- Genau eine
<h1>pro Seite, die das Thema benennt. - Keine Ebene überspringen (nach
<h2>kommt<h3>, nicht<h4>). - Die Hierarchie folgt der Bedeutung, nicht der Schriftgröße.
- Größe und Optik macht CSS – nicht die Wahl der Überschriftenebene.
Mehr: Überschriften-Hierarchie.
Formular-Check
- Jedes Feld hat ein verknüpftes
<label for>– kein Platzhalter als Ersatz. - Zusammengehörige Felder stehen in
<fieldset>mit<legend>. - Pflichtfelder sind im Text gekennzeichnet, nicht nur per Farbe.
- Fehler stehen am Feld, sind per
aria-describedbyverknüpft und im Klartext. - Passendes
autocompleteundtype(email,tel, …) sind gesetzt.
Details: Labels, Fehlermeldungen, Validierung und fieldset & legend.
Kontrast-Richtwerte
| Inhalt | Mindestkontrast |
|---|---|
| Normaler Text (< 24 px, bzw. < 18,66 px fett) | 4,5 : 1 |
| Großer Text (≥ 24 px, bzw. ≥ 18,66 px fett) | 3 : 1 |
| Bedienelemente & aussagekräftige Grafiken | 3 : 1 |
Das sind die AA-Werte. Wie man sie misst und einstellt: Farbkontraste.
Tastatur-Check
- Alles, was per Maus geht, geht auch per Tab / Shift+Tab / Enter / Leertaste.
- Der Fokus ist immer sichtbar (kein
outline: noneohne Ersatz). - Die Reihenfolge ist logisch und folgt der Leserichtung.
- Es gibt keine Tastaturfalle, aus der man nicht mehr herauskommt.
Mehr: Tastatur & Fokus.
WCAG in vier Worten: POUR
- Wahrnehmbar – Inhalte sind seh-, hör- oder ertastbar (Alt-Texte, Kontrast).
- Bedienbar – alles geht per Tastatur, nichts erzwingt die Maus.
- Verständlich – Sprache, Aufbau und Verhalten sind vorhersehbar.
- Robust – sauberes Markup, das Browser und Hilfsmittel zuverlässig deuten.
Mehr: Die vier Prinzipien (POUR), Konformitätsstufen A / AA / AAA – und zum Nachschlagen jedes einzelnen Kriteriums die WCAG-Referenz (alle A & AA).
Rechts-Check: BFSG oder BITV?
- Zuständigkeit geklärt: Unternehmen → BFSG; öffentliche Stelle → BITV/Landesrecht. Im Zweifel: BFSG-Schnelltest durchklicken.
- Technischer Maßstab: WCAG AA über EN 301 549 – gilt in beiden Strängen.
- Dokumentation: Barrierefreiheits-Informationen bzw. Erklärung veröffentlicht (Muster-Vorlagen), Feedback-Weg benannt.
- Fristen & Ausnahmen geprüft: privat bzw. öffentlich.
- Jahres-Termin gesetzt: Retest + „zuletzt geprüft“-Datum der Erklärung aktualisieren.
Kurz-Audit vor dem Launch
- axe / Lighthouse laufen lassen, offensichtliche Fehler beheben.
- Tastatur-Durchlauf der wichtigsten Seiten und Abläufe.
- Zoom auf 200 % / Reflow prüfen.
- Kontraste der kritischen Stellen messen.
- Screenreader-Stichprobe – Schritt für Schritt mit NVDA oder VoiceOver.
- Inhaltliche Prüfung für alles, was Tools nicht sehen.
Diese Runde lasse ich vor keinem Launch aus – Schritt für Schritt unter Barrierefreiheit selbst testen. Die ausführliche gesetzliche Variante ist die BFSG-Checkliste.
SEO-Quick-Wins
- Aussagekräftiger
<title>und<meta name="description">je Seite. - Eine
<h1>und eine saubere Überschriften-Struktur (= halbe SEO-Miete). - Sprechende, stabile URLs.
- Strukturierte Daten dort, wo sie passen.
- Sinnvolle Alt-Texte.
- Tempo im Blick behalten (Core Web Vitals).
Warum dieselbe Struktur Suche und KI hilft: Semantik & SEO.
Häufige Fragen
Reicht es, alle Punkte dieser Checklisten abzuhaken?
Nein, und das ist keine falsche Bescheidenheit. Diese Listen decken die häufigsten Fehlerquellen ab, nicht alle 55 A/AA-Kriterien. Für den vollständigen Abgleich gibt es die WCAG-Kriterien-Referenz; für den gesetzlichen Rahmen die BFSG-Checkliste. Eine abgehakte Liste bedeutet: Die geprüften Punkte stimmen.
Kann ich die Checklisten in meinem Projekt weiterverwenden?
Ja. Nimm sie ins Teamwiki, ins Ticketsystem oder in die Definition of Done – dafür sind sie geschrieben. Ich freue mich über einen Rückverweis, verlange ihn aber nicht. Was du nicht tun solltest: sie als Konformitätsnachweis gegenüber Dritten ausgeben.
In welcher Reihenfolge arbeite ich die Listen ab?
Bei bestehenden Seiten von hinten: erst das Kurz-Audit vor dem Launch, weil es die größten Brocken findet. Bei neuen Seiten von vorn – Semantik zuerst, weil jede spätere Korrektur an Formularen, Tastatur und Screenreader-Ausgabe auf dem Markup aufsetzt.
Warum stehen SEO-Punkte auf einer Barrierefreiheits-Seite?
Weil sie sich überschneiden: Eine <h1> je Seite, eine saubere Überschriften-Struktur und sinnvolle Alt-Texte sind für beide Zwecke dieselbe Arbeit. Der Zusammenhang steht unter Semantik & SEO – doppelt zu arbeiten wäre die eigentliche Verschwendung.
Fazit
Checklisten ersetzen kein Verständnis, aber sie verhindern Flüchtigkeitsfehler – und genau dafür sind sie da. Tipp: Die Seite lässt sich sauber ausdrucken, wenn man eine Papierversion neben den Bildschirm legen möchte. Den passenden Code zu vielen Punkten gibt es in der Snippet-Bibliothek, unbekannte Begriffe klärt das Glossar, und die Werkzeuge dazu stehen unter Tools.