Barrierefreie Weboberflächen — Cheat Sheet

Der technische Spickzettel zum Seminar Modern UI und UX Engineering für Webanwendungen — Kriterien, Markup-Formen und Prüfwege zum Nachschlagen, wenn man weiß, dass etwas zu tun ist, aber nicht mehr genau was. Maßgeblich sind die WCAG 2.2 und die ARIA Authoring Practices; hier steht die Auswahl, die im Alltag tatsächlich gebraucht wird. Die Methodenseite — Nutzerforschung, Interface Design, Evaluation — liegt auf dem zweiten Blatt: UX, Interface Design und KI.

WCAG 2.2: Prinzipien, Stufen und neue Kriterien

Die vier Prinzipien sind kein Inhaltsverzeichnis, sondern vier Suchrichtungen für Befunde.

„Robust” meint assistive Techniken, nicht Browserkompatibilität.

Neu in 2.2 und im Alltag am häufigsten gerissen:

Modul: Standards und rechtlicher Rahmen

Rechtsrahmen und Nachweise

Drei Ebenen derselben Kette, keine konkurrierenden Anforderungen: technisch laufen alle drei auf die WCAG hinaus.

Die EN 301 549 enthält für Web keine eigenen Kriterien, sie verweist auf die WCAG — Fassungsstand deshalb immer mit Datum der Aussage nennen.

Modul: Standards und rechtlicher Rahmen

Nutzungssituationen und assistive Technik

Permanent, temporär und situativ stellen dieselbe Anforderung — einhändige Bedienung ist Dauerzustand, Gipsarm für Wochen, Kind auf dem Arm für Minuten. Das Modell ist ein Argument für die Anforderung, kein Ersatz für sie.

Der gemeinsame Nenner aller vier ist die Tastatur. Deshalb ist der Tastaturdurchlauf die billigste Prüfung mit der größten Reichweite.

Modul: Menschen, Nutzungssituationen und assistive Technologien

Semantisches HTML: Name, Rolle, Zustand, Wert

Vier Angaben, die eine assistive Technik braucht — und die Stellen, an denen sie üblicherweise fehlen.

<!-- kommt als leere Schaltfläche an -->
<div class="icon" onclick="loeschen()"><svg>…</svg></div>

<!-- Rolle und Name sind gesetzt -->
<button type="button" onclick="loeschen()">
  <svg aria-hidden="true">…</svg>
  <span class="sr-only">Eintrag entfernen</span>
</button>

Link, Button und div sind nicht austauschbar:

Was ein Eigenbau übernimmt, das ein natives Element mitbringt: Tastaturmuster, Rolle und Zustand, plattformübliches Touch-Verhalten — und künftige Verbesserungen, die beim nativen Element mit dem Browser kommen und beim Eigenbau nie von allein.

Gleichnamige Landmarks brauchen ein Label — <nav aria-label="Hauptnavigation"> —, wobei das Wort „Navigation” nicht ins Label gehört: Die Rolle wird ohnehin angesagt. Überschriftenebenen sind eine Aussage über die Struktur, die Schriftgröße ist eine Klasse.

Modul: Semantisches HTML als Grundlage

Tastatur, Fokus und Sprungziele

/* Indikator nie ersatzlos entfernen */
:focus-visible {
  outline: 3px solid #1b4a7a;
  outline-offset: 2px;
}
/* hält den Fokus unter einer klebenden Kopfzeile frei */
:target, :focus-visible { scroll-margin-top: 5rem; }

tabindex kennt drei Bedeutungen: positive Werte verschieben die Reihenfolge global (nicht verwenden), 0 nimmt in den Tablauf auf, -1 macht per Skript fokussierbar — der Normalfall für Sprungziele. Ohne tabindex="-1" am Ziel springt bei einem Skip-Link nur die Ansicht, der Fokus bleibt stehen.

Drei Fehlerbilder mit demselben Ergebnis — kein Weiterkommen: die Fokusfalle (Overlay, eingebettetes Widget), der unerwartete Kontextwechsel (Auswahl sendet sofort ab) und der verlorene Fokus (Element wird entfernt, ohne den Fokus zu setzen).

<dialog> mit showModal() bringt Fokussetzung, Fokusfang, inerten Hintergrund und Escape mit; role="dialog" auf einem div bringt nichts davon.

Modul: Tastatur, Fokus und Navigation

Formulare, Fehler und Statusmeldungen

<label for="gd">Geburtsdatum</label>
<input id="gd" required aria-describedby="gd-hilfe" autocomplete="bday">
<p id="gd-hilfe">Beispiel: 03.09.1974</p>

<!-- Fehler: Zustand melden, Ursache und Korrektur verknüpfen -->
<input id="gd" aria-invalid="true" aria-describedby="gd-fehler">
<p id="gd-fehler" role="alert">Das Datum liegt in der Vergangenheit.</p>

Das Sternchen für Pflichtfelder ist Optik; gemeldet wird die Pflicht über required. Zusammengehörige Eingaben brauchen fieldset und legend — ohne Legende wird nur die Option angesagt, nicht die Frage dazu.

Die Live Region muss im Dokument stehen, bevor der Text hineinkommt.

