ARIA und Barrierefreiheit im Onlineshop: wann es hilft, wann es schadet

Veröffentlicht am 28. Oktober 2026

ARIA hilft Ihrem Shop nur dort, wo kein normales HTML-Element die Aufgabe erfüllt, etwa bei einem Karussell oder der Ansage „In den Warenkorb gelegt“. Überall sonst gilt: ein echter Button, ein echtes Auswahlfeld, ein echtes Formular bringen Tastaturbedienung und Ansage schon mit, ein Nachbau mit ARIA muss beides selbst leisten. Und falsches ARIA ist laut W3C schlechter als gar keins (APG).

Dieser Artikel zeigt, was ARIA ist, welche Shop-Bausteine es brauchen und welche nicht, wie Sie den Einsatz selbst im Browser prüfen und was Sie Ihre Agentur oder Ihren Theme-Anbieter fragen. Die Einordnung in die übrigen Anforderungen finden Sie in unserem Überblick WCAG 2.2 für Onlineshops.

Was ARIA ist

ARIA steht für Accessible Rich Internet Applications. Die aktuelle Fassung ist WAI-ARIA 1.2, eine W3C-Empfehlung vom 6. Juni 2023. ARIA besteht aus Attributen, die Ihr Theme in den HTML-Code schreibt, zum Beispiel role="dialog", aria-expanded="true" oder aria-label="Warenkorb". Sie sagen Hilfstechnik wie Screenreadern drei Dinge:

Rolle: was ein Element ist (Dialog, Reiter, Schieberegler).
Zustand: wie es gerade steht (aufgeklappt, ausgewählt, Wert 3).
Eigenschaft: wie es heißt und womit es zusammenhängt.

Entscheidend für Sie als Shopbetreiber: ARIA ändert nur, was angesagt wird, nicht, wie sich etwas verhält. Das ARIA Authoring Practices Guide des W3C nennt das „A role is a promise“: Wer einem div die Rolle Button gibt, verspricht, dass er sich auch per Tastatur wie ein Button bedienen lässt. ARIA-Rollen liefern laut derselben Seite weder Tastaturverhalten noch Gestaltung mit. Als Vergleich wählt der Leitfaden ausgerechnet ein Shop-Beispiel: Eine Rolle ohne das zugehörige Verhalten sei wie ein Button „Place Order“, der die Bestellung abbricht und den Warenkorb leert.

Die Regeln zur Verwendung von ARIA

Das W3C-Dokument Using ARIA fasst den richtigen Einsatz in vier Regeln. Gut zu wissen: Das W3C führt dieses Dokument inzwischen als Discontinued Draft; die vier Regeln bleiben laut Statusvermerk zum Nachschlagen erhalten, für weitere Anleitung verweist das W3C dort auf den ARIA Authoring Practices Guide (APG). Welche ARIA-Attribute auf welchem HTML-Element erlaubt sind, regelt ARIA in HTML, eine W3C-Empfehlung in der Fassung vom 11. August 2026. Die Regeln sinngemäß übersetzt:

Natives HTML zuerst. Wenn es ein HTML-Element oder -Attribut gibt, das die gewünschte Bedeutung und das Verhalten schon mitbringt, nehmen Sie das, statt ein anderes Element mit ARIA umzubauen.
Native Bedeutung nicht überschreiben, außer es muss wirklich sein.
Alles Interaktive mit ARIA muss per Tastatur bedienbar sein. Wer role="button" setzt, muss dafür sorgen, dass das Element den Fokus bekommt und mit Enter beziehungsweise Return und mit der Leertaste auslöst.
Kein role="presentation" und kein aria-hidden="true" auf fokussierbaren Elementen. Sonst landen manche Nutzer mit dem Fokus auf „nichts“.

Das APG stellt dem eine Überschrift voran, die als Faustregel taugt: „No ARIA is better than Bad ARIA“. Für jeden gängigen Baustein beschreibt das APG ein Muster (Pattern) mit Rollen, Zuständen und der erwarteten Tastaturbedienung. Das ist die Referenz, an der Sie ein selbst gebautes Element messen.

Was die Zahlen sagen

