Barrierefreie UI-Muster: WCAG, WAI-ARIA und der APG

Aktualisiert am 14. Oktober 2026 · Lesezeit: 6 Min.

Wer nach „WCAG Combobox“ oder „WCAG Tabs“ sucht, landet in drei verschiedenen W3C-Dokumenten, die unterschiedliche Fragen beantworten. Diese Reihe erklärt jedes gängige Bedienmuster eines Online-Shops: wofür es da ist, welche WCAG-Kriterien gelten, ein kurzes korrektes HTML-Beispiel, das erwartete Tastaturverhalten und was eine automatische Prüfung finden kann und was nicht. Diese Seite erklärt, wie die Dokumente zusammenhängen, und listet alle Muster auf.

Das ist eine technische Anleitung, keine Rechtsberatung.

WCAG, WAI-ARIA und ARIA Authoring Practices im Vergleich

Dokument	Was es ist	Welche Frage es beantwortet
WCAG 2.2	W3C-Empfehlung, der Standard hinter der EN 301 549 und den meisten Gesetzen	Was das Ergebnis sein muss: Tastaturbedienung, Namen, Kontrast, Fehlermeldungen
WAI-ARIA 1.2	W3C-Empfehlung (6. Juni 2023) mit Rollen, Zuständen und Eigenschaften	Wie man assistiven Technologien mitteilt, was ein eigenes Element ist: `role="tab"`, `aria-expanded`
ARIA Authoring Practices Guide (APG)	Leitfaden der W3C WAI mit Mustern und Beispielen	Wie sich ein Widget verhalten soll: welche Tasten, welche Fokuswechsel, welche Attribute

Die WCAG nennen kein einziges Widget beim Namen. Sie verlangen zum Beispiel, dass jedes Bedienelement Name, Rolle und Zustand bereitstellt (4.1.2), dass alles per Tastatur funktioniert (2.1.1), dass der Fokus sichtbar ist (2.4.7) und dass die Struktur im Code steckt, nicht nur im Layout (1.3.1). Natives HTML liefert das meiste davon gratis. Wenn Sie etwas bauen, das HTML nicht hat – Tabs, eine Combobox mit Vorschlägen, ein Karussell –, können Sie es mit WAI-ARIA beschreiben, und der APG sagt Ihnen, welches Verhalten Nutzerinnen und Nutzer assistiver Technologien erwarten.

Das W3C beschreibt WAI-ARIA als Weg, „dynamische Inhalte und fortgeschrittene Bedienelemente“ barrierefrei zu machen, und den APG als Begleiter, der „Vorgehensweisen empfiehlt, die Entwicklern von Webanwendungen helfen, Widgets“ barrierefrei zu gestalten. Der APG ist keine Konformitätsanforderung: Sie können die WCAG auch mit einer anderen, gut getesteten Lösung erfüllen. Seine eigene Einleitung sagt, dass Tests mit assistiven Technologien „unverzichtbar sind, bevor Code aus diesem Leitfaden produktiv eingesetzt wird“.

Zuerst natives HTML

Die W3C-Note Using ARIA formulierte es als erste Regel für den Einsatz von ARIA: Wenn Sie ein natives HTML-Element oder -Attribut verwenden können, das die nötige Semantik und das nötige Verhalten schon eingebaut hat, verwenden Sie es, statt ein anderes Element umzufunktionieren und ARIA hinzuzufügen. Ihre weiteren Regeln: Ändern Sie native Semantik nur, wenn es wirklich nötig ist; alle interaktiven ARIA-Bedienelemente müssen per Tastatur bedienbar sein; setzen Sie nie role="presentation" oder aria-hidden="true" auf ein fokussierbares Element. (Diese Note ist inzwischen als eingestellter Entwurf veröffentlicht und verweist für weitere Hinweise auf den APG, aber ihre Regeln sind weiterhin die gemeinsame Grundlage.)

Der APG sagt dasselbe mit eigenen Worten: „Kein ARIA ist besser als schlechtes ARIA“ und „eine Rolle ist ein Versprechen“. Wer einem div role="button" gibt, verspricht einen Button, aber „ARIA-Rollen sorgen nicht dafür, dass Browser Tastaturverhalten oder Gestaltung bereitstellen“ – Sie müssen das Element selbst fokussierbar machen und auf Enter und Leertaste reagieren lassen.

<!-- Nativ: Name, Rolle, Fokus und Tastatur gratis -->
<button type="button">In den Warenkorb</button>

<!-- Nachgebaut: jedes Teil muss von Hand ergänzt werden und wird oft vergessen -->
<div role="button" tabindex="0" onclick="add()" onkeydown="addOnEnterOrSpace(event)">In den Warenkorb</div>

Die Muster dieser Reihe

Grundlegende Bedienelemente

