Die Zahlungsabwicklung ist für viele Webshops der empfindlichste Teil der Website in Bezug auf Barrierefreiheit. Während die Produktseiten oft noch einigermaßen mit einer Bildschirmleseanwendung funktionieren, bleibt der Prozess stecken, sobald ein Kunde bezahlen muss: Schaltflächen ohne klares Label, Fehlermeldungen, die nicht angesagt werden, oder ein Zahlungs-Widget eines externen Anbieters, das sich ohne Maus nicht bedienen lässt. Das ist kein Zufall. Die Zahlungsabwicklung enthält die meisten dynamischen Elemente der gesamten Website, und dynamische Elemente sind genau dort, wo Bildschirmleseanwendungen und Tastaturnavigation am schnellsten steckenbleiben.
Es geht hier nicht um ein kleines Detail. Die Zahlungsabwicklung fällt unter die gleichen EN 301 549-Anforderungen wie der Rest der Website, und diesen Schritt durchläuft ein Nutzer per Definition in dem Moment, in dem er tatsächlich etwas kaufen möchte. Eine Bildschirmleseanwendung, die dort steckenbleibt, schließt einen Kunden im entscheidenden Moment aus. Das ist auch der Grund, warum wir bei axessia die Zahlungsabwicklung standardmäßig in die vollständige Prüfung einbeziehen und nicht nur in die kostenlose Schnellprüfung der Kernseiten.
Wo es in der Praxis schief läuft
Die häufigsten Probleme sind bemerkenswert wiederkehrend. Eine Schaltfläche für "nächster Schritt" oder "jetzt bezahlen", die nur ein Symbol enthält, ohne Text, den eine Bildschirmleseanwendung vorlesen kann. Eine Fehlermeldung bei einem falsch ausgefüllten Postleitzahlfeld, die zwar auf dem Bildschirm erscheint, aber nicht angesagt wird, weil die richtige technische Verknüpfung fehlt. Ein Fortschrittsanzeiger ("Schritt 2 von 3"), der visuell klar ist, aber für eine Bildschirmleseanwendung unsichtbar bleibt. Und der Zahlungsanbieter selbst: iDEAL- oder Kreditkarten-Widgets von Drittanbietern sind oft lose eingebaut und haben ihr eigenes Barrierefreiheitsniveau, auf das ein Webshop selbst wenig Einfluss hat, aber dennoch verantwortlich ist.
Auch die Fokusreihenfolge ist ein wiederkehrendes Problem. Nach dem Absenden eines Formulars mit einem Fehler sollte die Aufmerksamkeit des Nutzers zur Fehlermeldung gehen. Wenn dies nicht geschieht, bleibt jemand, der mit der Tastatur oder einer Bildschirmleseanwendung arbeitet, im Dunkeln darüber, was schiefgelaufen ist.
Warum eine automatisierte Prüfung dies teilweise übersieht
Eine automatisierte Prüfung ist gut darin, fehlende Labels, leere Schaltflächen und strukturelle Probleme im Quellcode zu erkennen. Was eine Prüfung nicht gut beurteilen kann, ist das Verhalten: Wird eine Fehlermeldung tatsächlich laut vorgelesen, springt der Fokus logisch, und ist die Zahlungsabwicklung nach der Eingabe von Daten immer noch ohne Maus erreichbar. Das erfordert jemanden, der den Schritt tatsächlich mit einer Bildschirmleseanwendung durchläuft. Dies ist genau die Art von Einschränkung, die in jedem Bericht von axessia ausdrücklich genannt wird: Eine Prüfung testet einen Teil der Anforderungen, nicht alles.
Deshalb konzentriert sich die vollständige Prüfung nicht nur auf die Startseite, sondern gerade auch auf die Schritte, die ein Kunde tatsächlich durchläuft, einschließlich Anmeldung und Zahlungsabwicklung. Wenn Sie zuerst eine unverbindliche Einschätzung möchten, können Sie in einigen wenigen Fragen sehen, wo Ihre Website derzeit steht.
Was dies für die Anforderungen bedeutet, denen Sie nachkommen müssen
Die zugrunde liegende Norm EN 301 549 übersetzt sich in der Praxis in WCAG 2.1 Level AA. Darin gibt es Anforderungen zu Name, Funktion und Status interaktiver Elemente, zu Statusmitteilungen, die ohne visuelle Aufmerksamkeit dennoch verständlich sein müssen, und zu Informationen, die nicht nur durch Farbe oder Position vermittelt werden. Für die genaue Formulierung und den Fundort im offiziellen Text ist EUR-Lex die richtige Quelle; wir übersetzen diese Anforderungen in erkennbare Situationen wie die Zahlungsabwicklung, geben aber keine Aussage über Ihre spezifische Situation ab. Weitere Informationen darüber, wie diese Umsetzung zustande kommt, finden Sie auf der Seite, die erklärt, woher unsere Informationen stammen.
Wie Sie dies selbst testen oder testen lassen
Ein erster, praktischer Schritt besteht darin, den Checkout-Prozess selbst durchzulaufen – ohne Maus, nur mit der Tabulatortaste und der Eingabetaste. Wenn Sie an irgendeinem Punkt nicht weiterkommen, ist die Wahrscheinlichkeit groß, dass ein Screenreader dort ebenfalls steckenbleibt. Ein zweiter Schritt ist das Testen mit einem kostenlosen Screenreader wie NVDA, wobei Sie besonders darauf achten sollten, was vorgelesen wird, sobald ein Fehler auftritt. Um ein vollständiges Bild zu erhalten – einschließlich der Punkte, die nur durch manuelle Durchläufe erkannt werden – ist eine umfassendere Prüfung erforderlich; axessia führt diese Prüfung durch und dokumentiert die Ergebnisse in einer priorisierten Maßnahmenliste, führt aber selbst keine Reparaturarbeiten durch. Diese bleiben Ihrem eigenen Entwickler oder Anbieter überlassen, oft basierend auf genau den Punkten, die wir benennen. Weitere häufig gestellte Fragen zu solchen konkreten Hürden finden Sie gesammelt in der Wissensdatenbank mit ausgearbeiteten Themen pro Situation.
Wenn Sie wissen möchten, was eine vollständige Prüfung Ihres Checkout-Prozesses und Ihrer Login-Umgebung kostet, finden Sie das übersichtlich auf der Seite mit Preisen und deren Inhalten.
Möchten Sie zunächst ohne Verpflichtungen einen Eindruck gewinnen? Der kostenlose Quick-Check von axessia gibt Ihnen innerhalb weniger Minuten einen ersten Eindruck Ihrer Kernseiten, und die Scope-Prüfung zeigt, ob die Regelgeving für Ihre Organisation gilt.