BlogApr 30, 2026

Barrierefreiheit im Code: Die häufigsten Accessibility Fehler in der technischen Entwicklung

Barrierefreiheitsprobleme im Web sind selten Einzelfälle. Vielmehr handelt es sich in der Praxis überwiegend um wiederkehrende Implementierungsfehler, die sich über Projekte, Frameworks und Komponenten hinweg reproduzieren. Diese Wiederholbarkeit ist ein Hinweis darauf, dass die Ursachen häufig in grundlegenden technischen Mustern liegen und nicht in individuellen Sonderfällen.

Der WebAIM Million Report 2025^[1], eine der umfassendsten Studien zur Barrierefreiheit im Web, zeigt die Dimension dieses Problems deutlich: 94,8 % der untersuchten Startseiten wiesen mindestens einen nachweisbaren WCAG-Fehler auf, mit einem Durchschnitt von über 50 identifizierbaren Fehlern pro Seite. Gleichzeitig betont WebAIM, dass automatisierte Tests nur einen begrenzten Teil der tatsächlichen Barrieren erfassen können und keine vollständige Bewertung der Barrierefreiheit ermöglichen. Viele Aspekte der Zugänglichkeit, insbesondere Interaktionen, semantische Korrektheit, Fokusverhalten und Verständlichkeit, lassen sich ausschließlich durch manuelle Prüfungen oder Nutzertests zuverlässig bewerten.^[2]

Technisch betrachtet liegt die Ursache häufig in grundlegenden Implementierungsentscheidungen. Barrierefreiheit wird oft fälschlicherweise als nachträglicher Feinschliff behandelt, obwohl sie integraler Bestandteil der Architektur sein muss.

Was als technischer Barrierefreiheitsfehler gilt

Ein technischer Barrierefreiheitsfehler bezeichnet ein Defizit in der Implementierung von Code oder im Verhalten einer Benutzeroberfläche, das dazu führt, dass Inhalte oder Funktionen für bestimmte Nutzergruppen nicht oder nur eingeschränkt zugänglich sind. Dies betrifft insbesondere die Nutzung mit assistiven Technologien (z. B. Screenreader), die Bedienung per Tastatur, die Anpassung von Darstellung (z. B. Zoom oder Reflow) sowie nicht-visuelle oder alternative Navigationsformen.

Die Web Content Accessibility Guidelines (WCAG) definieren Barrierefreiheit entlang von vier Grundprinzipien: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein (Perceivable, Operable, Understandable, Robust – POUR)^[3]. Technische Barrierefreiheitsfehler entstehen immer dann, wenn eine oder mehrere dieser Anforderungen nicht erfüllt sind.

In diesem Artikel konzentrieren wir uns auf technische Fehler, die Entwickler:innen unmittelbar im Code, in Komponenten oder in der Interaktionslogik identifizieren und beheben können.

Inkorrekte Semantik und Seitenstruktur

Ein zentraler Bestandteil barrierefreier Weboberflächen ist eine semantisch korrekte Seitenstruktur. Entscheidend ist nicht nur, wie eine Seite visuell erscheint, sondern ob ihre Struktur auch programmatisch erfassbar ist. Nach WCAG-Erfolgskriterium 1.3.1 müssen Informationen, Strukturen und Beziehungen, die visuell vermittelt werden, entweder programmatisch bestimmbar oder als Text verfügbar sein. Dazu gehören etwa Überschriften, Listen, Formularbeziehungen, Tabellenstrukturen und Seitenbereiche.

Eine Seite kann daher optisch klar gegliedert wirken und dennoch für assistive Technologien schwer verständlich sein, wenn semantische HTML-Elemente fehlen oder falsch eingesetzt werden.^[5]

Typische Fehler sind die übermäßige Verwendung generischer Container wie div und span, obwohl semantische Elemente wie header, nav, main, footer, section, article, h1–h6, ul, ol, button oder Formularstrukturen verfügbar wären. MDN beschreibt semantische Strukturelemente ausdrücklich als Mittel, um Seiteninhalte sinnvoll zu gliedern, statt überall generische div-Container zu verwenden.^[6]

Besonders relevant sind Überschriften und Landmarken. Überschriften vermitteln die inhaltliche Organisation einer Seite und können von Browsern, Plug-ins und assistiven Technologien zur Navigation genutzt werden. Landmarken wie main, nav, header und footer helfen Nutzern, zentrale Seitenbereiche schneller zu erkennen und anzusteuern.^[7]

Zu den häufigen Problemen zählen daher visuell hervorgehobene Texte, die nicht als echte Überschriften ausgezeichnet sind, übersprungene oder unlogische Überschriftenhierarchien, visuelle Listen ohne ul oder ol, klickbare div-Elemente statt echter Buttons sowie fehlende oder unzureichend benannte Landmarken.

Die Grundregel lautet: Wenn eine Struktur für das Verständnis, die Orientierung oder die Bedienung relevant ist, muss sie auch im Markup vorhanden sein.

Häufige Fehler: Codebeispielehtml

<!-- 
1. Nur generische Container statt semantischer Struktur
Ist ein Problem weil: Assistive Technologien keine klare Seitenstruktur erkennen können; Navigation über Landmarken und strukturelle Elemente ist nicht möglich.
-->
<!-- Schlecht -->
<div class="header">
  <div class="logo">Shop</div>
  <div class="menu">
    <span>Produkte</span>
    <span>Kontakt</span>
  </div>
</div>

<div class="content">
  <div class="title">Unsere Produkte</div>
  <div class="subtitle">Neue Kollektion</div>

  <div class="product-list">
    <div>Rucksack</div>
    <div>Sneaker</div>
    <div>Jacke</div>
  </div>
</div>

<div class="footer">
  © 2026 Shop
</div>

