Barrierefreiheit von Anfang an

Barrierefreiheit ist kein Zusatz, den man am Ende einbaut. Das meiste bekommst du geschenkt, wenn du die passenden Elemente benutzt. Das haben wir den ganzen Tag schon getan, jetzt fassen wir es zusammen und prüfen es.

Was du am Ende kannst

• beschreiben, wer wie auf Barrieren stößt
• eine Seite mit der Tastatur prüfen
• typische Fehler finden und beheben
• begründen, wann ARIA nötig ist und wann nicht

Live-Coding zum Mitmachen

⤓ demo-05-barrierefreiheit.zip herunterladen

Der Ordner starter ist der Ausgangsstand, fertig der Stand nach dem Live-Coding.

Enthält: bilder/laufstrecke.svg, fest.html, index.html, kontakt.html, termine.html

Für wen?

Situation	Was hilft
blind, Screenreader	Semantik, Überschriften, Alternativtexte, Labels
sehbehindert, Zoom	Kontrast, vergrößerbarer Text, kein festes Layout
Farbenfehlsichtigkeit	Farbe nie als einziges Signal
motorisch eingeschränkt, nur Tastatur	alles per Tastatur bedienbar, sichtbarer Fokus, große Klickflächen
kognitiv	klare Sprache, einheitliche Bedienung, gute Fehlermeldungen
vorübergehend: gebrochener Arm, grelle Sonne	alles oben Genannte

In Deutschland verpflichtet die BITV 2.0 öffentliche Stellen zur Barrierefreiheit. Seit 2025 gilt mit dem Barrierefreiheitsstärkungsgesetz auch für viele private Angebote eine ähnliche Pflicht. Die technische Grundlage sind die WCAG. Sie kennen drei Stufen, A, AA und AAA, und jede enthält Anforderungen zu weit mehr als nur Kontrast. Die BITV 2.0 orientiert sich an AA; AAA wird in der Regel nicht für ganze Websites verlangt.

Die wirksamsten Regeln

1. Das richtige Element. Ein button kann fokussiert und mit der Tastatur ausgelöst werden, ganz von selbst.
2. Sinnvolle Gliederung. Eine h1, keine übersprungenen Ebenen, Bereiche mit main und nav.
3. Alternativtexte. Sagen, was das Bild aussagt. Reine Dekoration bekommt alt="".
4. Labels für alle Felder.
5. Aussagekräftige Links. Kein „hier“.
6. Sprache angeben. lang="de" am html-Element.
7. Kontrast von mindestens 4,5:1.

Drücke mehrmals die Tab-Taste: Wer bekommt den Fokus?

<p><button onclick="this.textContent = 'Geklickt'">Echter Button: Tab + Enter geht</button></p>
<p><span onclick="this.textContent = 'Geklickt'">Span mit onclick: nur mit der Maus erreichbar</span></p>

Der Sprunglink

Tastaturnutzer müssen sonst auf jeder Seite erst durch das ganze Menü. Deshalb kommt als erstes Element ein Link auf den Hauptinhalt:

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

Mit CSS lässt er sich später verstecken, bis er den Fokus bekommt.

ARIA: nur wenn nötig

ARIA-Attribute geben Hilfstechnologien Zusatzinformationen, etwa aria-label oder aria-expanded. Die erste Regel lautet: Benutze kein ARIA, wenn es ein passendes HTML-Element gibt. <button> schlägt <div role="button">, denn ARIA ändert nur die Ansage, nicht das Verhalten. Tastaturbedienung musst du dann selbst programmieren.

Sinnvoll ist ARIA, wenn HTML keine Antwort hat, zum Beispiel:

<nav aria-label="Hauptmenü">…</nav>     <!-- mehrere nav unterscheiden -->
<a href="termine.html" aria-current="page">Termine</a>   <!-- aktuelle Seite -->

Selbst prüfen

Fünf Minuten genügen für die meisten Probleme.

1. Tastatur: Maus weglegen. Kommst du mit Tab überall hin? Siehst du immer, wo du bist? Funktioniert Enter?
2. Zoom: Auf 200 Prozent stellen. Ist alles noch lesbar?
3. Automatik: In Edge und Chrome im DevTools-Tab Lighthouse den Bericht „Accessibility“ starten, in Firefox im Tab Barrierefreiheit. Automatische Tests finden aber nur einen Teil der Fehler.
4. Gliederung: Der Accessibility Tree in den DevTools zeigt, was ein Screenreader bekommt.

Live-Coding: Eine Seite reparieren

Die Seite fest.html im Starter sieht harmlos aus, hat aber sieben Probleme. Findest du sie?

fest.html

  <main>
    <h3>Vereinsfest 2026</h3>
    <img src="bilder/laufstrecke.svg" width="400" height="200">
    <h5>Rückblick</h5>
    <p>Bilder vom Fest gibt es <a href="index.html">hier</a>.</p>
    <p>Newsletter: <input type="email" placeholder="E-Mail"></p>
    <div class="knopf" onclick="alert('Eingetragen')">Eintragen</div>
  </main>

Nach der Reparatur:

fest.html

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

fest.html

  <main id="inhalt">
    <h1>Vereinsfest 2026</h1>
    <img src="bilder/laufstrecke.svg" alt="Die Festwiese im Stadtpark bei Sonnenaufgang." width="400" height="200">
    <h2>Rückblick</h2>
    <p>Mehr dazu auf der <a href="index.html">Startseite des Vereins</a>.</p>
    <form action="#" method="post">
      <p>
        <label for="newsletter">E-Mail für den Newsletter</label><br>
        <input id="newsletter" name="newsletter" type="email" autocomplete="email">
      </p>
      <p><button type="submit">Eintragen</button></p>
    </form>
  </main>

Übung

Starter für die Übung

⤓ uebung-05-barrierefreiheit.zip herunterladen

ZIP-Datei entpacken und den Ordner in VS Code öffnen (Datei → Ordner öffnen).

Enthält: bilder/laufstrecke.svg, fest.html, index.html, kontakt.html, sommerlauf.html, termine.html

Die Seite sommerlauf.html wurde in großer Eile gebaut. Im Browser wirkt sie fast in Ordnung.

Stufe 1: Finden

Lies den Code und prüfe die Seite mit der Tastatur. Schreibe alle Probleme auf. Es sind mehr als zehn.

Stufe 2: Struktur reparieren

Sprache, Titel, semantische Bereiche und Überschriftenebenen, außerdem Absätze statt div und ein Sprunglink.

Stufe 3: Inhalte reparieren

Alternativtexte (Das zweite Bild ist reine Wiederholung), Linktexte, Labels und ein echtes Formular mit einem echten Button.

Für Schnelle

Lass Lighthouse oder das Firefox-Werkzeug über deine reparierte Seite laufen. Bekommst du 100 Punkte? Welches Problem hätte das Werkzeug nie gefunden?