Warenkorb

Sogenannte Warenkörbe stellen eines der Herzstücke eines E-Commerce-Projektes dar. Es ist ein digitale Ort, den Kundinnen und Kunden mit interessanten Waren oder Dienstleistungen befüllen können, bevor sie zur Zahlung und damit auch juristisch zum Abschluss eines Verbrauchervertrags schreiten. Entsprechend wichtig ist es, den Warenkorb zugänglich für alle zu gestalten.

Wenn man sich Warenkorb-Implementationen in typischen Webshops anschaut, so fällt einem eine gewisse Konvention auf. Nicht ungewöhnlich ist folgender Aufbau und folgende Gestaltung:

Von diesem nicht ungewöhnlichen Muster ausgehend, schauen wir uns in diesem Modul einmal an, wie die einzelnen Bestandteile zugänglich, standardkonform und – unter anderem – kompatibel mit Hilfstechnologien wie Screenreadern umzusetzen sind:

Das typische Muster hat die zwei genannten Bestandteile:

In der Beispielimplementation auf ecbf.shop ist das Warenkorb-Konstrukt folgendermaßen umgesetzt:

Da ein auf einen Klick auf „Warenkorb“ (oder ähnlich) eine Interaktion folgt, muss das verwendete Element eine interaktive semantische Rolle haben. Wenn ein Dialog (siehe nächste Sektion) geöffnet wird, ist das ein Element mit der Rolle button, was am einfachsten per HTML-<button>-Element umgesetzt werden kann. Führt ein Klick auf das Kontrollfeld jedoch auf eine eigene Seite oder einen eigenen, per URL erreichbaren (sogenannten) View einer Single Page Application (siehe übernächste Zwischenüberschrift), so sollte es sich um einen Link handeln. Die Rolle link mit all ihren nötigen Eigenschaften ist am besten per <a>-Element (inklusive href-Attribut!) zu realisieren.

Wenn sich der Warenkorb, z.B. von der rechten Seite über das Interface schiebt und es dabei abdunkelt und deaktiviert, aber die „auslösende Seite“ bestehen lässt, kann man davon ausgehen, dass der Warenkorb hier als sogenannter „modaler Dialog“ implementiert werden sollte. „Dialog“, weil es ein „Unterfenster“ ist, das sich nachvollziehbar über eine Oberfläche (hier: den Rest der Shop-Benutzeroberfläche) legt und diese teilweise verdeckt. „Modal“, weil es dabei den sprichwörtlichen wie wörtlichen Fokus auf sich zieht und vor allem alle Teile des Interfaces blockiert, die nicht Dialog oder Dialoginhalt sind (es „ändert den Modus“, wird deswegen „modal“ genannt). Weitere Pflicht-Eigenschaften eines modalen Dialogs sind:

Die gute Nachricht ist: man muss Dialoge dieser Art und die genannten Funktionen nicht mehr zwingend manuell unter Verwendung von ARIA implementieren, sich z. B. selbst um Rollen, Zustände und Fokusmanagement kümmern (man kann es dennoch, wenn mal will). Stattdessen ist seit relativ kurzer Zeit das <dialog>-Element im HTML-Werkzeugkoffer zu finden und genießt ausreichende Unterstützung. Dieses übernimmt das Fokusmanagement, das Deaktivieren des „Hintergrundes“ und implementiert die erforderlichen Rollen und Zustandsbeschreibungen. Wichtig: um einen Dialog modal zu starten, muss man ihn per JavaScript-Methode .showModal() starten, eine Initiierung mit anderen Mitteln oder auch nur per .show()-Funktionsaufruf führt nur zu einem nichtmodalen Dialog. Wenn ein offener Warenkorb den Rest der Benutzeroberfläche optisch wie programmatisch „in den Hintergrund rücken“ soll, wäre ein nichtmodaler Dialog nicht das Nutzungsmuster der Wahl (sondern ein modaler Dialog, siehe entsprechendes Modul).

