Barrierefreie Website erstellen: Schritt-für-Schritt nach WCAG 2.2 AA (2026)

Eine barrierefreie Website zu erstellen klingt nach Pflichtprogramm, ist aber kein Hexenwerk. Wer von Anfang an mit den richtigen Bausteinen arbeitet, baut sie ohne Mehraufwand. Wer eine bestehende Site nachträglich anpasst, hat mehr Arbeit, aber auch klare Etappenziele. Dieser Artikel zeigt beide Wege: den Neubau Schritt für Schritt und die Nachrüstung mit Priorisierung.

Der Fokus liegt auf der Erstellungs-Perspektive: Welche HTML-Bausteine sind die Basis, wie löse ich Kontrast-Probleme, wann brauche ich ARIA, welche Tests muss ich machen. Wer die rechtlichen Grundlagen sucht, findet sie im Schwester-Artikel Barrierefreiheit im Webdesign: BFSG 2025 Pflicht. Wer eine fertige Site prüfen will, nutzt unsere 7-Schritte-Anleitung zur Barrierefreiheits-Prüfung.

Was "barrierefrei" rechtlich und technisch heißt

Barrierefreiheit hat im Web zwei Ebenen: die rechtliche (Was muss ich erfüllen?) und die technische (Was bedeutet das konkret im Code?). Beide Ebenen treffen sich in der WCAG 2.2 AA, dem internationalen Standard, den auch das deutsche BFSG referenziert.

Die WCAG basiert auf vier Prinzipien, oft mit dem Akronym POUR abgekürzt:

WCAG 2.2 AA bedeutet: Sie erfüllen alle A- und alle AA-Kriterien des Standards (insgesamt 50 Stück). AAA ist möglich, aber nicht Pflicht und für viele Inhalte schlicht nicht umsetzbar.

Schritt 1: Semantisches HTML als Fundament

Eine barrierefreie Website fängt nicht beim Design an, sondern beim Markup. HTML hat seit Version 5 (2014) eine ganze Reihe semantischer Elemente, die Hilfstechniken wie Screenreadern Bedeutung vermitteln. Vor 2014 musste man alles mit <div> und <span> bauen, heute nutzt man:

<header>...</header>
<nav>...</nav>
<main>
  <article>
    <h1>Haupt-Titel</h1>
    <section>
      <h2>Unter-Titel</h2>
      ...
    </section>
  </article>
  <aside>...</aside>
</main>
<footer>...</footer>

Häufigster Fehler: mehrere <h1> auf einer Seite oder Überschriften-Hierarchie wird übersprungen (h2 nach h4). Screenreader nutzen die Überschriften zum schnellen Springen, eine kaputte Hierarchie zerstört diese Navigation.

Test: Browser-Devtools öffnen, Accessibility-Tree anzeigen lassen. Oder Plugin "headingsMap" installieren. Die Überschriften-Struktur muss linear sein: h1 → h2 → h3, kein Sprung.

Bonus-Regel: Pro Seite genau eine <h1>. Im Markup darf nichts vor der <h1> als Hauptinhalt stehen, das macht Screenreader-Navigation kaputt.

Schritt 2: Kontrast und Lesbarkeit

Hier scheitern die meisten Sites. Die WCAG verlangt:

Tools zum Messen:

• WebAIM Contrast Checker (Web, kostenlos)
• Axe DevTools (Browser-Extension)
• Stark (Figma-Plugin für Designer)

Häufiger Fehler: Hellgrauer Body-Text auf weißem Hintergrund. #999 auf #FFF ergibt 2,85:1, das ist nicht WCAG-konform. Minimal-Standard für Body-Text ist #666 auf #FFF (5,74:1).

Zoom-Test: Browser auf 200 Prozent zoomen. Layout darf nicht zerbrechen, kein horizontaler Scroll, alle Inhalte müssen lesbar bleiben.

Spezialfall Dark Mode: Auch hier gelten die Kontrastregeln. Helle Schrift auf Dunkelblau wirkt schick, ist aber oft nicht WCAG-konform. Standard für Dark Mode: #E5E7EB auf #1F2937 (12,86:1, exzellent).