Button oder Link – Buttons lösen etwas aus, Links führen woanders hin
Links, die in einem neuen Tab öffnen – wann es sinnvoll ist und wie man darauf hinweist
Deaktivierte Buttons – disabled oder aria-disabled, Kontrast und Erklärungen
Radiobuttons und Checkboxen – Labels, Gruppen und eigene Gestaltung

Pop-ups und Overlays

Dropdown, Select und Combobox – zuerst das native select, dann die APG-Combobox
Modaler Dialog – Fokus hinein, Fokus halten, Fokus zurück
Tooltip – WCAG 1.4.13 und warum das APG-Muster noch ein Entwurf ist

Navigation und Struktur

Navigationsmenü – warum der APG für Websites eine Disclosure-Navigation empfiehlt und keine menubar
Breadcrumbs – ein beschriftetes nav und aria-current="page"
Tabs – tablist, Pfeiltasten und automatische Aktivierung
Akkordeon – Überschriften mit Buttons oder details und summary
Datentabelle – echtes table-Markup, Kopfzellen und Beschriftungen
Karussell – Pause-Steuerung, beschriftete Folien, kein überraschendes Weiterdrehen

Formulare

Formularvalidierung und Fehlermeldungen – Fehler als Text, mit dem Feld verknüpft, angesagt

Was eine automatische Prüfung bei Mustern findet

Unsere Prüfungen führen axe-core in einem echten Browser auf der Seite aus, so wie sie geladen wird. Bei Mustern finden sie damit zuverlässig strukturelle Probleme: Buttons und Links ohne Namen, Formularfelder ohne Label, unbekannte Rollen, ARIA-Attribute, die für eine Rolle nicht erlaubt sind oder auf eine fehlende ID verweisen, ein tab außerhalb einer tablist, fokussierbare Elemente, die mit aria-hidden versteckt sind. Jeder Befund verweist auf seine Karte in der Regelbibliothek.

Verhaltensprobleme finden sie nicht: ob die Pfeiltasten zwischen Tabs wechseln, ob der Fokus in einen Dialog springt und danach zurückkehrt, ob sich aria-expanded ändert, wenn das Menü aufgeht, ob sich ein Karussell anhalten lässt. Inhalte, die beim Laden der Seite verborgen sind, etwa ein geschlossener Dialog, werden gar nicht geprüft; die Browser-Erweiterung prüft die Seite in dem Zustand, den Ihr Browser gerade zeigt, sodass Sie den Dialog vorher öffnen können. Planen Sie den Teil mit Tastatur und Screenreader so, wie es in WCAG testen beschrieben ist.

Beginnen Sie mit der kostenlosen Prüfung einer Seite. Sie ist eine automatische Prüfung, kein vollständiges Audit.

Häufige Fragen

Was ist der Unterschied zwischen WCAG und WAI-ARIA?

Die WCAG legen fest, wie das Ergebnis aussehen muss, etwa dass jedes Bedienelement Name, Rolle und Zustand bereitstellt (4.1.2). WAI-ARIA ist eine W3C-Spezifikation mit Rollen, Zuständen und Eigenschaften – ein Weg zu diesem Ergebnis, wenn natives HTML nicht ausreicht.

Verlangen die WCAG ARIA?

Nein. Die WCAG sind technologieneutral. Native HTML-Elemente wie button, a, input, select und table erfüllen die Kriterien meist ganz ohne ARIA. ARIA braucht man für eigene Widgets, die HTML nicht bietet, etwa Tabs.

Was ist der ARIA Authoring Practices Guide (APG)?

Eine Ressource der W3C WAI, die beschreibt, wie gängige Widgets sich verhalten sollen: welche Rollen und Zustände sie nutzen und welche Tasten sie unterstützen. Er ist eine Empfehlung, keine WCAG-Anforderung, und das W3C bittet darum, seine Beispiele vor dem Produktiveinsatz mit assistiven Technologien zu testen.

Was ist die erste Regel von ARIA?

Wenn ein natives HTML-Element oder -Attribut die nötige Semantik und das nötige Verhalten schon mitbringt, verwenden Sie es, statt einem anderen Element ARIA hinzuzufügen. Ein echter Button ist besser als ein div mit der Rolle button.

Kann eine automatische Prüfung UI-Muster testen?

Teilweise. Sie findet fehlende Namen, ungültige ARIA-Rollen und -Attribute sowie fehlerhafte Eltern- und Kind-Rollen. Sie kann nicht beurteilen, ob die Pfeiltasten funktionieren, ob der Fokus richtig wandert oder ob sich Zustände während der Bedienung aktualisieren.

Quellen

W3C WAI, WAI-ARIA overview: https://www.w3.org/WAI/standards-guidelines/aria/
W3C WAI, ARIA Authoring Practices Guide, Read Me First: https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/
W3C WAI, APG patterns: https://www.w3.org/WAI/ARIA/apg/patterns/
W3C, Using ARIA (eingestellter Entwurf, Regeln für den Einsatz von ARIA): https://www.w3.org/TR/using-aria/