Die WebAIM Million 2026 hat im Februar 2026 die Startseiten der eine Million meistbesuchten Websites automatisch geprüft:

82,7 % der Startseiten nutzten ARIA (ohne Landmark-Rollen gezählt), 2025 waren es 79,4 %.
Startseiten mit ARIA hatten im Schnitt 59,1 erkannte Fehler, Startseiten ohne ARIA 42.
5,7 % der Startseiten hatten ein ARIA-Menü (role="menu"); bei 22 % davon führte das Menü laut WebAIM zu Barrieren, weil das nötige Menü-Markup und die Tastaturbedienung fehlten.

WebAIM schreibt selbst dazu, dass das nicht beweist, dass ARIA diese Fehler verursacht hat, denn die Seiten mit ARIA waren auch komplexer. Unsere Einschätzung: Mehr ARIA bedeutet nicht mehr Barrierefreiheit. Wenn Ihr Theme viel ARIA enthält, lohnt sich die Prüfung unten erst recht.

Typische Shop-Bausteine: richtiger und falscher Einsatz

Die Tabelle zeigt für typische Shop-Bausteine die native Lösung, das passende APG-Muster für eigene Nachbauten und den Fehler, den Sie beim Prüfen suchen.

Baustein	Besser nativ	Wenn selbst gebaut: ARIA richtig	Typischer Fehler	WCAG 2.2
Mini-Warenkorb als Overlay	HTML-Element `<dialog>`, geöffnet mit `showModal()`	Dialog-Muster: `role="dialog"`, `aria-modal="true"`, Name über `aria-labelledby` auf die sichtbare Überschrift; beim Öffnen springt der Fokus in den Dialog, Escape schließt	Overlay ist ein `div` ohne Rolle und Namen; der Fokus bleibt auf der Seite dahinter	4.1.2, 2.4.3
Mengen-Stepper (Plus und Minus)	`<input type="number">` mit Beschriftung, hat laut ARIA in HTML schon die Rolle `spinbutton`; Plus und Minus als echte `<button>` mit Namen wie „Menge erhöhen“	Spinbutton-Muster: `role="spinbutton"` mit `aria-valuenow`, `aria-valuemin`, `aria-valuemax`; Pfeil hoch und runter ändern den Wert	Plus und Minus sind Symbole ohne Namen, Screenreader sagt nur „Schalter“	4.1.2
Varianten, Farbfelder, Größen	`<fieldset>` mit `<legend>` („Farbe“) und `<input type="radio">` je Variante	Radio-Group-Muster: `role="radiogroup"` mit Namen, je Feld `role="radio"` und `aria-checked`	Farbfeld ohne Text, Name fehlt („Schalter“ statt „Dunkelblau“); `aria-checked` auf einem echten Radio-Input, was ARIA in HTML verbietet	4.1.2, 1.3.1
Akkordeon (Details, Versand, Pflege)	`<details>` mit `<summary>`	Akkordeon-Muster: Überschrift mit Button, `aria-expanded` wechselt zwischen `true` und `false`, `aria-controls` zeigt aufs Panel	`aria-expanded` bleibt beim Klicken immer gleich; die Überschrift ist ein `div` mit Klick-Skript	4.1.2
Tabs (Beschreibung, Bewertungen)	Es gibt kein natives Tab-Element. Unsere Empfehlung: Abschnitte mit Überschriften untereinander oder ein Akkordeon	Tabs-Muster: `tablist`, `tab`, `tabpanel`, aktiver Reiter mit `aria-selected="true"`; Pfeil links und rechts wechseln den Reiter	Rollen gesetzt, aber keine Pfeiltasten-Bedienung, sodass nur der erste Reiter erreichbar ist, oder `aria-selected` bleibt falsch	4.1.2, 2.1.1
Slider, Karussell	Kein natives Element; Startseiten-Slider ganz weglassen ist eine Option	Karussell-Muster: `aria-roledescription="carousel"`, Name, Schaltflächen für Weiter und Zurück, bei automatischem Wechsel zusätzlich Start/Stopp; optional `aria-live="off"`, solange es automatisch läuft, sonst `polite`	`aria-live="polite"` bei automatischem Wechsel, der Screenreader liest ständig neue Folien vor; versteckte Folien bleiben mit Tab erreichbar	4.1.2, 2.2.2 bei automatischem Wechsel
Meldung „In den Warenkorb gelegt“	Kein natives Element	Leerer Container mit `role="status"` schon beim Laden der Seite; laut MDN wirkt er wie `aria-live="polite"` und `aria-atomic="true"`. Der Text wird erst bei Bedarf hineingeschrieben	Container wird erst zusammen mit der Meldung eingefügt und deshalb oft nicht angesagt (MDN); nur die Zahl am Warenkorb-Symbol ändert sich	4.1.3
Filter auf- und zuklappen	`<button>` mit `aria-expanded` nach dem Disclosure-Muster oder `<details>`	`aria-expanded` auf dem Button, der aufklappt, nicht auf der Liste; Wert wechselt bei jedem Klick	`aria-expanded` am falschen Element oder nie aktualisiert; Filterliste als `role="menu"`	4.1.2
Hauptnavigation	`<nav>` mit normalen Links	Kein ARIA-Menü nötig; laut APG verlangt das Menü-Muster komplexe Funktionen, die eine typische Seitennavigation nicht braucht; für aufklappbare Linkgruppen passt das Disclosure-Muster	`role="menu"` ohne die zugehörige Pfeiltasten-Bedienung (siehe WebAIM-Zahl oben)	4.1.2
Symbol-Buttons (Suche, Merkliste, Konto)	`<button>` mit sichtbarem Text oder mit `aria-label`	Name per `aria-label`, der den sichtbaren Text enthält	`aria-label` weicht vom sichtbaren Text ab; `aria-hidden="true"` auf dem Button selbst	4.1.2, 2.5.3