Schritt 3: Tastatur-Bedienbarkeit

Etwa 7 Prozent aller Nutzer können keine Maus verwenden (motorische Einschränkungen, blind, RSI-Geplagte). Für sie ist die Tastatur das einzige Werkzeug.

Pflicht-Test: Maus weglegen. Mit Tab durch die Seite navigieren. Mit Enter Links und Buttons aktivieren. Mit Esc Modals schließen. Mit Pfeiltasten durch Listen springen.

Häufige Fehler:

• Kein sichtbarer Focus-Indikator. Viele Designer entfernen den blauen Browser-Default-Focus aus Ästhetik. Das macht die Seite unbedienbar.
• Falsche Tab-Reihenfolge. CSS-Reorder mit flex-direction: row-reverse verändert visuell die Reihenfolge, aber nicht die Tab-Reihenfolge. Das verwirrt Tastatur-Nutzer.
• Maus-only-Interaktionen. Hover-Menüs, die nur per Mouseover öffnen, sind per Tastatur unbedienbar. Lösung: zusätzliche Tastatur-Trigger (Enter, Pfeiltasten).
• Focus-Falle in Modals. Beim Öffnen eines Modals muss der Focus ins Modal springen, beim Schließen zurück. Sonst landet der Tastatur-Nutzer wieder am Seitenanfang.

Code-Beispiel: Sichtbarer Focus-Ring

/* SCHLECHT: Focus entfernt */
button:focus { outline: none; }

/* GUT: Focus stilisiert, aber sichtbar */
button:focus-visible {
  outline: 2px solid #075CE1;
  outline-offset: 2px;
}

Der CSS-Pseudo-Selektor :focus-visible ist die elegante Lösung: Focus zeigt sich nur, wenn der Nutzer tatsächlich Tastatur verwendet, nicht bei reinem Maus-Klick.

Schritt 4: ARIA, das oft missverstandene Werkzeug

ARIA (Accessible Rich Internet Applications) ist eine Sammlung von HTML-Attributen, die Hilfstechniken zusätzliche Bedeutung vermitteln. ARIA wird oft falsch eingesetzt. Die Regel Nummer 1 lautet:

Kein ARIA ist besser als falsches ARIA.

Wenn Sie ein Button braucht, nutzen Sie <button>. Nicht <div role="button" tabindex="0">. Native HTML-Elemente bringen Tastatur-Support, Screenreader-Ansage und Focus-Management von Haus aus.

ARIA wird sinnvoll, wenn HTML allein nicht reicht. Beispiele:

Live-Region für dynamische Inhalte:

<div aria-live="polite" id="form-status">
  <!-- Wird nach Formular-Submit per JS gefüllt -->
</div>

Screenreader liest den Inhalt vor, sobald er sich ändert, ohne dass der Nutzer dort navigieren muss.

Label für Icon-Buttons:

<button aria-label="Menü schließen">
  <svg>...</svg>
</button>

Ohne Label liest der Screenreader nur "Button".

Aria-expanded für Akkordeons:

<button aria-expanded="false" aria-controls="panel-1">
  Mehr Informationen
</button>
<div id="panel-1" hidden>...</div>

Beim Aufklappen wird per JS aria-expanded="true" und hidden entfernt. Screenreader meldet "ausgeklappt".

Eine vollständige Referenz liefert der ARIA Authoring Practices Guide des W3C.

Schritt 5: Formulare und Fehlerbehandlung

Formulare sind die schwierigste Disziplin. Hier konzentrieren sich die meisten Barrierefreiheits-Verstöße.

Pflicht 1: Jedes Input braucht ein Label.

<!-- SCHLECHT -->
<input type="email" placeholder="E-Mail">

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

Placeholder ist kein Label. Sobald der Nutzer tippt, verschwindet der Placeholder und er sieht nicht mehr, was rein muss.

Pflicht 2: Pflichtfelder klar markieren.

<label for="name">
  Name <span aria-label="Pflichtfeld">*</span>
</label>
<input type="text" id="name" required aria-required="true">

Visuelles Sternchen plus aria-label für Screenreader-Nutzer.

