Warum Verständlichkeit im Checkout genauso zur Barrierefreiheit gehört wie Kontrast und Tastaturbedienung
Ein Kontrastverhältnis von 4,5 zu 1 und eine vollständig tastaturbedienbare Formularstrecke nützen wenig, wenn die Fehlermeldung im Checkout in einem verschachtelten Schachtelsatz erklärt, dass ein Feld ein ungültiges Format aufweist. Dieser Artikel zeigt, was WCAG 3.1.5 zur Lesbarkeit konkret verlangt, wie sich Leichte Sprache von Einfacher Sprache unterscheidet und wie klare Fehlermeldungen und Anleitungen im Checkout ohne Fachjargon auskommen.
Inhaltsverzeichnis
- 1. Was kognitive Barrierefreiheit umfasst und warum sie oft übersehen wird
- 2. WCAG 3.1.5: Lesbarkeit als Erfolgskriterium der Stufe AAA
- 3. Leichte Sprache vs. Einfache Sprache: der Unterschied
- 4. Klare Fehlermeldungen im Checkout: Beispiele und Anti-Patterns
- 5. Anleitungen und Schritt-für-Schritt-Texte im Checkout
- 6. Fachjargon vermeiden: das Glossar-Pattern für unvermeidbare Fachbegriffe
- 7. Lesbarkeits-Metriken: Flesch-Reading-Ease und Co.
- 8. Redaktionsprozess: wie ein Team Leichte-Sprache-Reviews einführt
- 9. Praxisbeispiel: Checkout-Fehlermeldungen in Hyvä überarbeiten
- 10. Zusammenfassung
- 11. FAQ
1. Was kognitive Barrierefreiheit umfasst und warum sie oft übersehen wird
Kognitive Barrierefreiheit richtet sich an Menschen mit Lernschwierigkeiten, Aufmerksamkeitsstörungen, Legasthenie, Demenz oder schlicht an Menschen, die unter Zeitdruck, Stress oder in einer fremden Sprache einkaufen. Anders als bei visuellen oder motorischen Einschränkungen lässt sich kognitive Barrierefreiheit kaum mit einem einzelnen technischen Attribut lösen, sie entsteht vielmehr durch die Summe aus klarer Sprache, vorhersagbarer Navigation und nachvollziehbaren Fehlermeldungen.
Gerade weil sich kognitive Barrieren nicht mit einem automatisierten Accessibility-Scanner erkennen lassen, wie es bei fehlendem Alternativtext oder zu niedrigem Kontrast der Fall ist, bleiben sie in vielen Barrierefreiheitsprojekten unbeachtet. Ein Shop kann formal alle automatisiert prüfbaren WCAG-Kriterien erfüllen und trotzdem für einen erheblichen Teil der Nutzerinnen und Nutzer im Checkout faktisch unbenutzbar bleiben, weil die Texte selbst zu komplex sind.
2. WCAG 3.1.5: Lesbarkeit als Erfolgskriterium der Stufe AAA
Das Erfolgskriterium 3.1.5 der WCAG mit dem Namen Lesbarkeit verlangt, dass für Texte, die ein höheres Bildungsniveau als die Sekundarstufe voraussetzen, eine ergänzende, leichter verständliche Version bereitgestellt wird, etwa in Form einer Zusammenfassung, von Illustrationen oder einer gesprochenen Fassung. Das Kriterium gehört zur Stufe AAA und wird deshalb selten als verpflichtend eingestuft, dennoch liefert es eine nützliche Richtschnur für alle Texte, die direkt im Kaufprozess stehen.
Für einen Magento-Shop bedeutet das praktisch, dass komplexe rechtliche Texte wie die Widerrufsbelehrung oder die AGB weiterhin vollständig vorliegen dürfen, die tatsächlich im Checkout sichtbaren Texte, also Formularlabels, Fehlermeldungen und Bestätigungshinweise, aber unabhängig vom AAA-Anspruch grundsätzlich so einfach wie möglich gehalten werden sollten, weil genau diese Texte über den erfolgreichen Abschluss der Bestellung entscheiden.
3. Leichte Sprache vs. Einfache Sprache: der Unterschied
Leichte Sprache ist ein strikt geregeltes Regelwerk mit kurzen Sätzen von maximal etwa acht bis zwölf Wörtern, einem Verb pro Satz, dem konsequenten Verzicht auf Nebensätze, Konjunktiv und Passivkonstruktionen sowie einer verpflichtenden Erklärung jedes Fachworts. Sie richtet sich vor allem an Menschen mit kognitiven Beeinträchtigungen oder geringer Lesekompetenz und wird typischerweise von zertifizierten Prüfgruppen gegengelesen, bevor ein Text als Leichte Sprache gilt.
Einfache Sprache dagegen ist kein formal geregeltes Regelwerk, sondern ein allgemeiner Sprachstil mit kürzeren Sätzen, aktiven statt passiven Formulierungen und alltagsnahem Wortschatz, der aber grammatikalisch komplexer bleiben darf als Leichte Sprache. Für einen Magento-Checkout ist Einfache Sprache in aller Regel die passendere Wahl, weil sie sich natürlicher in ein bestehendes Markendesign einfügt, während vollständige Leichte Sprache eher für separate, explizit ausgewiesene Zielgruppenseiten sinnvoll ist.
4. Klare Fehlermeldungen im Checkout: Beispiele und Anti-Patterns
Eine typische, schlecht verständliche Fehlermeldung lautet sinngemäß, dass das eingegebene Format ungültig ist, ohne zu erklären, welches Format konkret erwartet wird oder an welcher Stelle genau der Fehler liegt. Für Nutzerinnen und Nutzer mit kognitiven Einschränkungen bedeutet eine solche Meldung, dass sie raten müssen, was falsch war, was einen Checkout-Abbruch deutlich wahrscheinlicher macht als eine präzise, handlungsorientierte Formulierung.
Eine gute Fehlermeldung benennt das betroffene Feld konkret beim Namen, beschreibt den erwarteten Wert in einfacher Sprache und schlägt idealerweise direkt eine Korrektur vor, etwa dass die Postleitzahl genau fünf Ziffern ohne Leerzeichen enthalten muss. Zusätzlich sollte die Meldung räumlich direkt beim betroffenen Feld erscheinen und nicht nur am oberen Seitenrand gesammelt, damit der Zusammenhang zwischen Fehler und Ursache jederzeit nachvollziehbar bleibt.
<!-- Schlecht: technisch, ohne Handlungsanweisung -->
<span class="error">Ungültiges Format</span>
<!-- Gut: konkret, mit Korrekturvorschlag, am Feld verankert -->
<div class="mt-1 text-sm text-red-700" id="plz-error" role="alert">
Bitte gib eine gültige Postleitzahl mit genau 5 Ziffern ein,
zum Beispiel 10115.
</div>
<input type="text" id="plz" aria-describedby="plz-error" aria-invalid="true">
5. Anleitungen und Schritt-für-Schritt-Texte im Checkout
Neben Fehlermeldungen prägen auch unterstützende Anleitungstexte den kognitiven Aufwand eines Checkouts erheblich, etwa Hinweise zur Zahlungsart, zur Adresseingabe bei abweichender Lieferadresse oder zur Gutscheinanwendung. Solche Texte sollten in der Reihenfolge stehen, in der die Handlung tatsächlich ausgeführt wird, statt Bedingungen und Ausnahmen vor der eigentlichen Handlung aufzuzählen, weil eine vorangestellte Bedingung den Lesefluss unterbricht und den Text unnötig verkompliziert.
Ein bewährtes Muster ist die konsequente Verwendung von Verben am Satzanfang bei Handlungsaufforderungen, etwa Gutscheincode eingeben statt der Gutscheincode kann hier eingegeben werden, weil aktive, imperativische Formulierungen kognitiv schneller verarbeitet werden als passive Konstruktionen. Ebenso hilft eine sichtbare Schrittanzeige, etwa Schritt 2 von 4, Versand, weil sie Nutzerinnen und Nutzern jederzeit eine klare Orientierung gibt, wie viel des Checkouts noch verbleibt.
6. Fachjargon vermeiden: das Glossar-Pattern für unvermeidbare Fachbegriffe
Manche Fachbegriffe lassen sich im E-Commerce-Kontext nicht vollständig vermeiden, etwa Rechnungsadresse, Vorkasse oder Zwischensumme, weil sie in der Buchhaltung und im Zahlungsverkehr feste, notwendige Bezeichnungen sind. Statt solche Begriffe komplett zu ersetzen, was oft zu ungenauen oder missverständlichen Alternativen führt, hilft eine konsequente, unaufdringliche Erklärung direkt an der Stelle, an der der Begriff zum ersten Mal auftaucht.
Technisch lässt sich das über ein Element mit einem knappen Erklärtext oder über ein aria-describedby-Attribut umsetzen, das bei Bedarf per Tastatur oder Screenreader zugänglich zusätzliche Erklärung liefert, ohne den Haupttext optisch aufzublähen. Wichtig ist dabei, den Erklärtext selbst wieder in einfacher Sprache zu formulieren, da eine Erklärung, die selbst neue Fachbegriffe einführt, das eigentliche Verständnisproblem lediglich verschiebt statt zu lösen.
<p>
Der Gesamtbetrag wird per
<span class="underline decoration-dotted" tabindex="0" aria-describedby="vorkasse-erklaerung">
Vorkasse
</span>
bezahlt.
</p>
<div role="tooltip" id="vorkasse-erklaerung" class="text-sm text-gray-600">
Vorkasse bedeutet: Du bezahlst zuerst. Wir versenden die Ware,
sobald das Geld bei uns angekommen ist.
</div>
7. Lesbarkeits-Metriken: Flesch-Reading-Ease und Co.
Um Verständlichkeit nicht nur subjektiv einzuschätzen, helfen etablierte Lesbarkeits-Formeln wie der Flesch-Reading-Ease-Index, der aus durchschnittlicher Satzlänge und durchschnittlicher Silbenzahl pro Wort einen Wert zwischen null und hundert berechnet, wobei höhere Werte leichter verständlichen Text bedeuten. Für deutschsprachige Checkout-Texte gilt ein Wert von etwa sechzig bis siebzig als guter Zielbereich, während juristische Fließtexte häufig deutlich darunter liegen.
Solche Formeln ersetzen keine echte Nutzerprüfung mit tatsächlich Betroffenen, liefern aber ein schnelles, automatisierbares Signal, das sich sogar in einen Redaktions-Workflow oder eine CI-Prüfung für Übersetzungsdateien integrieren lässt, um auffällig komplexe Textstellen frühzeitig zu markieren, bevor sie überhaupt im Live-Shop erscheinen.
8. Redaktionsprozess: wie ein Team Leichte-Sprache-Reviews einführt
Damit Verständlichkeit nicht von der individuellen Tagesform einzelner Redakteurinnen und Redakteure abhängt, lohnt sich eine feste Checkliste im Redaktionsprozess, etwa maximale Satzlänge, aktiv statt passiv, ein Gedanke pro Satz und ein verbindliches Glossar für wiederkehrende Fachbegriffe. Diese Checkliste sollte fester Bestandteil des Review-Prozesses für neue Checkout-Texte sein, genauso wie ein Code-Review für neue Funktionen.
Für besonders kritische Texte wie Fehlermeldungen im Zahlungsprozess lohnt sich zusätzlich ein Test mit echten Nutzerinnen und Nutzern, die keinen fachlichen Hintergrund im E-Commerce haben, da interne Teams durch die tägliche Beschäftigung mit dem Shop blind für Formulierungen werden, die für Außenstehende tatsächlich unklar bleiben.
9. Praxisbeispiel: Checkout-Fehlermeldungen in Hyvä überarbeiten
In einem Hyvä-Theme werden Validierungsmeldungen häufig über Alpine.js-Komponenten gesteuert, die auf serverseitige Validierungsantworten oder clientseitige Prüfungen reagieren. Der entscheidende Hebel liegt dabei selten im JavaScript selbst, sondern in den Übersetzungsdateien, aus denen die eigentlichen Meldungstexte stammen, weshalb sich eine Überarbeitung auf Verständlichkeit zunächst als reine Textänderung ohne Codeänderung umsetzen lässt.
Erst wenn die Meldungen zusätzlich näher am jeweiligen Feld positioniert oder mit einer sofortigen Ankündigung versehen werden sollen, ist eine Anpassung der Alpine.js-Komponente selbst nötig, wie im folgenden Ausschnitt für ein Postleitzahl-Feld gezeigt, das Fehlertext, Feldreferenz über aria-describedby und eine sofortige Ankündigung per role alert kombiniert. Die folgende Tabelle ordnet die verschiedenen Sprachebenen den passenden Einsatzbereichen im Shop zu.
<div x-data="{ plzState: '' }">
<label for="plz" class="block text-sm font-medium">Postleitzahl</label>
<input
type="text"
id="plz"
x-on:blur="plzState = /^\d{5}$/.test($el.value) ? '' : 'invalid'"
:aria-invalid="plzState !== ''"
:aria-describedby="plzState !== '' ? 'plz-error' : null"
class="border rounded px-3 py-2"
>
<p
x-show="plzState !== ''"
id="plz-error"
role="alert"
class="mt-1 text-sm text-red-700"
>
Bitte gib eine gültige Postleitzahl mit genau 5 Ziffern ein.
</p>
</div>
| Ebene | Beispiel | Zielgruppe | Einsatz im Shop |
|---|---|---|---|
| Leichte Sprache | Kurze Sätze, ein Gedanke pro Satz, Fachwörter erklärt | Menschen mit kognitiven Beeinträchtigungen | Separate erklärende Zielgruppenseiten |
| Einfache Sprache | Kurze, aktive Sätze, alltagsnaher Wortschatz | Breites Publikum, auch unter Zeitdruck | Checkout-Texte, Fehlermeldungen, Anleitungen |
| Standardsprache | Vollständige Sätze, moderate Komplexität | Geübte Leserinnen und Leser | Marketingtexte, Blogartikel |
| Fachsprache | Juristische und technische Fachbegriffe | Fachpublikum, rechtlich notwendig | AGB, Widerrufsbelehrung, Datenschutzerklärung |
Mironsoft
WCAG-Audits, barrierefreie Magento-Shops und Schulungen
Unsicher, ob der Shop wirklich barrierefrei ist?
Wir prüfen bestehende Magento-Shops gegen WCAG 2.2, beheben konkrete Barrieren im Hyvä-Frontend und schulen Teams, damit Barrierefreiheit dauerhaft im Entwicklungsprozess verankert bleibt.
WCAG-Audit
Shop systematisch gegen WCAG 2.2 AA prüfen, mit priorisierter Fehlerliste.
Barrieren beheben
Konkrete Umsetzung: Tastaturbedienbarkeit, Screenreader-Support, Kontraste, Formulare.
Team-Schulung
Entwickler und Redakteure für barrierefreie Umsetzung im Alltag sensibilisieren.
10. Zusammenfassung
Kognitive Barrierefreiheit: Das Wichtigste auf einen Blick
Kernidee
Kognitive Barrierefreiheit entsteht durch klare Sprache, nicht durch ein einzelnes technisches Attribut.
WCAG 3.1.5
Verlangt eine leichter verständliche Zusatzversion für Texte über Sekundarstufen-Niveau, Stufe AAA.
Leichte vs. Einfache Sprache
Leichte Sprache ist streng geregelt, Einfache Sprache ist der praktikablere Stil für den Checkout.
Praxisregel
Fehlermeldungen benennen das Feld konkret und schlagen eine direkte Korrektur vor.