Aktualisiert: März 2026 · Lesezeit: 14 Min.
Letzte Woche habe ich den Online-Shop eines Kunden in Köln getestet. Einfach mal mit geschlossenen Augen und eingeschaltetem Screenreader. Nach drei Minuten wollte ich aufgeben. Der Warenkorb-Button war nicht mal auffindbar. Das Menü ein Labyrinth aus <div>-Elementen ohne jede Semantik. Und dieser Shop generiert sechsstellige Monatsumsätze.
So sieht die Realität bei den meisten Websites aus. Nicht, weil Entwickler schlechte Arbeit machen wollen — sondern weil Barrierefreiheit in den allermeisten Webprojekten schlicht kein Thema ist. Oder war. Denn seit das BFSG greift, hat sich das grundlegend geändert.
Ich fange bei jedem Audit mit dem HTML an. Klingt langweilig? Vielleicht. Aber semantisches HTML ist das Fundament, auf dem alles andere aufbaut. Und es ist kostenlos — Sie müssen nur die richtigen Tags verwenden.
Hier ein typisches Beispiel aus der Praxis. So sieht der Header auf gefühlt 80 % der Websites aus, die ich prüfe:
<!-- So NICHT (vorher) -->
<div class="header">
<div class="nav">
<div class="nav-item"><a href="/">Start</a></div>
<div class="nav-item"><a href="/shop">Shop</a></div>
<div class="nav-item"><a href="/kontakt">Kontakt</a></div>
</div>
</div>
Und so sollte es aussehen:
<!-- So JA (nachher) -->
<header role="banner">
<nav aria-label="Hauptnavigation">
<ul>
<li><a href="/">Start</a></li>
<li><a href="/shop">Shop</a></li>
<li><a href="/kontakt">Kontakt</a></li>
</ul>
</nav>
</header>
Der Unterschied? Im ersten Beispiel sieht ein Screenreader nur „Link Start, Link Shop, Link Kontakt" — ohne Kontext, ohne Struktur. Im zweiten Beispiel hört der Nutzer: „Hauptnavigation, Liste mit 3 Elementen, Link Start..." Das ist ein komplett anderes Erlebnis.
Die relevanten HTML5-Landmark-Elemente, die Sie verwenden sollten:
<header> — Kopfbereich der Seite oder eines Abschnitts<nav> — Navigationsbereiche (WCAG 2.4.1 fordert Umgehungsmöglichkeiten, Landmarks ermöglichen das)<main> — Hauptinhalt (nur einmal pro Seite!)<aside> — Ergänzende Inhalte wie Sidebars<footer> — Fußbereich<section> und <article> — Thematische GruppierungenScreenreader-Nutzer navigieren häufig über Überschriften. Sie springen von H2 zu H2, um den Inhalt zu scannen — ähnlich wie sehende Nutzer eine Seite überfliegen. Deshalb ist die Überschriftenhierarchie so kritisch (WCAG 1.3.1 — Info und Beziehungen).
Regeln, die ich bei jedem Projekt durchsetze:
<h1> pro SeiteWCAG 2.1.1 fordert: Alle Funktionalitäten müssen per Tastatur bedienbar sein. WCAG 2.1.2 ergänzt: Es darf keine Tastaturfallen geben — der Nutzer muss jedes Element auch wieder verlassen können.
Testen Sie es jetzt. Ernsthaft. Öffnen Sie Ihre Website in einem neuen Tab und versuchen Sie, nur mit der Tab-Taste zu navigieren. Können Sie:
Falls nicht — das ist die Nummer-1-Barriere, die ich bei Audits finde. Und sie betrifft nicht nur Screenreader-Nutzer, sondern auch Menschen mit motorischen Einschränkungen, die keine Maus verwenden können.
Ein häufiges Problem: Custom-Buttons mit <div onclick="..."> statt echten <button>-Elementen.
<!-- Vorher: Nicht per Tastatur bedienbar --> <div class="btn" onclick="addToCart()">In den Warenkorb</div> <!-- Nachher: Tastatur-zugänglich --> <button type="button" class="btn" onclick="addToCart()"> In den Warenkorb </button>
Der <button> ist von Haus aus per Tastatur fokussierbar, per Enter und Leertaste aktivierbar und wird vom Screenreader als „Schaltfläche" angekündigt. Null Aufwand, riesiger Unterschied.
WCAG 1.4.3 fordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (ab 18pt oder 14pt fett). Das klingt abstrakt, ist in der Praxis aber einer der häufigsten Verstöße.
Grauer Text auf weißem Hintergrund? Sieht elegant aus, ist aber für rund 8 % der männlichen Bevölkerung mit einer Farbschwäche problematisch. Von älteren Menschen mit nachlassender Sehkraft ganz zu schweigen.
Konkretes Beispiel:
/* Vorher: Kontrast 2,5:1 — DURCHGEFALLEN */
.text-light { color: #94a3b8; } /* Grau auf Weiß */
/* Nachher: Kontrast 4,6:1 — BESTANDEN */
.text-accessible { color: #475569; } /* Dunkleres Grau */
Mein Tipp: Prüfen Sie nicht nur den Body-Text. Die schlimmsten Kontrastverstöße finde ich regelmäßig bei Placeholder-Text in Formularen, deaktivierten Buttons und Fußnoten.
WCAG 1.1.1 — Nicht-Text-Inhalt: Jedes Bild braucht eine Textalternative. Aber bitte keine generischen Alt-Texte wie alt="Bild" oder alt="foto_2024_final_v3.jpg". Das hilft niemandem.
Faustregeln, die sich bewährt haben:
alt="Diagramm: BFSG-Betroffenheit nach Unternehmensgröße — 78% der Mittelständler sind betroffen"alt="". Ja, wirklich leer. Nicht weglassen — leer setzen.alt="Warenkorb öffnen" statt alt="Einkaufswagen-Symbol"Formulare sind der Bereich, in dem schlechte Zugänglichkeit am unmittelbarsten schadet. Ein Nutzer, der ein Formular nicht ausfüllen kann, kann nicht kaufen, nicht anfragen, nichts tun. Und nach WCAG gibt es gleich mehrere Kriterien, die hier greifen:
<!-- Vorher: Label nicht verknüpft -->
<span>E-Mail</span>
<input type="email" class="form-input">
<!-- Nachher: Korrekt verknüpft -->
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email"
autocomplete="email"
aria-describedby="email-hint"
required>
<span id="email-hint">Wir verwenden Ihre E-Mail nur für die Bestellbestätigung.</span>
Beachten Sie: autocomplete="email" hilft nicht nur bei der Barrierefreiheit (WCAG 1.3.5), sondern verbessert auch die User Experience für alle Nutzer. Win-win.
Ein Thema, das oft erst beim manuellen Test auffällt: Was passiert, wenn sich Seiteninhalte dynamisch ändern? Wenn ein Modal geöffnet wird, ein Accordion ausgeklappt wird oder eine Fehlermeldung erscheint?
Der Fokus muss aktiv auf den neuen Inhalt gesetzt werden. Sonst weiß ein Screenreader-Nutzer nicht, dass sich etwas geändert hat.
// Modal öffnen — Fokus auf den Close-Button setzen
function openModal() {
const modal = document.getElementById('modal');
modal.style.display = 'block';
modal.setAttribute('aria-hidden', 'false');
modal.querySelector('.close-btn').focus();
// Fokus im Modal einfangen (Focus Trap)
trapFocus(modal);
}
// Bei Fehlern — Fokus auf die Fehlerzusammenfassung
function showErrors(errors) {
const summary = document.getElementById('error-summary');
summary.innerHTML = `<h2>${errors.length} Fehler gefunden</h2>`;
summary.setAttribute('role', 'alert');
summary.focus();
}
ARIA (Accessible Rich Internet Applications) ist fantastisch für Fälle, in denen HTML allein nicht reicht. Aber die erste Regel von ARIA lautet — kein Witz, das steht so in der Spezifikation: „Verwende kein ARIA, wenn du natives HTML verwenden kannst."
Häufige ARIA-Fehler, die ich bei Audits sehe:
role="button" auf einem <div> statt einfach ein <button> zu verwendenaria-label das dem sichtbaren Text widerspricht (verwirrt sowohl Screenreader als auch Sprachsteuerung)aria-hidden="true" auf interaktiven Elementen — macht sie für Screenreader unsichtbar, aber sie bleiben per Tab erreichbar. Das ist eine Tastaturfalle.Sinnvoller ARIA-Einsatz:
<!-- Live-Region für dynamische Updates --> <div aria-live="polite" aria-atomic="true" id="cart-status"> 3 Artikel im Warenkorb </div> <!-- Accordion mit korrektem State --> <button aria-expanded="false" aria-controls="panel-1"> Versandkosten </button> <div id="panel-1" role="region" hidden> Kostenloser Versand ab 50 €. </div>
Automatisierte Tools wie axe, WAVE oder Lighthouse finden grob geschätzt 30-40 % der Barrierefreiheitsprobleme. Das ist besser als nichts, aber bei weitem nicht genug.
Mein Audit-Workflow sieht so aus:
Tipp, den ich jedem Entwicklerteam gebe: Macht die Tastatur-Tests zum Teil des Sprint Reviews. Fünf Minuten reichen, um die gröbsten Probleme zu finden. Und die Hemmschwelle sinkt, wenn man es regelmäßig macht.