<!-- Besser -->
<header>
  <a href="/" aria-label="Startseite">Shop</a>

  <nav aria-label="Hauptnavigation">
    <ul>
      <li><a href="/produkte">Produkte</a></li>
      <li><a href="/kontakt">Kontakt</a></li>
    </ul>
  </nav>
</header>

<main>
  <h1>Unsere Produkte</h1>

  <section aria-labelledby="new-collection-heading">
    <h2 id="new-collection-heading">Neue Kollektion</h2>

    <ul>
      <li>Rucksack</li>
      <li>Sneaker</li>
      <li>Jacke</li>
    </ul>
  </section>
</main>

<footer>
  <p>© 2026 Shop</p>
</footer>


<!-- 
2. Visuelle Überschriften ohne semantische Auszeichnung
Ist ein Problem weil: Screenreader keine Überschriftenstruktur erkennen; Navigation über Überschriften ist eingeschränkt oder unmöglich.
-->
<!-- Schlecht -->
<p class="headline">Versandinformationen</p>
<p>Wir liefern innerhalb von 3–5 Werktagen.</p>

<p class="subheadline">Lieferkosten</p>
<p>Der Versand kostet 4,90 €.</p>

<!-- Besser -->
<section aria-labelledby="shipping-heading">
  <h2 id="shipping-heading">Versandinformationen</h2>
  <p>Wir liefern innerhalb von 3–5 Werktagen.</p>

  <h3>Lieferkosten</h3>
  <p>Der Versand kostet 4,90 €.</p>
</section>


<!-- 
3. Inkonsistente oder übersprungene Überschriftenhierarchie
Ist ein Problem weil: Die logische Dokumentstruktur wird gestört; Nutzer können Inhalte schlechter verstehen und navigieren.
-->
<!-- Schlecht -->
<main>
  <h1>Hilfe & Support</h1>

  <h4>Kontakt aufnehmen</h4>
  <p>Unser Support-Team hilft dir gerne weiter.</p>
</main>

<!-- Besser -->
<main>
  <h1>Hilfe & Support</h1>

  <section>
    <h2>Kontakt aufnehmen</h2>
    <p>Unser Support-Team hilft dir gerne weiter.</p>
  </section>
</main>


<!-- 
4. Fehlende semantische Elemente für Interaktion
Ist ein Problem weil: Interaktive Elemente ohne korrekte Semantik nicht per Tastatur bedienbar sind und von Screenreadern nicht als solche erkannt werden.
-->
<!-- Schlecht -->
<div class="button" onclick="openMenu()">
  Menü öffnen
</div>

<!-- Besser -->
<button type="button" onclick="openMenu()">
  Menü öffnen
</button>


<!-- 
5. Visuelle Listen ohne semantische Listenstruktur
Ist ein Problem weil: Zusammengehörige Inhalte werden nicht als Gruppe erkannt; Screenreader geben keine Listenstruktur aus.
-->
<!-- Schlecht -->
<div class="features">
  <div>✓ Kostenloser Versand</div>
  <div>✓ 30 Tage Rückgabe</div>
  <div>✓ Sichere Zahlung</div>
</div>

<!-- Besser -->
<ul>
  <li>Kostenloser Versand</li>
  <li>30 Tage Rückgabe</li>
  <li>Sichere Zahlung</li>
</ul>

Fehlende Namen, Labels und Alternativtexte

Ein weiterer großer Fehlerbereich sind fehlende oder unklare zugängliche Namen (accessible names). Interaktive Elemente benötigen einen programmatisch bestimmbaren Namen, Bilder müssen mit geeigneten Alternativtexten versehen sein, und Formularelemente brauchen eindeutig zugeordnete Beschriftungen. Diese Informationen sind notwendig, damit assistive Technologien Inhalte korrekt identifizieren, interpretieren und vermitteln können.

Die WCAG fordert in Erfolgskriterium 1.1.1 (Non-text Content)^[8], dass für nicht-textuelle Inhalte geeignete Textalternativen bereitgestellt werden. Darüber hinaus verlangt 4.1.2 (Name, Role, Value)^[9], dass Benutzeroberflächenkomponenten über einen programmatisch bestimmbaren Namen verfügen. Für Formulare konkretisiert 3.3.2 (Labels or Instructions)^[10], dass Eingabefelder klar beschriftet oder mit verständlichen Anweisungen versehen sein müssen.

Der zugängliche Name wird aus verschiedenen Quellen gebildet, etwa aus sichtbarem Text, label-Elementen, Alternativtexten oder ARIA-Attributen wie aria-label oder aria-labelledby. Entscheidend ist, dass dieser Name eindeutig, verständlich und konsistent mit der sichtbaren Benutzeroberfläche ist.

Typische Fehler entstehen, wenn diese Zuordnung fehlt oder unzureichend ist. Dazu gehören Eingabefelder ohne label, Placeholder als alleinige Beschriftung, unklare Sammel-Labels für mehrere Felder sowie Icon-Buttons ohne zugänglichen Namen. Ebenso problematisch sind Links ohne aussagekräftigen Text, dekorative Bilder ohne alt="" sowie bedeutungsvolle Bilder ohne sinnvollen Alternativtext.

Ein weiterer häufiger Fehler ist eine Diskrepanz zwischen sichtbarem Label und zugänglichem Namen. Wenn sich beide widersprechen oder stark unterscheiden, entsteht Inkonsistenz in der Nutzung, insbesondere für Screenreader-Nutzer.^[11]

Die grundlegende Regel lautet: Jede Funktion und jeder nicht rein dekorative Inhalt muss einen klaren, verständlichen und programmatisch verfügbaren Namen besitzen. Nur so können Inhalte unabhängig von Darstellung und Interaktionsform zuverlässig genutzt werden.

Häufige Fehler: Codebeispielehtml