Unabhängig davon, mit welchen Mitteln der Dialog gebaut wurde, ist es angemessen, ihm einen programmatischen Namen zu geben. Wenn eine Website mehrere mögliche Dialoge hat (z. B. einen weiteren für Cookiehinweise), kann man vor allem nicht-visuell diese am ehesten auseinanderhalten, wenn sie Namen wie „Warenkorb“ oder „Cookiebanner“ tragen. Um einen Dialog also zu benennen, muss leider doch wieder auf ein ARIA-Attribut zurückgreifen: Das ist entweder aria-label, also z. B. aria-label="Warenkorb". Oder aber eine z. B. wahrnehmbare Überschrift wird als „Namensgeber“ referenziert. Dazu nutzt man aria-labelledby und gibt als Attribut-Wert die ID des Textes an, der den Namen des Dialogs bereithält. Ein Beispiel:

Auch in diesem Szenario ist der Dialog nun mit dem Namen „Warenkorb“ ausgestattet.

In der ecbf.shop-Beispielimplementierung findet sich die Benennung in Zeile 12 des warenkorb-Partials.

Falls der Warenkorb kein Unterfenster eines anderen HTML-Dokumentes ist, sondern eher eine eigene Unterseite , gelten hier die Basis-Regeln der Barrierefreiheit (z. B. was eine nachvollziehbare Überschriftenstruktur und ein sinnvoller Dokumententitel wie „Warenkorb“ angeht).

Löst man den Warenkorb als „gefühlt“ eigene Seite, ist es aber in Wirklichkeit kein „klassisches“ Dokument sondern ein so genannter „View“ (in etwa: Web-App-Zustand) in einer Single Page Application (SPA) ist, sollte man auch hier…

Unabhängig von den Seiten oder Unterseitenkonzept stellt sich nun die Frage, wie man die Inhalte im Warenkorb am Sinnvollsten strukturiert. Haben Produkte Eigenschaften wie Bestellnummern, Namen und Einzelpreise und Verpackungs-Optionen, so ergibt es Sinn, diese in tabellarischer Form zu strukturieren. Jede Tabellenzeile wäre dann eine Ware oder Dienstleistung (mit Stückzahlen, wo es Sinn ergibt), und die Tabelle insgesamt der Warenkorb. Unterhalb der Tabelle steht dann der in Echtzeit berechnete Gesamtpreis:

Auch hierzu bietet ecbf.shop eine Beispielimplementation an, unter dieser URL startet der Shop mit einem vorausgefüllten und offenem Warenkorb.

Was bestimmte Werte angeht, sei es Stückzahl oder Preis, so werden beide in Echtzeit berechnet und aktualisiert angezeigt. Wenn man davon ausgeht, dass man in bestimmten Tabellenzeilen die Produktstückzahlen ändern kann (z. B. per input[type="number"]), so sind keine gesonderten Hinweise für Screenreader und ihre Nutzer*innen nötig (die sonst Echtzeit-Updates dieser Art nicht unmittelbar mitbekommen). Bestimmte Ereignisse, wie das grundsätzliche Hinzufügen zu oder Entfernen aus dem Warenkorb sollten dennoch jeweils mit einer sogenannten asynchronen Anmerkung an den Screenreader vonstattengehen. Mehr dazu im nächsten Abschnitt.

Für Screenreader sind Echtzeit-Updates (also Aktualisierungen eines Dokuments, ohne das ein Neuladen stattfindet) tendenziell problematisch. Es besteht die Gefahr, dass die Nutzenden dieser Bildschirmvorleser wichtige Updates auf der Seite nicht oder nur nach manuellem Suchen bemerken.

Aus diesem Grund bietet der ARIA-Werkzeugkasten die so genannten „Live-Regions“, die gerade im Zusammenspiel mit einem Warenkorb als modaler Dialog Sinn ergeben. Wo ein Screenreader sonst im HTML-Dokument (oder dem „live“ erzeugten HTML) Element pro Element voranschreitet und immer nur genau das, was vor seinem „virtuellen Cursor“ liegt, vorließt – so bieten Live-Regions die Möglichkeit Statusmeldungen abzugeben, die nichts mit der aktuellen Position des virtuellen Cursors zu tun haben. Per HTML gibt es einige Wege, eine Live-Region-Ausgabe zu erzeugen:

Patrick H. Laucke hat kürzlich einen tiefergehenden Artikel zu Live-Regions, ihren theoretischen und auch praktischen Einsatz geschrieben (hier das englischprachige Original).

Im Rahmen folgender Ereignisse ergibt eine Live-Region-Ausgabe Sinn:

Wenn ein Produkt oder mehrere Produkte zum Warenkorb hinzugefügt werden, ist folgender Ablauf zu empfehlen:

Hier gehen wir von einer Implementierung aus, bei der ein <input type="number"> die genaue Eingabe der Stückzahl eines Produktes ermöglicht.

Da es sich hier um eine Wertänderung in einem Eingabefeld handelt ist keine Live-Region-Ausgabe nötig. Wohl aber eine Neuberechnung des Gesamtpreises, über den Screenreadernutzende wiederum per Live-Region informiert werden sollten: „Neuer Gesamtpreis des Warenkorbs: € 40.46“.

Ähnliches gilt auch für Produktoptionen wie Geschenkverpackungen – hat deren Buchung einen Echtzeit-Einfluss auf die Preise ist dies ein Job für Informationen per Live-Region-Ausgabe.

Für das Entfernen eines Produkts oder einer Produktart wird ein Live-Region-Aufruf wie „Artikel 'Hippe Jeans' entfernt“ empfohlen (oder die Ausgabe einer Fehlermeldung, sollte es aus irgendwelchen Gründen nicht möglich sein). Hier bietet sich ebenfalls eine Information an, welcher neue Gesamt-Warenkorb-Preis in der Folge entsteht. Ob sich der Warenkorb-Dialog in diesem Szenario ebenfalls schließt, sollte davon abhängen, ob die just entfernte Ware der letzte Eintrag der letzte verbleibende im Shopping Cart war – und dieser nun leer ist.

Wenn wir eine Zeile einer Datentabelle dynamisch entfernen, entsteht aber ein Problem: Wohin mit dem Fokus? Mit dem Löschen der Zeile entfernen wir auch alle Fokushaltepunkte in ihm, und auf einem dieser (der „Enfernen“-Schaltfläche) lag der Tastaturfokus bisher, wenn wir von einer Nutzung per Tastatur ausgehen. Löschen wir also letztendlich das aktuell aktive HTML-Element und werfen den Fokus versehentlich auf den body des Elements zurück?

Um das zu vermeiden, wird die Datentabelle des Warenkorbs fokussiert. Dies geschieht nur ausnahmsweise, weil ein Fokussieren von nicht-interaktiven Elementen normalerweise vermieden werden sollte. Man kann ein Element programmatisch, aber nicht manuell fokussierbar machen, in dem man das Attribut tabindex="-1" auf ihm verwendet. Somit ist die Tabelle durch ein Skript fokussierbar, aber nicht durch einen menschlichen Nutzenden versehentlich erreichbar.

Zu guter Letzt erinnern wir uns an die Grundregel, dass fokussierbare Elemente auch einen zugänglichen Namen benötigen. Weil wir eine Tabelle fokussieren wollen, sollten wir uns damit auseinandersetzen, wie wir diesen Elementen einen zugänglichen Namen geben können. Um es abzukürzen: Dazu gibt es das <caption>-Element. Dieses verbergen wir visuell, um eine Doppelung mit den Informationen im Tabellenfuß zu vermeiden, und befüllen es dynamisch mit dem jeweiligen Gesamtpreis:

Etwas ausführlicher wird dieser Ansatz im Modul zur Tastaturbedienung erklärt.

Eine zugängliche Beispielimplementierung eines Warenkorbs als Dialog inklusive aller sinnigen Live-Region-Ausgaben, nötigem Fokusmanagement und dynamischer Tabelleninformationen findet sich auf ecbf.shop.

Wer sich in das Thema Live-Regionen über oben stehenden Link hinaus weiter vertiefen will, dem sei dieser Artikel ans Herz gelegt.