Best Practices

Konkrete Empfehlungen für barrierefreie Websites, gruppiert nach Themen — als Checkliste für Design und Entwicklung.

Farbe & Kontrast

Text und Hintergrund brauchen mindestens 4.5:1 Kontrast (3:1 bei großer Schrift ab 24px bzw. 19px fett).
Informationen nie ausschließlich über Farbe vermitteln (z. B. Fehler nur rot markieren) — zusätzlich Text, Icon oder Muster nutzen.
Kontrast auch bei Hover-, Fokus- und Platzhaltertexten in Formularfeldern prüfen.
Mit einem Kontrast-Checker gegen den tatsächlich gerenderten Hintergrund testen, nicht nur gegen die Designvorlage.

Informative Bilder brauchen einen aussagekräftigen Alternativtext, der den Zweck beschreibt, nicht nur das Motiv.
Rein dekorative Bilder erhalten ein leeres alt="", damit Screenreader sie überspringen.
Videos brauchen Untertitel, Audioinhalte nach Möglichkeit ein Transkript.
Bei komplexen Grafiken (Diagramme, Infografiken) den Inhalt zusätzlich als Text bereitstellen.

Alle interaktiven Elemente müssen per Tab erreichbar und per Enter/Leertaste bedienbar sein.
Der Fokus muss immer sichtbar sein — Standard-Fokusrahmen nicht per CSS entfernen, ohne eine gleichwertige Alternative zu setzen.
Die Tab-Reihenfolge sollte der visuellen/logischen Reihenfolge der Seite entsprechen.
Ein Sprunglink („Zum Hauptinhalt springen") am Seitenanfang erspart wiederholtes Durchtabben der Navigation.
Keine Tastaturfallen: Aus jedem Element (z. B. einem Modal) muss man per Tastatur wieder herauskommen.

Genau eine h1 pro Seite, Überschriftenebenen ohne Sprünge (h2 folgt auf h1, nicht h2 direkt auf h4).
Seitenbereiche mit semantischen Landmarks gliedern: main, nav, header, footer statt generischer <div>s.
Native HTML-Elemente statt nachgebauter Interaktivität verwenden — <button> statt klickbarem <div>, <a href> statt onClick auf <span>.
Sprache des Dokuments im <html lang="…">-Attribut korrekt setzen.

Jedes Formularfeld braucht ein sichtbares, programmatisch verknüpftes <label> — Platzhaltertext allein reicht nicht.
Pflichtfelder und Formatanforderungen (z. B. Datumsformat) vor dem Absenden klar kommunizieren, nicht nur per Farbe.
Fehlermeldungen konkret und mit dem betroffenen Feld verknüpft ausgeben (z. B. via aria-describedby), nicht nur als allgemeiner Banner.
Zusammengehörige Felder (z. B. Adresse) mit <fieldset> und <legend> gruppieren.

Links und Buttons brauchen einen Text, der ihren Zweck auch außerhalb des Kontexts verständlich macht — nicht nur „Hier klicken" oder „Mehr".
Touch-Ziele auf Mobilgeräten mindestens 24×24 Pixel groß und mit ausreichend Abstand zueinander gestalten.
Bei Icon-only-Buttons einen zugänglichen Namen per aria-label ergänzen.
Zustände (ausgewählt, deaktiviert, ausgeklappt) sowohl visuell als auch über ARIA-Attribute (aria-expanded, aria-selected, aria-disabled) kommunizieren.

Automatisierte Scans wie diesen regelmäßig in den Entwicklungsprozess einbauen, idealerweise vor jedem Release.
Automatisierte Ergebnisse durch manuelle Tastatur- und Screenreader-Tests ergänzen (z. B. NVDA, VoiceOver).
Nach Möglichkeit echtes Nutzerfeedback von Menschen einholen, die assistierende Technologien einsetzen.
Barrierefreiheit von Anfang an mitdenken (Design, Konzeption), nicht erst kurz vor dem Launch nachbessern.