Die Kürzel der letzten Spalte: 1.3.1 Info und Beziehungen, 2.1.1 Tastatur, 2.2.2 Pausieren, Stoppen, Ausblenden, 2.4.3 Fokus-Reihenfolge, 2.5.3 Beschriftung im Namen, 4.1.2 Name, Rolle, Wert, 4.1.3 Statusmeldungen.

So sieht die Warenkorb-Meldung aus, wenn sie funktioniert. Der Container steht von Anfang an im Code, das Skript schreibt später nur den Text hinein:

Ganzer Satz statt nur Zahl: Das Understanding-Dokument zu 4.1.3 nennt genau dieses Beispiel, einen Warenkorb, der von „0 items“ auf „3 items“ springt; wird nur die Zahl als Änderung ausgegeben, hört der Nutzer womöglich nur „drei“ (W3C Understanding 4.1.3).

Und ein Grundfehler im Vergleich:

WCAG-2.2-Zuordnung

ARIA ist kein eigenes Kriterium in WCAG 2.2 (aktuelle Fassung vom 12. Dezember 2024). Ob ARIA richtig sitzt, zeigt sich vor allem an drei Kriterien:

4.1.2 Name, Rolle, Wert (Stufe A): Jedes Bedienelement hat einen Namen, eine Rolle und, wo nötig, einen Zustand, den Hilfstechnik auslesen kann. Laut Understanding-Dokument sind zusätzliche Maßnahmen nötig, sobald eigene Bedienelemente gebaut werden. Hier landen fast alle Zeilen der Tabelle.
1.3.1 Info und Beziehungen (Stufe A): Was optisch zusammengehört, muss auch im Code zusammengehören, etwa die Überschrift „Farbe“ und die Farbfelder darunter. Zu den Techniken gehören dort unter anderem ARIA-Landmarks und aria-labelledby.
4.1.3 Statusmeldungen (Stufe AA): Statusmeldungen müssen im Code so ausgezeichnet sein, dass Hilfstechnik sie ansagen kann, ohne dass der Fokus dorthin springt. Das Understanding-Dokument nennt dafür unter anderem die Technik role="status".

Das frühere Kriterium 4.1.1 Parsing ist in WCAG 2.2 als obsolet und entfernt markiert (W3C). Nach unserer Lesart bleibt ein kaputter Verweis wie ein aria-labelledby auf eine nicht vorhandene ID trotzdem ein Problem: Er zeigt sich als fehlender Name und damit unter 4.1.2.