Pflicht 3: Fehlermeldungen mit Bezug.

<label for="email">E-Mail</label>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">
<p id="email-error">Bitte eine gültige E-Mail-Adresse eingeben.</p>

aria-describedby verknüpft Input mit Fehlermeldung. Beim Focus liest der Screenreader Label plus Fehlertext.

Pflicht 4: Autocomplete-Hints für Standard-Felder.

Browser können Felder automatisch ausfüllen, wenn das autocomplete-Attribut korrekt gesetzt ist. Das hilft motorisch eingeschränkten Nutzern enorm.

<input type="text" autocomplete="given-name">
<input type="text" autocomplete="family-name">
<input type="tel" autocomplete="tel">
<input type="email" autocomplete="email">
<input type="text" autocomplete="street-address">

Schritt 6: Screenreader-Tests durchführen

Lighthouse erkennt etwa 30 bis 40 Prozent der echten Barrieren. Den Rest finden Sie nur, indem Sie Ihre Seite mit einem Screenreader durchgehen.

Setup für Windows-Nutzer:

1. NVDA herunterladen (nvaccess.org, kostenlos).
2. Installieren, starten (Tastenkombination: NVDA + N).
3. Seite öffnen, mit Pfeiltasten + Tab durch die Seite.
4. Wichtige NVDA-Kürzel: H springt zu nächster Überschrift, K zu nächstem Link, F zu nächstem Formular-Feld.

Setup für Mac-Nutzer:

1. VoiceOver per Cmd + F5 aktivieren.
2. Navigation: Ctrl + Option + Pfeiltasten.
3. Items mit Ctrl + Option + Leertaste aktivieren.
4. Rotor für Schnell-Navigation: Ctrl + Option + U.

Test-Routine:

Wer hier durchhält, hat eine wirklich barrierefreie Site, nicht nur eine, die im automatischen Test grün ist.

Was die Erstellung einer barrierefreien Website kostet

Die Investition hängt davon ab, ob Sie neu bauen oder eine bestehende Site nachrüsten. Drei Lektionen aus Bielefelder Audit-Praxis:

Lektion 1: Audit zuerst, dann Fix. Wer ohne Audit fixt, verschwendet Geld an Symptome. Ein systematisches Audit nach WCAG 2.2 AA mit priorisierter Maßnahmenliste kostet 1.500 bis 2.500 € und spart oft das Doppelte beim Fix.

