Web-Barrierefreiheit: Tastatur, ARIA und Kontrast

Web-Barrierefreiheit bedeutet, eine Oberfläche so zu bauen, dass auch Menschen mit visuellen, auditiven, motorischen oder kognitiven Unterschieden sie reibungslos nutzen können. Viele Entwickler sehen darin nur ein rechtliches Häkchen oder ein „Extra“, das man am Ende dranhängt. Tatsächlich ist Barrierefreiheit eine grundlegende Praxis, die — von Anfang an richtig umgesetzt — auch Codequalität, SEO und die allgemeine Bedienbarkeit verbessert. Dieser Leitfaden konzentriert sich auf die drei Bereiche mit dem größten Effekt: Tastaturnavigation, korrekter ARIA-Einsatz und Farbkontrast.

Warum Barrierefreiheit Pflicht ist, kein Bonus

Ein erheblicher Teil der Bevölkerung lebt mit einer dauerhaften oder vorübergehenden Behinderung, aber Barrierefreiheit ist nicht nur für diese Menschen da. Ein in der Sonne spiegelndes Display, eine kaputte Maus, ein stummgeschaltetes Video, müde Augen — jeder surft manchmal in einem „eingeschränkten“ Kontext. Eine barrierefreie Seite hilft Nutzern von Screenreadern und Tastatur und gibt Suchmaschinen zugleich eine bedeutungsvollere Struktur.

• Semantisches HTML erledigt rund 80 % der Arbeit: das richtige Tag macht die richtige Aufgabe.
• WCAG (Web Content Accessibility Guidelines) gibt ein messbares Ziel; die meisten Organisationen nehmen Stufe AA als Referenz.
• Barrierefreier Code ist meist robuster und leichter zu warten.

Semantisches HTML: das Fundament der Barrierefreiheit

Der häufigste Fehler ist, alles aus <div> und <span> zu bauen. Der Browser weiß nicht, dass ein <div> klickbar ist, und ein Screenreader kündigt es nicht an. Das richtige Element zu verwenden liefert Tastaturverhalten, Fokusverwaltung und Screenreader-Ansagen gratis.

<!-- Schlecht: Barrierefreiheit muss manuell ergänzt werden -->
<div class="btn" onclick="speichern()">Speichern</div>

<!-- Gut: Tastatur, Fokus und Rolle sind eingebaut -->
<button type="button" onclick="speichern()">Speichern</button>

Dieselbe Logik gilt für <nav>, <main>, <header>, <footer> und Formularfelder. Jedes <input> sollte mit einem <label> verbunden sein:

<label for="email">E-Mail</label>
<input id="email" type="email" name="email">

Tastaturnavigation: es muss ohne Maus funktionieren

Eine Oberfläche mit der Tastatur zu testen ist die schnellste Barrierefreiheitsprüfung überhaupt. Vorwärts mit Tab, rückwärts mit Shift+Tab: Erreichen Sie jeden Link, jede Schaltfläche und jedes Formularfeld? Ist der Fokus sichtbar?

• Entfernen Sie den Fokusring niemals mit outline: none. Passt er nicht zum Design, gestalten Sie ihn ansprechend mit :focus-visible.
• Nutzen Sie die DOM-Reihenfolge für eine logische Abfolge und vermeiden Sie positive tabindex-Werte. Nur tabindex="0" (in die Reihenfolge aufnehmen) und tabindex="-1" (programmatischer Fokus) sind nötig.
• Wenn ein Modal öffnet, fangen Sie den Fokus darin ein und geben Sie ihn beim Schließen an die auslösende Schaltfläche zurück.

/* Ein klarer Fokusring nur für Tastaturnutzer */
:focus-visible {
  outline: 2px solid #4f46e5;
  outline-offset: 2px;
}

Ein Sprunglink (Skip-Link) ist ebenfalls eine große Hilfe für Tastaturnutzer:

<a class="skip-link" href="#main">Zum Inhalt springen</a>
...
<main id="main"> ... </main>

ARIA: weniger ist mehr