<!-- 
1. Eingabefeld ohne Label
Ist ein Problem weil: Screenreader-Nutzende nicht erkennen können, welche Information erwartet wird; das Feld ist nicht eindeutig identifizierbar.
-->
<!-- Schlecht -->
<input type="text" name="email">

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


<!-- 
2. Placeholder als einziges Label
Ist ein Problem weil: Placeholder beim Tippen verschwindet und nicht zuverlässig als zugänglicher Name dient.
-->
<!-- Schlecht -->
<input type="text" placeholder="E-Mail-Adresse">

<!-- Besser -->
<label for="email2">E-Mail-Adresse</label>
<input type="email" id="email2" placeholder="name@beispiel.de">


<!-- 
3. Unklare Sammel-Labels für mehrere Felder
Ist ein Problem weil: Mehrere Eingabefelder nicht individuell beschriftet sind und ihre Bedeutung unklar bleibt.
-->
<!-- Schlecht -->
<label>Name:</label>
<input type="text" name="vorname">
<input type="text" name="nachname">

<!-- Besser -->
<fieldset>
  <legend>Name</legend>

  <label for="vorname">Vorname</label>
  <input type="text" id="vorname" name="vorname">

  <label for="nachname">Nachname</label>
  <input type="text" id="nachname" name="nachname">
</fieldset>


<!-- 
4. Icon-Button ohne zugänglichen Namen
Ist ein Problem weil: Screenreader den Zweck des Buttons nicht erkennen können.
-->
<!-- Schlecht -->
<button>
  <svg><!-- Icon --></svg>
</button>

<!-- Besser -->
<button aria-label="Suche">
  <svg aria-hidden="true"><!-- Icon --></svg>
</button>


<!-- 
5. Link ohne beschreibenden Inhalt
Ist ein Problem weil: Der Linkzweck außerhalb des Kontexts nicht verständlich ist.
-->
<!-- Schlecht -->
<a href="/kontakt">Hier klicken</a>

<!-- Besser -->
<a href="/kontakt">Kontakt aufnehmen</a>


<!-- 
6. Dekoratives Bild ohne leeres alt-Attribut
Ist ein Problem weil: Screenreader unnötige oder verwirrende Informationen vorlesen.
-->
<!-- Schlecht -->
<img src="linie.png">

<!-- Besser -->
<img src="linie.png" alt="">


<!-- 
7. Bedeutungsvolles Bild ohne sinnvollen Alternativtext
Ist ein Problem weil: Wichtige Inhalte für nicht-sehende Nutzer verloren gehen.
-->
<!-- Schlecht -->
<img src="diagramm.png" alt="Bild">

<!-- Besser -->
<img src="diagramm.png" alt="Umsatzsteigerung von 20 % im Jahr 2025">


<!-- 
8. Diskrepanz zwischen sichtbarem Label und zugänglichem Namen
Ist ein Problem weil: Unterschiedliche Bezeichnungen zu Verwirrung bei Screenreader-Nutzern führen.
-->
<!-- Schlecht -->
<button aria-label="Formular absenden">Jetzt kaufen</button>

<!-- Besser -->
<button>Jetzt kaufen</button>

<!-- Alternative (erweiternd, aber konsistent) -->
<button aria-label="Jetzt kaufen – Bestellung abschließen">
  Jetzt kaufen
</button>

Tastaturzugänglichkeit und Fokusmanagement

Ein häufiger Irrtum in der Praxis ist die Annahme, eine Oberfläche sei bereits tastaturbedienbar, wenn sich einzelne Elemente mit der Tab-Taste erreichen lassen. Tatsächlich fordert die WCAG in Erfolgskriterium 2.1.1 (Keyboard)^[12], dass alle Funktionen, die per Maus bedienbar sind, auch vollständig über die Tastatur zugänglich sein müssen. Darüber hinaus darf der Fokus nicht unbeabsichtigt eingeschlossen werden, wie in 2.1.2 (No Keyboard Trap)^[13] beschrieben.

Tastaturzugänglichkeit umfasst dabei mehr als reine Erreichbarkeit: Interaktionen müssen vollständig ausführbar sein, und der Fokus muss sich erwartbar, logisch und konsistent durch die Oberfläche bewegen.

Typische Probleme entstehen, wenn interaktive Elemente nicht korrekt implementiert sind. Dazu zählen klickbare div- oder span-Elemente ohne Tastaturunterstützung, benutzerdefinierte Komponenten wie Dropdowns oder Akkordeons, die ausschließlich auf Mausinteraktionen reagieren, sowie entfernte oder unzureichende Fokusindikatoren. Auch unlogische Tab-Reihenfolgen, unerwartet springender Fokus oder fehlendes Fokusmanagement in komplexeren Komponenten wie Dialogen führen zu erheblichen Nutzungshürden.

Ein weiterer kritischer Punkt ist die Sichtbarkeit des Fokus. Nach WCAG 2.4.7 (Focus Visible)^[14] muss jederzeit erkennbar sein, welches Element aktuell den Fokus besitzt. Wird der Fokusindikator entfernt oder visuell überdeckt – etwa durch fixierte UI-Elemente – geht die Orientierung verloren, insbesondere für Tastatur- und Screenreader-Nutzer.

Fokus ist dabei kein technisches Detail, sondern der zentrale Interaktionspunkt des Nutzers. Er bestimmt, wo Eingaben wirken und wie sich Nutzer durch eine Anwendung bewegen. Wenn Fokus unsichtbar, unlogisch oder unvorhersehbar wird, ist die Bedienbarkeit der Oberfläche unmittelbar beeinträchtigt.

Häufige Fehler: Codebeispielehtml

<!-- 
1. Klickbare div/span ohne Tastaturfunktion
Ist ein Problem weil: Elemente nicht per Tastatur erreichbar oder auslösbar sind; sie sind keine echten interaktiven Komponenten.
-->
<!-- Schlecht -->
<div onclick="openMenu()">
  Menü öffnen
</div>