autocomplete nimmt nur standardisierte Werte an (given-name, family-name, email, postal-code …) — eigene Bezeichnungen wirken nicht. Bei der Anmeldung gilt: Passwort mit Einfügen und Einmallink per Mail sind zulässig, Zeichenrätsel und Rechenaufgaben nicht.

Modul: Barrierefreie Formulare und Interaktionen

Komponentenmuster

Eine Combobox braucht mindestens role="combobox", aria-expanded, aria-controls auf ein role="listbox" und eine Statuszeile mit der Trefferzahl. Eine Website-Navigation ist dagegen eine Linkliste in <nav> und kein role="menu" — wer Menü-Rollen setzt, schuldet Pfeiltasten, Escape und einen einzigen Tabstopp. Sortierbare Tabellen melden ihren Zustand über aria-sort an der Kopfzelle plus role="status".

Modul: Zugängliche UI-Komponenten

Kontrast, Zoom, Zielgrößen und Medien

/* Trefferfläche wachsen lassen, Symbol klein halten */
.icon-btn {
  min-width: 44px; min-height: 44px;
  display: inline-grid; place-items: center;
}
/* im erzwungenen Modus verschwinden Hintergrundfarben, ein Rahmen überlebt */
@media (forced-colors: active) {
  .tab[aria-selected="true"] {
    border-bottom: 3px solid ButtonText;
    forced-color-adjust: none;
  }
}

Für Reflow bis 400 Prozent: min-height statt height, max-width in rem, und keine Regel, die an der Bildschirmausrichtung hängt — fest montierte Geräte drehen nicht.

Modul: Visuelle und responsive Accessibility

Prüfen: Reichweite der Verfahren

Vier Fragen für den Screenreader-Rauchtest: Überschriftenliste aufrufen (ist die Struktur klar), Landmarkliste aufrufen (sind Bereiche anspringbar), Elementliste durchgehen (haben Elemente Namen), Filter ändern und hören (werden Änderungen gemeldet). Die geprüfte Kombination — etwa NVDA mit Firefox unter Windows — gehört in jeden Befund.

Zustände, die eine Prüfung erreichen muss: Dialog offen, Fehlerfall (ungültig absenden), leeres Ergebnis (unmöglichen Filter setzen), Ladezustand (Verbindung drosseln).

Ein Befund, der bearbeitet wird, trägt: Seite, Element, Reproduktionsschritte, Erwartet, Tatsächlich, Kriterium, geprüfte Kombination — und Auswirkung. Die letzte Zeile entscheidet über die Priorität; ohne sie bleibt es eine Formalie.

Modul: Accessibility Testing

Im Entwicklungsprozess verankern

Aus „Der Dialog ist barrierefrei” wird ein prüfbares Kriterium, indem man es in Sätze zerlegt: Fokus beim Öffnen auf der Überschrift, Fokus bleibt im Dialog, Escape schließt, nach dem Schließen liegt der Fokus wieder auf der auslösenden Schaltfläche. Vier Sätze, vier Tests — und derselbe Text taugt als Auftrag an einen Coding Agent.

Zuständigkeit hängt an Fragen, nicht an einer beauftragten Person: Design verantwortet Kontrast, Fokus, Zielgröße und Text; Entwicklung Semantik, Tastatur und Zustände; QA Prüfung und Nachweis; Product Owner Priorität und Termin.

Modul: Accessibility in Entwicklungsprozessen

Typische Fallen

• outline: none ohne Ersatz. Der Indikator verschwindet, der Ersatz kommt „später”. :focus-visible trennt Maus von Tastatur — :focus nicht.
• Positive tabindex-Werte. Sie ordnen die Reihenfolge global um; die visuelle Reihenfolge per order zu ändern und das Markup zu belassen, ist dieselbe Falle von der anderen Seite.
• aria-label, das von der sichtbaren Beschriftung abweicht. Die Sprachsteuerung ruft die sichtbare Beschriftung auf und findet nichts.
• aria-hidden auf einem fokussierbaren Element. Der Fokus landet im Nichts. Zusätzlich inert setzen oder aus dem Tablauf nehmen.
• ARIA als Ersatz für fehlendes Tastaturverhalten. Attribute melden Zustände, sie erzeugen keine Bedienbarkeit.
• Platzhaltertext als einzige Beschriftung. Er verschwindet beim Tippen — genau dann, wenn man ihn braucht.
• Fehler nur farblich markieren. Ohne aria-invalid und verknüpften Fehlertext kommt weder Zustand noch Ursache an.
• Gegen Weiß prüfen, obwohl das Element auf einer Farbfläche liegt. Und: nur den Ruhezustand messen, Hover, Fokus und Fehler auslassen.
• Zielgröße am Mauszeiger bemessen statt am Finger. 24 × 24 ist das WCAG-Minimum, 44 × 44 die praktikable Größe.
• Grüner automatischer Lauf als Konformitätsnachweis. Er belegt, dass Namen vorhanden sind, nicht dass sie sinnvoll sind.
• Das Quality Gate als Warnung einführen und nie scharf schalten. Ebenso wirkungslos: eine Schwelle, die der Bestand sofort reißt.
• Eine Erklärung veröffentlichen, die vollständige Konformität behauptet. Bekanntes Offenes gehört hinein — mit Behelf und Termin.

Zum Seminar Modern UI und UX Engineering für Webanwendungen