ARIA (Accessible Rich Internet Applications) dient dazu, Screenreadern Zustände mitzuteilen, die HTML allein nicht ausdrücken kann. Doch die goldene Regel ist eindeutig: kein ARIA ist besser als schlechtes ARIA. Eine falsche role oder ein falscher Zustand zerstört ansonsten korrektes semantisches HTML.

• Erledigt ein natives HTML-Element die Aufgabe, fügen Sie kein ARIA hinzu: role="button" auf einem <button> ist überflüssig.
• Geben Sie Icon-Schaltflächen ohne Text einen barrierefreien Namen: aria-label="Menü öffnen".
• Kündigen Sie den Zustand an: aria-expanded="true/false" bei einem Dropdown, aria-selected beim aktiven Tab.
• Kündigen Sie Live-Updates mit aria-live="polite" an (etwa eine Formular-Fehlermeldung).

<button aria-label="Menü öffnen" aria-expanded="false" aria-controls="menu">
  <svg aria-hidden="true"> ... </svg>
</button>
<ul id="menu" hidden> ... </ul>

Bei rein dekorativen Bildern lassen Sie alt="" oder verwenden aria-hidden="true", damit Screenreader sie überspringen. Bei bedeutungstragenden Bildern ist ein beschreibender alt-Text unverzichtbar.

Farbe und Kontrast: Lesbarkeit für alle

Geringer Kontrast ist das häufigste und am leichtesten behebbare Barrierefreiheitsproblem. WCAG-Stufe AA verlangt ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (18,66px fett oder 24px). Auch UI-Komponenten und grafische Elemente sollten 3:1 anstreben.

• Die DevTools Ihres Browsers zeigen das Kontrastverhältnis und den AA/AAA-Status, wenn Sie Text auswählen.
• Vermitteln Sie Informationen nie allein über Farbe. Statt „das rote Feld ist ungültig“ ergänzen Sie ein Icon, Text oder Muster — entscheidend für farbenblinde Nutzer.
• Heben Sie Links mit einem zweiten Hinweis hervor, etwa Unterstreichung oder Fettung, nicht nur per Farbe.
• Reduzieren Sie Animationen für bewegungsempfindliche Nutzer mit prefers-reduced-motion.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Testen: Werkzeuge und Menschen zusammen

Automatische Werkzeuge erfassen nur einen Teil der Probleme; der Rest braucht echte Erfahrung.

• Führen Sie einen schnellen Scan mit Lighthouse oder axe DevTools durch.
• Navigieren Sie die ganze Seite mit der Tastatur: Bleiben Sie irgendwo hängen?
• Probieren Sie einen Screenreader: VoiceOver auf macOS und NVDA auf Windows sind kostenlos.
• Zoomen Sie die Seite auf 200 %; fließt der Inhalt ohne zu brechen?

Häufige Fragen

Sollte ich WCAG AA oder AAA anstreben?

Für die meisten Projekte ist Stufe AA das praktikable und weithin akzeptierte Ziel, und viele rechtliche Rahmen verweisen ebenfalls darauf. AAA ist bei einigen Kriterien sehr streng und für jeden Inhalt nicht realistisch, aber es ist gut, es dort anzuwenden, wo es möglich ist.

Kann ARIA semantisches HTML ersetzen?

Nein. ARIA bereichert nur die Bedeutung dort, wo HTML nicht ausreicht; es fügt kein Verhalten hinzu. Selbst wenn Sie einem <div> eine role="button" geben, müssen Sie Tastaturereignisse und Fokus weiterhin selbst implementieren. Das richtige Element ist immer sicherer.

Hilft Barrierefreiheit dem SEO?

Ja. Semantische Struktur, alt-Texte, eine logische Überschriftenhierarchie und klar lesbarer Inhalt geben Screenreadern und Suchmaschinen dieselbe Klarheit; beide überschneiden sich stark.

Eine barrierefreie Oberfläche ist schlicht eine bessere Oberfläche. Wenn Sie Ihre Seite auf Tastatur, ARIA und Kontrast prüfen lassen oder sie von Anfang an barrierefrei aufbauen möchten, nehmen Sie Kontakt mit mir auf.