<!-- Besser -->
<button type="button" onclick="openMenu()">
  Menü öffnen
</button>


<!-- 
2. Interaktive Komponenten nur für Maus (z. B. Dropdown)
Ist ein Problem weil: Tastaturnutzer keine Möglichkeit haben, Inhalte zu öffnen oder zu bedienen.
-->
<!-- Schlecht -->
<div class="dropdown" onclick="toggleDropdown()">
  Optionen
  <div class="menu">
    <div>Profil</div>
    <div>Einstellungen</div>
  </div>
</div>

<!-- Besser -->
<button aria-haspopup="true" aria-expanded="false" onclick="toggleDropdown()">
  Optionen
</button>
<ul>
  <li><a href="/profil">Profil</a></li>
  <li><a href="/einstellungen">Einstellungen</a></li>
</ul>


<!-- 
3. Entfernte Fokusrahmen (outline)
Ist ein Problem weil: Nutzer nicht sehen können, welches Element aktuell fokussiert ist.
-->
<!-- Schlecht -->
<style>
  :focus {
    outline: none;
  }
</style>

<button>Speichern</button>

<!-- Besser -->
<style>
  :focus {
    outline: 2px solid #005fcc;
    outline-offset: 2px;
  }
</style>

<button>Speichern</button>


<!-- 
4. Unlogische Tab-Reihenfolge
Ist ein Problem weil: Fokus springt nicht in visueller Reihenfolge; Navigation wird unvorhersehbar.
-->
<!-- Schlecht -->
<input type="text" placeholder="Name" tabindex="3">
<input type="email" placeholder="E-Mail" tabindex="1">
<button tabindex="2">Absenden</button>

<!-- Besser -->
<input type="text" placeholder="Name">
<input type="email" placeholder="E-Mail">
<button>Absenden</button>


<!-- 
5. Unerwartet springender Fokus
Ist ein Problem weil: Nutzer die Kontrolle über ihre Position verlieren; Kontextwechsel erfolgt ohne Erwartung.
-->
<!-- Schlecht -->
<input type="text" oninput="document.getElementById('next').focus()">
<input type="text" id="next">

<!-- Besser -->
<input type="text">
<input type="text" id="next">
<!-- Fokus bleibt beim Nutzer, keine erzwungene Verschiebung -->


<!-- 
6. Modal ohne korrektes Fokusmanagement
Ist ein Problem weil: Fokus kann hinter dem Modal bleiben oder verloren gehen; Tastaturnavigation bricht.
-->
<!-- Schlecht -->
<div class="modal">
  <p>Dialoginhalt</p>
  <button onclick="closeModal()">Schließen</button>
</div>

<!-- Besser -->
<div role="dialog" aria-modal="true" aria-labelledby="modal-title">
  <h2 id="modal-title">Dialog</h2>
  <p>Dialoginhalt</p>
  <button autofocus onclick="closeModal()">Schließen</button>
</div>
<!-- Fokus wird beim Öffnen in den Dialog gesetzt -->


<!-- 
7. Fixierte Elemente verdecken Fokus
Ist ein Problem weil: Fokussierte Elemente nicht sichtbar sind, z. B. hinter Sticky Headern.
-->
<!-- Schlecht -->
<style>
  header {
    position: fixed;
    top: 0;
    height: 80px;
  }
</style>

<a href="#main">Zum Inhalt springen</a>

<main id="main">
  <h1>Inhalt</h1>
</main>

<!-- Besser -->
<style>
  header {
    position: fixed;
    top: 0;
    height: 80px;
  }

  #main {
    scroll-margin-top: 100px;
  }
</style>

<a href="#main">Zum Inhalt springen</a>

<main id="main">
  <h1>Inhalt</h1>
</main>

Custom Widgets und ARIA

Native Elemente wie button, input oder select bringen bereits eingebaute Semantik, Tastaturbedienung, Fokusverhalten und Zustandskommunikation mit. Werden diese durch eigene Widgets ersetzt, müssen all diese Aspekte explizit implementiert werden.

Die WCAG fordert in 4.1.2 (Name, Role, Value)^[9], dass alle interaktiven Komponenten einen programmatisch bestimmbaren Namen, eine Rolle und – sofern zutreffend – einen Zustand besitzen. Diese Informationen sind notwendig, damit assistive Technologien die Funktion und den aktuellen Status eines Elements korrekt vermitteln können.

Gleichzeitig betont das WAI-ARIA-Authoring-Prinzip: „No ARIA is better than bad ARIA“^[15]. Semantisches HTML sollte immer Vorrang haben, wenn geeignete native Elemente verfügbar sind, da diese bereits korrektes Verhalten und Zugänglichkeit mitbringen.

Die grundlegende Regel lautet: Eine Rolle ist ein Versprechen. Wird beispielsweise role="button" verwendet, muss sich das Element auch wie ein Button verhalten – inklusive Tastaturbedienung (z. B. Enter/Space), Fokusfähigkeit und visueller sowie programmatischer Zustandsanzeige.

Typische Fehler entstehen, wenn diese Anforderungen nicht vollständig umgesetzt werden. Dazu gehören Rollen ohne entsprechende Interaktionslogik, nicht kommunizierte Zustände (z. B. fehlendes aria-expanded), Dialoge ohne echte Modalität oder korrektes Fokusmanagement, sowie komplexe Widgets, die keine konsistente Tastaturnavigation bieten.

Ein besonders kritischer Fehler ist die Verwendung von aria-hidden="true" auf fokussierbaren Elementen. Dieses Attribut entfernt Inhalte aus dem Accessibility Tree, macht sie jedoch nicht visuell unsichtbar. Dadurch entsteht eine Inkonsistenz zwischen sichtbarer Oberfläche und wahrnehmbarer Struktur für assistive Technologien. MDN weist ausdrücklich darauf hin, dass aria-hidden nicht auf interaktiven oder fokussierbaren Elementen eingesetzt werden sollte.^[16]