Lektion 2: Code-Refactor ist günstiger als Plugin-Overlays. Overlay-Widgets wie UserWay oder accessiBe versprechen Compliance per Klick, sind aber laut WebAIM und mehreren Gerichtsurteilen (Domino's Pizza, Eyebobs in den USA) nicht ausreichend. Sauberer Code schlägt jedes Overlay.

Lektion 3: Monitoring verhindert Rückfall. Eine Redaktion bricht Compliance schnell wieder (Alt-Text vergessen, falsches Überschriften-Tag). Quartalsweises Monitoring für 1.200 € pro Jahr hält die Compliance stabil.

Bielefeld-Bezug: Wer ist betroffen und was tun?

In Bielefeld sind seit Juni 2025 besonders folgende Branchen unter BFSG-Pflicht:

• Online-Händler aus OWL: Möbel-, Mode- und Spielwaren-Anbieter mit eigenem Shop fallen direkt darunter.
• Banken und Sparkassen: Sparkasse Bielefeld, Bielefelder Volksbank haben ihre Online-Portale bereits 2024/2025 umgestellt.
• Versorger und Mobilität: moBiel, Stadtwerke Bielefeld, Bielefelder Versorgungswerke prüfen ihre digitalen Tickets und Apps.
• Bildungsanbieter mit Online-Buchung: VHS Bielefeld, Erwachsenenbildung mit eigenem Buchungssystem.

Wer hier vor Ort eine BFSG-Konformität braucht, kann sich über unsere Seite Barrierefreies Webdesign Bielefeld informieren. Speziell für die geforderte BFSG-Erklärung haben wir eine eigene Vorlage unter Erklärung zur Barrierefreiheit.

Die häufigsten 8 Fehler beim Erstellen barrierefreier Websites

Aus rund 40 Audits, die wir in Bielefeld und OWL durchgeführt haben, die Top-Fehler in der Reihenfolge der Häufigkeit:

1. Kontrast zu gering im Body-Text (in 78 Prozent der Audits Problem)
2. Fehlender oder unsichtbarer Focus-Indikator (in 71 Prozent)
3. Bilder ohne Alt-Text oder nichtssagender Alt-Text (in 63 Prozent)
4. Formular-Inputs ohne <label> (in 58 Prozent)
5. Überschriften-Hierarchie kaputt (in 51 Prozent)
6. Cookie-Banner als Focus-Falle (in 47 Prozent)
7. Decorative ARIA-Roles missbraucht (in 39 Prozent)
8. Sprache nicht gesetzt (<html lang="de"> fehlt) (in 33 Prozent)

Diese acht Punkte zu lösen bringt eine Site von etwa 60 Prozent WCAG-Konformität auf 85 bis 90 Prozent.

Werkzeuge: Was wir und Sie täglich nutzen

Für Bielefeld-Agenturen empfehlen wir das Set axe DevTools + NVDA + Wave als kostenlose Basis und Pa11y für CI-Integration in eigene Projekte.

Wann ein Profi nötig ist

Sie können den Großteil dieses Artikels in Eigenregie umsetzen, wenn Sie Code-Zugriff und Geduld haben. Drei Szenarien, in denen Sie einen Profi brauchen:

1. Komplexe Web-Apps mit Custom-Widgets. Datenpicker, Drag-and-Drop, Sortable-Tabellen, Live-Karten. Hier ist ARIA-Expertise nötig, die Fehlerquote von Eigenbau ist hoch.
2. E-Commerce mit Checkout-Flow. Mehrstufige Formulare, Validierung, Live-Updates der Warenkorb-Summe. Hier hängt sehr viel Conversion an Barrierefreiheit.
3. Audits mit Rechtsverbindlichkeit. Vor BFSG-Marktüberwachung oder bei Abmahnung brauchen Sie ein zertifiziertes Audit. Eigenarbeit reicht hier nicht.

In allen anderen Fällen können Sie viel selbst stemmen, mit den oben gezeigten Werkzeugen und einer disziplinierten Test-Routine. Wer die Umsetzung lieber abgibt, kann bei uns eine barrierefreie Website erstellen lassen: Konzept, Design und Entwicklung nach WCAG 2.2 AA aus einer Hand, inklusive BFSG-Erklärung.

Fazit: Barrierefrei ist Bauplan, nicht Bonus

Barrierefreiheit ist kein nettes Extra mehr, sondern Pflicht-Bauteil jeder modernen Website. Wer von Anfang an mit semantischem HTML, sauberem Kontrast, Tastatur-Bedienbarkeit und Screenreader-Tests baut, hat keinen Mehraufwand, sondern ein robusteres Produkt.

Die rund 8 Millionen Menschen in Deutschland, die auf Barrierefreiheit angewiesen sind, sind dabei nur die offensichtliche Zielgruppe. Indirekt profitieren alle Nutzer: bessere Lesbarkeit, sauberere Navigation, schnellere Seiten. Und Google honoriert es, denn Barrierefreiheits-Signale fließen indirekt in Core Web Vitals und Page Experience ein.

Für Bielefeld und OWL beraten wir Sie persönlich bei Audit, Fix oder Neubau. Schreiben Sie uns über die Kontaktseite oder vereinbaren Sie ein Erstgespräch.

Weiterlesen

• Barrierefreiheit im Webdesign: BFSG 2025 Pflicht
• Barrierefreiheit: Pflicht, Umsetzung und Selbst-Check
• Website auf Barrierefreiheit prüfen: 7-Schritte-Anleitung
• Barrierefreies Webdesign Bielefeld: Agentur, Kosten, Vorgehen
• Barrierefreie Website Kosten: Audit, Fix, Neubau
• Erklärung zur Barrierefreiheit: BFSG-Pflicht-Statement
• Lexikon: WCAG
• Lexikon: BFSG
• Lexikon: ARIA