Mit welchem Fundament fängt eine barrierefreie Website an?
Mit sauberem, semantischem HTML. Echte Überschriften, Listen, Buttons und Landmarks geben dem Inhalt eine Struktur, die assistive Technologien verstehen. Wer von Beginn an semantisch arbeitet, erfüllt einen großen Teil der WCAG-Kriterien automatisch – noch bevor es um Design oder Plugins geht.
Struktur und Navigation
Jede Seite braucht genau eine H1 und eine logische Überschriftenhierarchie ohne Sprünge. Navigation und wichtige Bereiche werden über Landmarks (header, nav, main, footer) ausgezeichnet. Ein „Zum Inhalt springen”-Link am Seitenanfang hilft Tastaturnutzern, sich wiederholende Navigation zu überspringen.
Farben, Kontraste und Schrift
Normaler Text braucht ein Kontrastverhältnis von mindestens 4,5:1, große Schrift 3:1. Informationen dürfen nie allein über Farbe vermittelt werden – ein roter Rahmen am Fehlerfeld braucht zusätzlich Text oder Symbol. Texte müssen sich auf 200 Prozent vergrößern lassen, ohne dass Inhalt verloren geht.
Tastatur und Fokus
Alles, was per Maus geht, muss auch per Tastatur funktionieren: Menüs, Formulare, Slider, Dialoge. Der Tastaturfokus muss immer sichtbar sein und einer sinnvollen Reihenfolge folgen. Versteckte Bedienelemente oder „Tastaturfallen”, aus denen man nicht heraustabbt, sind häufige und schwere Fehler.
Bilder, Formulare und Medien
Jedes informative Bild bekommt einen Alternativtext, dekorative Bilder ein leeres alt-Attribut. Formularfelder brauchen sichtbare, programmatisch verknüpfte Labels und klare Fehlermeldungen. Videos benötigen Untertitel, Audio-Inhalte ein Transkript. Diese Punkte gehören in jede Redaktions-Checkliste.
Testen vor dem Launch
Prüfen Sie vor der Veröffentlichung mit einem automatischen Tool (z. B. axe), einem reinen Tastaturdurchlauf und einem Screenreader. friendlyuse automatisiert den wiederkehrenden Teil dieser Prüfung, erkennt neue Barrieren nach Änderungen und dokumentiert den Stand – als Nachweis und als To-do-Liste fürs Team.