Die zentrale Empfehlung lautet daher: Native HTML-Elemente sollten immer bevorzugt verwendet werden. ARIA sollte nur dann eingesetzt werden, wenn native Semantik nicht ausreicht – und dann vollständig und korrekt implementiert werden.

Häufige Fehler: Codebeispielehtml

<!-- 
1. Rolle ohne entsprechendes Verhalten (role="button" ohne Interaktion)
Ist ein Problem weil: Die Rolle ein Verhalten verspricht, das nicht umgesetzt wird; Tastaturbedienung und Erwartungen von Nutzern werden verletzt.
-->
<!-- Schlecht -->
<div role="button" onclick="save()">
  Speichern
</div>

<!-- Besser -->
<button type="button" onclick="save()">
  Speichern
</button>

<!-- Alternative (nur wenn nötig) -->
<div 
  role="button" 
  tabindex="0" 
  onclick="save()" 
  onkeydown="if(event.key==='Enter' || event.key===' ') save()">
  Speichern
</div>


<!-- 
2. Fehlende Zustandskommunikation (z. B. Toggle)
Ist ein Problem weil: Screenreader-Nutzer nicht erkennen können, ob ein Zustand aktiv/inaktiv ist.
-->
<!-- Schlecht -->
<div role="button" onclick="toggleMenu()">
  Menü
</div>

<!-- Besser -->
<button 
  aria-expanded="false" 
  aria-controls="menu" 
  onclick="toggleMenu()">
  Menü
</button>

<ul id="menu" hidden>
  <li><a href="#">Profil</a></li>
  <li><a href="#">Einstellungen</a></li>
</ul>


<!-- 
3. Dialog ohne echte Modalität
Ist ein Problem weil: Fokus nicht eingeschränkt wird und Nutzer weiterhin mit Hintergrundinhalten interagieren können.
-->
<!-- Schlecht -->
<div class="dialog">
  <p>Bestätigen?</p>
  <button>OK</button>
</div>

<!-- Besser -->
<div role="dialog" aria-modal="true" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Bestätigen</h2>
  <p>Möchten Sie fortfahren?</p>
  <button autofocus>OK</button>
  <button>Abbrechen</button>
</div>


<!-- 
4. Komplexes Widget ohne korrektes Fokusverhalten (z. B. Tabs)
Ist ein Problem weil: Nutzer nicht mit Pfeiltasten navigieren können und der Fokus nicht logisch geführt wird.
-->
<!-- Schlecht -->
<div class="tabs">
  <div onclick="showTab(1)">Tab 1</div>
  <div onclick="showTab(2)">Tab 2</div>
</div>

<!-- Besser -->
<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="panel1" id="tab1">
    Tab 1
  </button>
  <button role="tab" aria-selected="false" aria-controls="panel2" id="tab2">
    Tab 2
  </button>
</div>

<div id="panel1" role="tabpanel" aria-labelledby="tab1">
  Inhalt 1
</div>
<div id="panel2" role="tabpanel" aria-labelledby="tab2" hidden>
  Inhalt 2
</div>


<!-- 
5. aria-hidden auf fokussierbaren Elementen
Ist ein Problem weil: Element für Screenreader unsichtbar ist, aber weiterhin fokussierbar bleibt → inkonsistente Wahrnehmung.
-->
<!-- Schlecht -->
<button aria-hidden="true">
  Schließen
</button>

<!-- Besser -->
<button>
  Schließen
</button>

<!-- Oder wenn wirklich versteckt -->
<button hidden>
  Schließen
</button>


<!-- 
6. ARIA statt nativer HTML-Semantik
Ist ein Problem weil: Unnötige Komplexität entsteht und native Funktionen (z. B. Tastatur, Zustände) nicht automatisch bereitgestellt werden.
-->
<!-- Schlecht -->
<div role="checkbox" aria-checked="false" onclick="toggleCheckbox(this)">
  Newsletter abonnieren
</div>

<!-- Besser -->
<label>
  <input type="checkbox" name="newsletter">
  Newsletter abonnieren
</label>


<!-- 
7. aria-hidden entfernt Inhalte aus dem Accessibility Tree
Ist ein Problem weil: Inhalte für assistive Technologien komplett unsichtbar werden, obwohl sie visuell vorhanden sind.
-->
<!-- Schlecht -->
<p aria-hidden="true">
  Wichtige Information für alle Nutzer
</p>

<!-- Besser -->
<p>
  Wichtige Information für alle Nutzer
</p>

Lesbarkeit und Anpassbarkeit

Die WCAG definieren hierfür konkrete Anforderungen, insbesondere ausreichenden Farbkontrast (1.4.3 Contrast (Minimum))^[17], Skalierbarkeit von Text (1.4.4 Resize Text)^[18], responsives Verhalten ohne Informationsverlust (1.4.10 Reflow)^[19], die Vermeidung ausschließlich farbbasierter Informationsvermittlung (1.4.1 Use of Color)^[20] sowie die Möglichkeit, bewegte Inhalte zu pausieren oder zu stoppen (2.2.2 Pause, Stop, Hide)^[21].

Diese Anforderungen stellen sicher, dass Inhalte unter unterschiedlichen Nutzungsbedingungen wahrnehmbar und bedienbar bleiben – etwa bei vergrößertem Text, kleinen Viewports oder eingeschränktem Sehvermögen.

In der Praxis entstehen Probleme häufig durch unzureichende technische Umsetzung. Dazu zählen geringer Farbkontrast zwischen Text und Hintergrund, Texte über Bildern ohne ausreichende Lesbarkeit, entfernte oder kaum sichtbare Fokusindikatoren, feste Containerhöhen mit abgeschnittenem Inhalt sowie Layouts, die bei vergrößertem Text oder Zoom brechen oder überlappen. Ebenso problematisch sind Informationen, die ausschließlich über Farbe vermittelt werden, sowie Animationen oder automatisch ablaufende Inhalte ohne Möglichkeit zur Unterbrechung.

