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 verweist zurück 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 nur Flüchtigkeitsfehler.
- 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. Wo diese Werte im Stylesheet landen, sammelt der Bereich CSS.
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.