Produktvariationen
Formulare im Web haben ganz allgemein vor allem einen Zweck: Eingaben von Nutzenden entgegen nehmen, man könnte hochtrabender auch von „Kommunikation mit den Kund*innen in spe“ sprechen – und das gilt insbesondere im E-Commerce, das ganz wesentlich auf Dateneingaben fußt (und Informationen wie Zahlungs-, Rechnungs- und Versanddaten abfragt – wie bereits im Formular-Modul formuliert).
Eine weitere wesentliche Datenabfrage hat aber vor allem mit den zu erstehenden Produkten oder Dienstleistungen zu tun: Welche Variation oder Größe wünscht der Kunde oder die Kundin genau? Nehmen wir das konkrete Beispiel eines T-Shirts: allein dort lässt sich z. B. über die Größe, Textilbeschaffenheit und Farbe eine Vielzahl von möglichen Produktvariationen erzeugen – und welche Variante genau gewünscht wird, muss eindeutig an Kaufende und Verkaufende kommuniziert werden.
Welche Information möchte man vom Nutzenden?
Tritt man einen Schritt zurück, stellt der Verkäufer planerische Fragen, wie die folgende: Liegt eine Produktvariation vor, die ein komplett neues Produkt erfordert? Wenn ja: siehe unten. Wenn nein: Wie genau fragen wir Angaben zur Produktvariation „T-Shirt-Größe“ genau ab? Ist es für den oder die Interessierte eine Selektion, die als „Einfachauswahl“ gelten kann, soll der Kaufwillige alle verfügbaren Optionen sofort sehen können? Mit diesen Fragen und vor allem Antworten im Hinterkopf, schaut man sich nun an, welche Optionen der HTML-Werkzeugkasten für diese Abfragen bieten kann.
Die Antwort ist: Ein input-Element des Typs radio, denn diese Art von Eingabefeld nimmt genau eine Wahl entgegen, präsentiert aber alle verfügbaren Optionen:
Radio-Eingabefelder, die nicht wie solche aussehen
Häufig wirkt die Variations-Auswahl wie eine Reihe an Schaltflächen, so zum Beispiel in Shopfiys Dawn-Theme:
Wenn Radio-Eingabefelder benutzerdefiniertes Styling erfahren, dann meist, indem man das zugeordnete label-Element per CSS-Selektor adressiert, nach Wunsch gestaltet und dann das eigentliche Eingabefeld (<input type="radio">) verbirgt. Häufig geschieht das per display: none, mit dem man das Element allerdings „brutalstmöglichst“ aus dem Dokument entfernt: Es ist nun nicht nur unsichtbar, sondern auch nicht mehr per Tastatur erreichbar sowie vor allen Nutzungsformen versteckt. Eine empfehlenswerte Alternative ist, das Element nur visuell zu verstecken (zu „verbergen“), es dabei aber zugänglich für Screenreader-User zu belassen. Dies gilt insbesondere für Screenreader-Nutzende, die die Oberfläche per Touch erkunden. Aus diesem Grund soll das verborgene Element transparent und im Sinne des Z-Index' auf dem verborgenen Element liegen. Oder wie es Sara Soueidan in Ihrem Artikel „Inclusively Hiding & Styling Checkboxes and Radio Buttons“ (hier als automatische Übersetung ins Deutsche) zusammenfasst:
When you hide an interactive element, make sure you choose a hiding technique that keeps it screen reader-accessible, position it on top of whatever is visually replacing it so that a user navigating by touch can find it where they expect to, and then make it transparent.
Kontextwechsel und Inhaltswechsel
Wenn allerdings die oben stehende Analyse dazu geführt hat, dass wir es nicht mit den Einstellmöglichkeiten eines Produktes, sondern einem ganz eigenen Produkt zu tun haben, ist die Lage einfach: die neuen Produkte werden unter Einsatz des <a>-Elements schlicht verlinkt. Nutzende erwarten bei Aktivierung eines Links, dass ein neues Dokument geladen wird, oder abstrakter formuliert: Dass ein „Kontextwechsel“ stattfindet. Würde dieser schon bei einer Auswahl einer Radio-Option passieren, wäre dies ein Verstoß des WCAG-Erfolgskriteriums 3.3.2, Bei Eingabe. Der Hintergrund hierzu ist, dass User bei einer Bedienung eines Formularelementes nicht erwarten, dass wesentliche Änderungen an der Website erfolgen. Wenn sich Inhalte nach Bedienung eines Eingabefelds vom Typ Checkbox oder Radio im Sinne des Dokuments nur unterhalb der Felder verändern, und die Änderungen „unwesentlich“ sind, spricht man übrigens von einem so genannten Inhaltswechsel. Solche „Changes Of Contents“ bei Interaktion mit einem Formularelement sind wiederum erlaubt und die genaue Unterscheidung zwischen Kontext- und Inhaltswechsel ist immer eine Einzelfallentscheidung, die aber auf Grundlage der hier genannten Aspekte getroffen wird.
Umsetzung im Beispielshop
Auf der Produkteinzelseite im Beispielshop lässt sich die Inhalte dieses Moduls in Aktion sehen. Im exemplarischen Fall kann die Größe eines Shirts durch ein Radio-Element angegeben werden, während Produktvarianten (z. B. T-Shirt in Rot) als eigene Produkte verlinkt werden.
Übungen
Lückentext
Zusammenfassung
- Wie fast immer im HTML-Zusammenhang stehen abstrakte Fragen am Beginn des Baus einer Seite. Hier ist eine entscheidende Frage: welche Daten benötigen wir genau zur Ware, um den (zumeist Kauf-)Vertag auszuführen?
- Sobald diese geklärt sind, schließt sich eine Folgefrage an: Mit welchen Elementen aus dem HTML-Werkzeugkasten setzen wir die Oberfläche am besten um? Sie kennen Ihr Produkt und seine verfügbaren Variationen natürlich besser. Mit diesem Modul will ich Ihnen aber konkrete Fragen und konkrete, mögliche Lösungswege an die Hand geben – je nachdem, wie die Antworten genau ausfallen.