Diese Probleme werden oft als reine Designfragen betrachtet, sind jedoch funktionale Barrierefreiheitsfehler. Wenn Text nicht ausreichend vergrößert werden kann oder Inhalte bei Reflow verloren gehen, ist die Nutzung für bestimmte Nutzergruppen faktisch eingeschränkt oder unmöglich. Barrierefreiheit erfordert daher nicht nur visuelle Gestaltung, sondern eine technisch robuste Umsetzung, die unterschiedliche Darstellungskontexte zuverlässig unterstützt.

Häufige Fehler: Codebeispielehtml

<!-- 
1. Unzureichender Farbkontrast
Ist ein Problem weil: Texte für viele Nutzer (z. B. mit Sehschwäche) schwer oder gar nicht lesbar sind.
-->
<!-- Schlecht -->
<style>
  .text {
    color: #aaa;
    background: #fff;
  }
</style>
<p class="text">Wichtige Information</p>

<!-- Besser -->
<style>
  .text {
    color: #222;
    background: #fff;
  }
</style>
<p class="text">Wichtige Information</p>


<!-- 
2. Text über Bildern ohne ausreichenden Kontrast
Ist ein Problem weil: Hintergrundbilder die Lesbarkeit stark beeinträchtigen können.
-->
<!-- Schlecht -->
<div style="background: url('bild.jpg'); color: white;">
  Willkommen auf unserer Seite
</div>

<!-- Besser -->
<div style="position: relative;">
  <img src="bild.jpg" alt="" style="width:100%;">
  <div style="
    position:absolute;
    top:0;
    left:0;
    right:0;
    bottom:0;
    background: rgba(0,0,0,0.5);
    color: #fff;
    display:flex;
    align-items:center;
    justify-content:center;">
    Willkommen auf unserer Seite
  </div>
</div>


<!-- 
3. Fixe Höhen schneiden Text ab (kein Reflow)
Ist ein Problem weil: Bei vergrößertem Text Inhalte abgeschnitten oder unlesbar werden.
-->
<!-- Schlecht -->
<style>
  .box {
    height: 50px;
    overflow: hidden;
  }
</style>
<div class="box">
  Sehr langer Text, der bei größerer Schrift abgeschnitten wird.
</div>

<!-- Besser -->
<style>
  .box {
    min-height: 50px;
  }
</style>
<div class="box">
  Sehr langer Text, der sich flexibel anpasst.
</div>


<!-- 
4. Layout bricht bei Textvergrößerung
Ist ein Problem weil: Inhalte überlappen oder verschwinden, wenn Nutzer Text skalieren.
-->
<!-- Schlecht -->
<style>
  .container {
    display: flex;
    width: 300px;
  }
  .item {
    width: 150px;
  }
</style>

<div class="container">
  <div class="item">Text 1</div>
  <div class="item">Text 2</div>
</div>

<!-- Besser -->
<style>
  .container {
    display: flex;
    flex-wrap: wrap;
  }
  .item {
    flex: 1 1 200px;
  }
</style>

<div class="container">
  <div class="item">Text 1</div>
  <div class="item">Text 2</div>
</div>


<!-- 
5. Information nur über Farbe vermittelt
Ist ein Problem weil: Farbblinde oder Screenreader-Nutzer die Bedeutung nicht erkennen können.
-->
<!-- Schlecht -->
<p style="color: red;">Fehler: Passwort ist zu kurz</p>

<!-- Besser -->
<p>
  <strong>Fehler:</strong> Passwort ist zu kurz
</p>


<!-- 
6. Unsichtbarer Fokusindikator
Ist ein Problem weil: Tastaturnutzer nicht sehen, wo sie sich befinden.
-->
<!-- Schlecht -->
<style>
  :focus {
    outline: none;
  }
</style>

<button>Weiter</button>

<!-- Besser -->
<style>
  :focus {
    outline: 2px solid #005fcc;
    outline-offset: 2px;
  }
</style>

<button>Weiter</button>


<!-- 
7. Animationen ohne Pause- oder Stopp-Möglichkeit
Ist ein Problem weil: Bewegungen ablenken oder gesundheitliche Probleme (z. B. bei Epilepsie) verursachen können.
-->
<!-- Schlecht -->
<div class="animation"></div>

<style>
  .animation {
    width: 100px;
    height: 100px;
    background: red;
    animation: move 1s infinite alternate;
  }

  @keyframes move {
    from { transform: translateX(0); }
    to { transform: translateX(200px); }
  }
</style>

<!-- Besser -->
<button onclick="toggleAnimation()">Animation pausieren</button>
<div class="animation"></div>

<style>
  .animation {
    width: 100px;
    height: 100px;
    background: red;
    animation: move 1s infinite alternate;
  }

  .paused {
    animation-play-state: paused;
  }

  @keyframes move {
    from { transform: translateX(0); }
    to { transform: translateX(200px); }
  }
</style>

<script>
  function toggleAnimation() {
    document.querySelector('.animation').classList.toggle('paused');
  }
</script>

Formulare, Validierung und Feedback

Formulare gehören zu den komplexesten Bereichen barrierefreier Webanwendungen, da sie mehrere Anforderungen gleichzeitig erfüllen müssen: klare Beschriftungen, verständliche Anweisungen, sinnvolle Gruppierung, valide Eingabeprüfung, korrektes Fokusmanagement sowie zugängliches Feedback.