Selbst prüfen: Schritt für Schritt

Sie brauchen dafür keine Programmierkenntnisse, nur Chrome oder Firefox und etwas Zeit; unsere Schätzung: etwa eine Stunde. Prüfen Sie Startseite, eine Produktseite mit Varianten, eine Kategorieseite mit Filtern und den Warenkorb.

Schritt 1: Den Accessibility-Baum in Chrome ansehen

Der Accessibility-Baum ist das, was der Browser an Screenreader weitergibt. Laut Chrome-Dokumentation ist er eine Teilmenge des DOM-Baums.

Öffnen Sie die Entwicklertools, gehen Sie ins Panel Elements und wählen Sie im Code den Baustein aus, etwa den Farbfeld-Bereich.
Wählen Sie den Reiter Accessibility. Er kann laut Doku hinter dem Symbol More Tabs versteckt sein.
Unter Computed Properties sehen Sie die Eigenschaften, die der Browser berechnet, darunter Name und Rolle des Elements. Mit dem Schalter Show accessibility tree sehen Sie statt des Codes den ganzen Accessibility-Baum der Seite.

Worauf Sie achten:

Hat jedes Bedienelement einen sinnvollen Namen? „Dunkelblau“ statt leer, „Menge erhöhen“ statt „+“.
Passt die Rolle? Ein Button soll „button“ heißen, nicht „generic“.
Wechselt der Zustand? Klappen Sie einen Filter auf und wählen Sie das Element erneut aus: aria-expanded muss jetzt true zeigen.

Schritt 2: Gegenprobe in Firefox

Öffnen Sie laut Firefox-Dokumentation den Accessibility Inspector über Tools > Browser Tools > Accessibility oder per Rechtsklick auf der Seite mit Inspect Accessibility Properties. In deutschen Firefox-Versionen können die Menünamen übersetzt sein.
Wählen Sie im Aufklappmenü Check for issues den Eintrag Text Labels: Firefox listet Elemente ohne Namen.
Mit dem Kästchen Show Tabbing Order sehen Sie die Reihenfolge, in der die Tab-Taste durch die Seite springt. Versteckte Karussell-Folien oder ein geschlossener Mini-Warenkorb dürfen darin nicht auftauchen.

Schritt 3: Automatisch nach ARIA-Fehlern suchen

Die Prüfbibliothek axe-core hat eine Gruppe von Regeln, die mit aria- beginnen (Regelliste von Deque). Wie Sie die Browser-Erweiterung bedienen, erklärt unser Artikel axe DevTools Schritt für Schritt. Für ARIA sind diese Meldungen die wichtigsten:

aria-hidden-focus: Ein versteckter Bereich enthält etwas, das man mit Tab erreicht (Regel 4 oben).
aria-valid-attr-value und aria-valid-attr: Ein ARIA-Attribut gibt es nicht, oder sein Wert ist ungültig.
aria-required-attr: Einem Element mit ARIA-Rolle fehlt ein Attribut, das diese Rolle verlangt.
aria-required-children und aria-required-parent: Eine Rolle steht ohne die Rollen, die zu ihr gehören, etwa eine Reiterleiste ohne Reiter oder ein Reiter außerhalb einer Reiterleiste.
aria-allowed-attr, aria-prohibited-attr und aria-allowed-role: Attribut oder Rolle passt nicht zum Element.
aria-command-name, aria-toggle-field-name, aria-dialog-name: Button, Schalter oder Dialog ohne Namen.

Unsere Einschätzung: Ein automatischer Test erkennt, ob ARIA formal stimmt. Ob aria-expanded beim Klicken wirklich wechselt oder die Pfeiltasten im Tab-Element funktionieren, sehen Sie nur in Schritt 1, 4 und 5.

Schritt 4: Tastatur

Legen Sie die Maus weg. Erreichen Sie Mengen-Stepper, Farbfelder, Filter, Tabs und Karussell mit Tab? Lösen Enter und Leertaste aus? Schließt Escape den Mini-Warenkorb, und springt der Fokus beim Öffnen hinein? Bei selbst gebauten Tabs müssen laut APG die Pfeiltasten den Reiter wechseln. Die vollständige Anleitung steht im Tastaturtest in 10 Minuten.

