powered by 
Eine Website ist barrierefrei, wenn alle sie benutzen können: wer nicht sieht und sie sich vorlesen lässt, wer nur die Tastatur benutzt, wer Farben schlecht unterscheidet, wer die Schrift groß braucht oder nicht hört, was ein Video sagt. Hier stehen die wichtigsten Regeln, was das Gesetz dazu sagt und wie du deine eigene Seite prüfst.
Menschen benutzen das Internet auf sehr verschiedene Weise. Wer blind ist, hört die Seite von einem Screenreader, einem Programm, das vorliest, was auf ihr steht, und springt mit der Tastatur von Überschrift zu Überschrift. Wer die Maus nicht halten kann, bedient alles mit der Tastatur oder mit der Stimme. Wer schlecht sieht, vergrößert die Seite auf das Doppelte oder mehr. Und viele Barrieren treffen alle einmal: helle Sonne auf dem Bildschirm, ein Video in der Bahn ohne Ton, ein gebrochener Arm.
Barrierefreiheit ist darum keine Zugabe für wenige. Sie entsteht beim Bauen: mit dem richtigen HTML-Element, einem Text für jedes Bild, genug Kontrast. Hinterher lässt sie sich nur mühsam nachrüsten.
Die Regeln dafür stehen in den Web Content Accessibility Guidelines (WCAG) des W3C, heute in der Fassung 2.2. Sie haben drei Stufen, A, AA und AAA; Gesetze verlangen meist AA.
Die WCAG ordnen ihre Regeln nach vier Grundsätzen. In Klammern steht die Nummer der Regel in den WCAG 2.2 und ihre Stufe.
| Regel | Was sie verlangt |
|---|---|
| Wahrnehmbar: alles, was die Seite zeigt, kommt auch an, wenn man es nicht sieht oder hört | |
| Text für Bilder 1.1.1, A |
Jedes Bild hat ein alt, das sagt, was es zeigt; ein Bild nur zur Zierde hat alt="", damit der Screenreader es überspringt. |
| Untertitel 1.2.2, A |
Ein Video mit Ton hat Untertitel. |
| Kontrast 1.4.3, AA |
Text hebt sich mindestens 4,5 : 1 vom Hintergrund ab, großer Text (ab 18 Punkt, fett ab 14) mindestens 3 : 1. |
| Nicht nur Farbe 1.4.1, A |
Was eine Farbe sagt, sagt auch noch etwas anderes: ein Fehler ist rot und hat ein Zeichen oder ein Wort, ein Link ist blau und unterstrichen. |
| Vergrößern 1.4.4 und 1.4.10, AA |
Auf das Doppelte vergrößert und auf 320 Pixel Breite geht nichts verloren und nichts muss seitwärts geschoben werden. |
| Bedienbar: alles lässt sich bedienen, auch ohne Maus | |
| Tastatur 2.1.1, A |
Jeder Link, Knopf und jedes Feld ist mit Tab erreichbar und mit Enter oder der Leertaste zu benutzen. |
| Fokus sichtbar 2.4.7, AA |
Man sieht, wo man mit der Tastatur gerade ist; outline: none ohne Ersatz nimmt das weg. |
| Große Klickflächen 2.5.8, AA |
Was man anklickt oder antippt, ist mindestens 24 × 24 Pixel groß oder hat so viel Abstand zum nächsten. |
| Verständlich: man weiß, was die Seite tut und was sie will | |
| Sprache 3.1.1, A |
<html lang="de">: Der Screenreader liest dann deutsch vor, nicht mit englischer Aussprache. |
| Beschriftungen 3.3.2, A |
Jedes Eingabefeld hat ein <label>, das sagt, was hinein soll. |
| Robust: Browser und Hilfsprogramme verstehen, was auf der Seite ist | |
| Das richtige Element 4.1.2, A |
Ein Knopf ist ein <button>, ein Link ein <a href>, eine Überschrift ein <h2>: Nur dann wissen Screenreader, was es ist, und die Tastatur kommt hin. Ein <div> mit onclick kann das alles nicht von selbst. |
Eine Rot-Grün-Schwäche ist häufig: In Europa hat sie etwa jeder zwölfte Mann. Wer sie hat, sieht Rot und Grün als ähnliche Brauntöne. Eine Liste, in der nur ein grüner oder ein roter Punkt sagt, was gelöst ist, sagt dann nichts mehr, und ein Feld, dessen Fehler nur ein roter Rahmen zeigt, sieht aus wie jedes andere. Ein Zeichen und ein Wort dazu gehen nicht verloren, auch nicht in Grau, auf einem schlechten Beamer oder beim Ausdruck.
Wie gut sich Text vom Hintergrund abhebt, misst das Kontrastverhältnis: von 1 : 1, Grau auf demselben Grau, bis 21 : 1, Schwarz auf Weiß. Helles Grau auf Weiß sieht auf einem guten Bildschirm elegant aus, auf dem Handy in der Sonne ist es kaum zu lesen.
Ein Screenreader sieht die Seite nicht, er liest ihr HTML. Was dort nicht steht,
erfährt niemand, der ihm zuhört. Aus <img src="rocket.png"> wird etwa
»Grafik: rocket«, der Name der Datei; mit alt="Eine Rakete beim Start" wird
daraus »Grafik: Eine Rakete beim Start«. Ein <div onclick> liest er wie
jeden anderen Text vor, ohne zu sagen, dass man es anklicken kann, und mit der
Tastatur kommt man nicht hin; ein <button> heißt »Schalter«, und
Tab erreicht ihn.
Ausprobieren kannst du das alles im Labor Fair, barrierefrei, sicher: eine Seite mit anderen Augen sehen, lesen, was ein Screenreader aus ihr macht, den Kontrast selbst ausrechnen und die Barrieren einer Seite Schritt für Schritt ausbauen.
Die Elemente erklärt die Seite HTML, das Aussehen CSS.
<!DOCTYPE html> <html lang="de"> <head> <meta charset="utf-8"> <title>Anmeldung zur Hacker-AG</title> </head> <body> <h1>Anmeldung zur Hacker-AG</h1> <img src="ag.jpg" alt="Sechs Lernende an Laptops, einer zeigt auf seinen Bildschirm"> <h2>Deine Angaben</h2> <form> <label for="name">Dein Name</label> <input id="name" type="text" autocomplete="name"> <button type="submit">Anmelden</button> </form> </body> </html>
lang="de" sagt dem Screenreader die Sprache.h1 dann h2; wer nicht sieht,
springt an ihnen entlang durch die Seite.for und id verbinden die Beschriftung mit dem Feld: Ein Klick auf »Dein
Name« setzt den Cursor hinein, und der Screenreader liest sie vor.<button> ist mit der Tastatur erreichbar und sagt, dass er ein
Knopf ist.Dazu gehört etwas CSS:
:focus-visible { outline: 3px solid #1a5fb4; outline-offset: 2px; } @media (prefers-reduced-motion: reduce) { * { animation: none !important; transition: none !important; } }
Der Rahmen zeigt, wo die Tastatur gerade ist, und wer im System »weniger Bewegung« eingestellt hat, bekommt keine Animationen, die schwindlig machen können.
alt, Beschriftungen und zu wenig Kontrast;
der Barrierefreiheits-Inspektor von Firefox zeigt, was ein Screenreader von
jedem Element erfährt. Was ein Werkzeug nicht findet, ist damit noch nicht
in Ordnung: Ob ein alt das Bild wirklich beschreibt, sieht nur ein
Mensch.