Die WCAG fassen diese Anforderungen unter dem Prinzip zusammen, dass Nutzer beim Vermeiden und Korrigieren von Fehlern unterstützt werden müssen. Konkret definieren die Erfolgskriterien 3.3.1 (Error Identification)^[22], 3.3.2 (Labels or Instructions)^[23] und 3.3.3 (Error Suggestion)^[24], dass Fehler eindeutig identifiziert, verständlich beschrieben und – wenn möglich – mit konkreten Korrekturhinweisen versehen werden müssen.

Typische Probleme entstehen, wenn diese Anforderungen nicht erfüllt werden. Dazu zählen Pflichtfelder, die ausschließlich durch Farbe gekennzeichnet sind, Formatangaben, die nur als Placeholder bereitgestellt werden, sowie Fehlermeldungen, die rein visuell dargestellt und nicht programmatisch verknüpft sind. Ebenso problematisch sind unklare oder generische Fehlermeldungen, nicht angekündigtes Feedback (z. B. bei dynamischer Validierung) und Formulare, bei denen Nutzereingaben nach einem Fehler verloren gehen.

Ein weiterer zentraler Aspekt ist die Kommunikation von Zuständen und Änderungen. Rückmeldungen, etwa Fehlermeldungen oder Erfolgshinweise, müssen so implementiert sein, dass sie von assistiven Technologien wahrgenommen werden können, beispielsweise durch korrekt verknüpfte Beschreibungen oder Live-Regionen.

Entscheidend ist dabei, dass Formulare sowohl präventiv als auch reaktiv unterstützen: Sie sollten Fehler möglichst vermeiden helfen (z. B. durch klare Anweisungen und sinnvolle Voreinstellungen) und gleichzeitig effektive Mechanismen zur Korrektur bereitstellen. Eine barrierefreie Formularimplementierung beschränkt sich daher nicht darauf, Fehler anzuzeigen, sondern unterstützt aktiv dabei, diese schnell und verständlich zu beheben.

Häufige Fehler: Codebeispielehtml

<!-- 
1. Pflichtfelder nur durch Farbe markiert
Ist ein Problem weil: Nutzer die Bedeutung der Markierung nicht erkennen können, wenn sie Farben nicht wahrnehmen oder Screenreader verwenden.
-->
<!-- Schlecht -->
<label for="email">E-Mail</label>
<input id="email" name="email" style="border-color: red;">

<!-- Besser -->
<label for="email">
  E-Mail <span aria-hidden="true">*</span>
</label>
<input id="email" name="email" type="email" required aria-describedby="email-hint">
<p id="email-hint">Pflichtfeld</p>


<!-- 
2. Formatangaben nur als Placeholder
Ist ein Problem weil: Placeholder beim Tippen verschwinden und nicht zuverlässig als dauerhafte Anweisung verfügbar sind.
-->
<!-- Schlecht -->
<input type="text" placeholder="TT.MM.JJJJ">

<!-- Besser -->
<label for="birthdate">Geburtsdatum</label>
<p id="birthdate-hint">Format: TT.MM.JJJJ</p>
<input
  id="birthdate"
  name="birthdate"
  type="text"
  autocomplete="bday"
  aria-describedby="birthdate-hint"
>


<!-- 
3. Fehler nur visuell dargestellt
Ist ein Problem weil: Assistive Technologien den Fehler nicht zuverlässig erkennen oder ankündigen können.
-->
<!-- Schlecht -->
<label for="password">Passwort</label>
<input id="password" name="password" type="password" style="border-color: red;">
<p style="color: red;">Zu kurz</p>

<!-- Besser -->
<label for="password">Passwort</label>
<input
  id="password"
  name="password"
  type="password"
  aria-invalid="true"
  aria-describedby="password-error"
>
<p id="password-error">
  Fehler: Das Passwort muss mindestens 8 Zeichen lang sein.
</p>


<!-- 
4. Unklare Fehlermeldungen
Ist ein Problem weil: Nutzer zwar erfahren, dass etwas falsch ist, aber nicht, wie sie den Fehler beheben können.
-->
<!-- Schlecht -->
<label for="phone">Telefonnummer</label>
<input id="phone" name="phone" type="tel" aria-invalid="true">
<p>Ungültige Eingabe</p>

<!-- Besser -->
<label for="phone">Telefonnummer</label>
<input
  id="phone"
  name="phone"
  type="tel"
  aria-invalid="true"
  aria-describedby="phone-error phone-hint"
>
<p id="phone-hint">Beispiel: +49 30 1234567</p>
<p id="phone-error">
  Fehler: Bitte geben Sie die Telefonnummer mit Landesvorwahl ein.
</p>


<!-- 
5. Nicht angekündigtes Feedback
Ist ein Problem weil: Screenreader-Nutzer Änderungen wie Erfolgsmeldungen oder Validierungsfehler möglicherweise nicht bemerken.
-->
<!-- Schlecht -->
<form onsubmit="showMessage(); return false;">
  <label for="newsletter-email">E-Mail</label>
  <input id="newsletter-email" name="email" type="email">
  <button>Abonnieren</button>
</form>
<div id="message"></div>

<!-- Besser -->
<form onsubmit="showMessage(); return false;">
  <label for="newsletter-email-good">E-Mail</label>
  <input id="newsletter-email-good" name="email" type="email">
  <button>Abonnieren</button>
</form>

<div id="message-good" role="status" aria-live="polite"></div>

<script>
  function showMessage() {
    document.getElementById('message-good').textContent =
      'Danke, Ihre Anmeldung wurde gespeichert.';
  }
</script>


<!-- 
6. Eingaben gehen bei Fehler verloren
Ist ein Problem weil: Nutzer ihre Angaben erneut eingeben müssen; das erschwert Korrektur und kann zum Abbruch führen.
-->
<!-- Schlecht -->
<form>
  <label for="name">Name</label>
  <input id="name" name="name" value="">

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

  <p>Fehler: Bitte prüfen Sie Ihre Eingaben.</p>
</form>