Schritt 5: Kurztest mit Screenreader

Schalten Sie NVDA (Windows) oder VoiceOver (Mac) ein und gehen Sie die vier Seiten mit der Tab-Taste durch. Hören Sie bei jedem Baustein der Tabelle hin: Wird ein Name angesagt? Eine Rolle wie „Schalter“, „Auswahlschalter“ oder „Tab“? Ein Zustand wie „ausgeklappt“ oder „ausgewählt“? (So lauten die Wörter im deutschen NVDA laut dessen Übersetzungsdatei; VoiceOver verwendet teils andere Wörter.) Legen Sie ein Produkt in den Warenkorb: Hören Sie eine Bestätigung, ohne dass Sie den Fokus bewegen? Wie Sie die Screenreader starten und bedienen, erklärt unser Screenreader-Test mit NVDA und VoiceOver.

Schritt 6: Festhalten

Notieren Sie je Fund Seite, Baustein, was angesagt wurde und was Sie erwartet hätten, plus die Zeile aus der Tabelle oben. Mit dieser Liste kann Ihre Agentur gezielt nachbessern.

Fragen an Theme-Anbieter oder Agentur

Welche Bausteine sind selbst gebaut statt nativ? Bitte nennen: Mini-Warenkorb, Mengen-Stepper, Variantenauswahl, Akkordeon, Tabs, Karussell, Filter.
Nach welchem APG-Muster ist jeder selbst gebaute Baustein umgesetzt? Gibt es für jeden eine dokumentierte Tastaturbedienung?
Warum hier ARIA statt eines HTML-Elements? Etwa: Warum kein <dialog>, kein <details>, keine echten Radio-Buttons?
Wie wird „In den Warenkorb gelegt“ angesagt? Steht der Statuscontainer schon beim Laden im Code?
Mit welchen Screenreadern und Browsern wurde getestet, und gibt es dazu ein Protokoll?
Nutzt die Hauptnavigation role="menu"? Wenn ja: Warum, und ist die Pfeiltasten-Bedienung umgesetzt?
Bleiben die Korrekturen bei Theme-Updates erhalten?

Checkliste ARIA im Shop

Buttons, Links, Formularfelder sind echte HTML-Elemente, keine div mit role.
Mini-Warenkorb ist ein Dialog mit Namen; Fokus springt hinein, Escape schließt.
Mengen-Stepper: Feld hat eine Beschriftung, Plus und Minus haben Namen.
Farb- und Größenauswahl: Gruppe hat einen Namen („Farbe“), jedes Feld einen Text („Dunkelblau“), die Auswahl wird angesagt.
Akkordeon und Filter: aria-expanded sitzt am Button und wechselt beim Klicken.
Tabs: Pfeiltasten funktionieren, aktiver Reiter hat aria-selected="true", oder es gibt gar keine Tabs.
Karussell: Weiter und Zurück vorhanden, bei automatischem Wechsel auch Start/Stopp; kein Dauervorlesen, versteckte Folien nicht mit Tab erreichbar.
„In den Warenkorb gelegt“ wird angesagt, als ganzer Satz.
Hauptnavigation ohne role="menu", außer die Menübedienung ist vollständig umgesetzt.
Kein aria-hidden="true" auf oder um etwas, das man mit Tab erreicht.
aria-label enthält den sichtbaren Text des Elements.
axe meldet keine Regel, die mit aria- beginnt.
Ergebnis je Baustein notiert und an Agentur oder Theme-Anbieter gegeben.

Mehr zu aufklappbaren Filtern lesen Sie im Artikel Produktfilter barrierefrei.

Ihr nächster Schritt

Machen Sie zusätzlich den kostenlosen Scan. Er prüft Startseite, Produktseite und Warenkorb und zeigt, was zuerst behoben werden sollte. Wie axe findet er als automatische Prüfung nur einen Teil der Barrieren; ob ARIA-Zustände beim Bedienen wirklich wechseln, prüfen Sie selbst mit Accessibility-Baum, Tastatur und Screenreader.

Stand: 28.10.2026. Quellen gelesen am 28.10.2026.