Barrierefreie Website Beispiele: Inspiration aus der Praxis

Warum es selten perfekte Beispiele gibt

Lass uns ehrlich sein: Eine Website, die alle Barrierefreiheits-Anforderungen zu 100% erfüllt, wirst du selten finden. Selbst große Unternehmen mit riesigen Budgets kämpfen mit einzelnen Kriterien.

Aber das ist okay! Statt nach Perfektion zu suchen, schauen wir uns an, was einzelne Websites richtig gut machen. Denn genau daraus kannst du lernen und für deine eigenen Projekte übernehmen.

Apple AirPods – Animations-Steuerung richtig gemacht

Apple ist bekannt für Design und Ästhetik. Aber wusstest du, dass sie auch bei Barrierefreiheit Vorreiter sind? Schauen wir uns die AirPods-Seite an: apple.com/airpods/

Screen Recording der Apple AirPods Seite – zeigt den Stop-Button bei Auto-Play Animationen und die Funktion „Bewegung reduzieren“.

Der Stop-Button bei Auto-Play Animationen

Auf der AirPods-Seite laufen automatisch Animationen ab. Aber Apple macht etwas richtig: Sie bieten einen Stop-Button an.

Warum ist das wichtig? Laut WCAG 2.2.2 (Pause, Stop, Hide) müssen automatische Animationen, die länger als 5 Sekunden laufen, pausierbar sein. Das hilft Menschen mit:

• Aufmerksamkeitsstörungen (ADHS)
• Epilepsie oder Anfallsleiden
• Vestibulären Störungen (Schwindel)

Was passiert, wenn du „Bewegung reduzieren“ aktivierst?

• Alle Animationen stoppen komplett
• Der Play-Button wird entfernt (weil nicht mehr nötig)
• Der Inhalt bleibt vollständig zugänglich

Aria-Labels bei „Mehr lesen“-Links

Ein weiteres Highlight bei Apple: Sinnvolle „Mehr lesen“-Links.

Viele Websites machen diesen Fehler:

<!-- ❌ SCHLECHT: Unklar für Screenreader -->
<a href="/produkt-details">Mehr lesen</a>
<a href="/produkt-details-2">Mehr lesen</a>
<a href="/produkt-details-3">Mehr lesen</a>

Zweck: Zeigt das Problem – Screenreader lesen nur „Mehr lesen, Mehr lesen, Mehr lesen“

Das Problem: Screenreader-Nutzer hören nur „Mehr lesen, Mehr lesen, Mehr lesen“ – aber worüber? Bei 5-10 Links wird das zur Geduldsprobe.

Apple löst das mit aria-label:

Warum das genial ist:

• Sehende Nutzer sehen nur „Learn more“ (clean design)
• Screenreader-Nutzer hören „Learn more, AirPods Pro 3“
• Erfüllt WCAG 2.4.4 (Link Purpose in Context)

Der Mythos: „Barrierefreiheit = hässliches Design“

Viele Designer denken: „Wenn ich eine barrierefreie Website baue, wird sie automatisch unattraktiv.“

Apple beweist das Gegenteil.

Die AirPods-Seite ist:

• Visuell beeindruckend mit Animationen
• Modern und minimalistisch
• Barrierefrei mit Stop-Buttons und aria-labels

Die Lektion: Barrierefreiheit und gutes Design schließen sich nicht aus. Sie ergänzen sich!

Microsoft – Hero Slider mit Stop-Button

Auch Microsoft zeigt, wie man Slider barrierefrei gestaltet. Schauen wir uns ihre Hero-Section an.

Der oft vergessene Stop-Button

Viele Websites haben automatische Slider – aber ohne Pause-Funktion. Das ist ein klassischer Fehler!

Microsoft macht es richtig:

• Der Hero-Slider hat einen sichtbaren Stop-Button
• Der Button hat eine Target Size von 44×44 Pixeln
• Das erfüllt sogar WCAG 2.5.5 Level AAA (nicht nur AA!)

Gov.uk – Tastaturnavigation im Menü

Die britische Regierungswebsite gov.uk hat viele gute Lösungen für Barrierefreiheit. Besonders das Navigationsmenü ist hervorragend umgesetzt.

Warum das Menü herausragend ist

Das Menü ist:

• Vollständig mit Tab und Enter bedienbar
• Hat sichtbare Fokus-Indikatoren
• Verwendet semantische HTML-Struktur
• Nutzt aria-expanded für Menü-Status
• Schließt automatisch mit ESC-Taste
• Schließt automatisch bei Fokus außerhalb
• Erfüllt WCAG 2.1.1 (Keyboard Accessible)

Die Überschrift als Link-Text

Hier macht Gov.uk etwas Cleveres: Sie verwenden die Headline als Überschrift (<h3>) innerhalb des Links.

Viele Entwickler packen ALLES in den <a>-Tag – also Überschriften, Absätze, Listen. Das ist falsch! Warum? Screenreader lesen dann den gesamten Text als einen einzigen Link vor. Bei langen Texten wird das zur Qual. Die Lösung: Nutze CSS mit ::after, um die gesamte Box klickbar zu machen – aber behalte semantisches HTML bei. So bleibt die Struktur für Screenreader verständlich und die User Experience gut.

<li class="gem-c-cards__list-item">
  <div class="gem-c-cards__list-item-wrapper">
    <h3 class="gem-c-cards__sub-heading govuk-heading-s">
      <a
        class="govuk-link gem-c-cards__link gem-print-force-link-styles"
        href="/browse/benefits"
      >Benefits</a>
    </h3>
    <p class="govuk-body gem-c-cards__description">
      Includes eligibility, appeals, tax credits and Universal Credit
    </p>
  </div>
</li>

.gem-c-cards__link::after {
  bottom: 0;
  content: "";
  left: 0;
  position: absolute;
  right: 0;
  top: 0;
}

Website: https://www.gov.uk/

WP Accessibility Day – Dark Mode & Dekorative Icons

Die Website WP Accessibility Day 2025 zeigt weitere Best Practices.

Dark Mode Switcher richtig integriert

Ein Dark Mode ist keine Pflicht laut WCAG – aber er verbessert die Benutzererfahrung enorm!

Warum ein guter Dark Mode wichtig ist:

• Hilft Menschen mit Lichtempfindlichkeit
• Reduziert Augenbelastung bei langer Nutzung

Dekorative Icons mit aria-hidden

Auf der Website findest du viele Icons. Aber sie sind richtig umgesetzt!

Die Regel:

• Dekorative Icons (rein visuell) → aria-hidden="true"
• Funktionale Icons (ohne Text) → aria-label am Button/Link

Überschriften-Hierarchie

Die Website hat eine perfekte Überschriften-Struktur:

• Keine Sprünge (z.B. von <h2> zu <h4>)
• Eine <h1> (Seitentitel)
• Logische <h2> für Hauptbereiche
• <h3> für Unterbereiche

Website: https://2025.wpaccessibility.day

Starte jetzt mit deiner eigenen Website

Brauchst du eine vollständige Checkliste?

Wir haben eine kostenlose Checkliste für dich erstellt, die dir den Einstieg super einfach macht. Von den ersten Schritten bis zur Umsetzung – alles übersichtlich zum Abhaken!

👉 Zur kostenlosen Barrierefreiheits-Checkliste