<!-- Besser -->
<form>
  <label for="name-good">Name</label>
  <input id="name-good" name="name" value="Max Mustermann">

  <label for="email-preserved">E-Mail</label>
  <input
    id="email-preserved"
    name="email"
    type="email"
    value="max@beispiel"
    aria-invalid="true"
    aria-describedby="email-error"
  >

  <p id="email-error">
    Fehler: Bitte geben Sie eine vollständige E-Mail-Adresse ein, z. B. max@beispiel.de.
  </p>
</form>


<!-- 
7. Fehlerzusammenfassung ohne Fokusmanagement
Ist ein Problem weil: Nutzer nach dem Absenden nicht direkt erfahren, wo Fehler aufgetreten sind und wie sie dorthin gelangen.
-->
<!-- Schlecht -->
<form>
  <p>Es sind Fehler aufgetreten.</p>

  <label for="street">Straße</label>
  <input id="street" name="street">

  <label for="zip">PLZ</label>
  <input id="zip" name="zip">
</form>

<!-- Besser -->
<form>
  <div role="alert" tabindex="-1" id="error-summary">
    <h2>Bitte korrigieren Sie die folgenden Fehler:</h2>
    <ul>
      <li><a href="#street-good">Straße ist erforderlich.</a></li>
      <li><a href="#zip-good">PLZ muss aus 5 Ziffern bestehen.</a></li>
    </ul>
  </div>

  <label for="street-good">Straße</label>
  <input
    id="street-good"
    name="street"
    aria-invalid="true"
    aria-describedby="street-error"
  >
  <p id="street-error">Fehler: Bitte geben Sie Ihre Straße ein.</p>

  <label for="zip-good">PLZ</label>
  <input
    id="zip-good"
    name="zip"
    inputmode="numeric"
    aria-invalid="true"
    aria-describedby="zip-error"
  >
  <p id="zip-error">Fehler: Die PLZ muss aus 5 Ziffern bestehen.</p>
</form>

<script>
  document.getElementById('error-summary').focus();
</script>

Warum diese Fehler wiederkehren

Designsysteme priorisieren häufig Styling und Konsistenz im Erscheinungsbild, während Verhalten, Interaktion und semantische Korrektheit nachgelagert behandelt werden. Komponenten werden als Branding-Instrumente entwickelt, nicht als robuste, zugängliche Infrastruktur.

Hinzu kommt ein übermäßiges Vertrauen in automatisierte Tests. Diese können zwar bestimmte technische Probleme erkennen, decken jedoch nur einen Teil der tatsächlichen Barrieren ab. Wenn Barrierefreiheit primär über Tools geprüft wird, bleiben zentrale Aspekte wie Interaktionslogik, Fokusverhalten oder Verständlichkeit häufig unentdeckt. Gleichzeitig wird Barrierefreiheit in vielen Entwicklungsprozessen erst spät berücksichtigt, anstatt von Anfang an integraler Bestandteil von Architektur und Komponentenentwicklung zu sein.

Ein weiterer entscheidender Faktor ist die Abstraktionsebene moderner Frontend-Architekturen. Fehler entstehen oft nicht isoliert, sondern werden in Komponenten oder Mustern verankert und anschließend systematisch wiederverwendet. Ein fehlerhaft implementierter Button, ein unzugängliches Formularfeld oder ein inkonsistentes Interaktionsmuster kann sich so über ein gesamtes Produkt oder sogar mehrere Anwendungen hinweg verbreiten.

Gerade deshalb ist die Komponentenebene der zentrale Ansatzpunkt für nachhaltige Barrierefreiheit. Werden grundlegende UI-Bausteine korrekt implementiert, getestet und dokumentiert, lassen sich viele Fehler systematisch vermeiden, bevor sie sich im System ausbreiten.

Wie Teams früher prüfen

Ein wirksamer Ansatz zur Sicherstellung von Barrierefreiheit ist mehrschichtig und sollte früh im Entwicklungsprozess ansetzen. Zunächst sollten Teams konsequent mit semantischen Defaults arbeiten und native HTML-Elemente bevorzugen. Diese bringen bereits grundlegende Zugänglichkeit in Bezug auf Semantik, Interaktion und Fokusverhalten mit und reduzieren den Implementierungsaufwand erheblich.

Automatisierte Tests können diesen Prozess sinnvoll unterstützen, sollten jedoch realistisch eingeordnet werden. Sie sind vor allem geeignet, häufige und klar erkennbare Fehler – etwa fehlende Alternativtexte oder Kontrastprobleme – zu identifizieren, decken jedoch nur einen Teil der tatsächlichen Barrieren ab.

Ergänzend dazu sind gezielte manuelle Prüfungen notwendig. Dazu gehören insbesondere Tests der reinen Tastaturbedienung, die Überprüfung sichtbarer Fokuszustände, korrektes Fokusmanagement in Dialogen, Verhalten bei Zoom und Reflow (z. B. bis 400 %), erhöhte Textabstände sowie bewusst fehlerhafte Eingaben in Formularen zur Prüfung von Validierung und Feedback. Auch dynamische Inhalte und asynchrone Rückmeldungen sollten daraufhin überprüft werden, ob sie für assistive Technologien wahrnehmbar sind.

Fazit

Barrierefreiheit wird verbessert, wenn diese Muster frühzeitig erkannt und systematisch auf Komponenten- und Markup-Ebene adressiert werden. Entscheidend ist dabei nicht die nachträgliche Korrektur einzelner Fehler, sondern die Etablierung robuster technischer Grundlagen, die sich konsistent über ein gesamtes System hinweg durchsetzen.

Die zentrale Regel für die Entwicklung und Prüfung von Komponenten lautet: Wenn das Verhalten nativer Browserfunktionen ersetzt wird, muss auch deren vollständige Barrierefreiheit übernommen werden – einschließlich Semantik, Interaktion, Zuständen und Fokusverhalten.

Quellen