Wissen für Commerce-Agenturen
Technische Accessibility-Befunde für die Entwicklung gliedern
Ein automatisierter Scan kann viele einzelne Fundstellen liefern. Für Entwicklung und Projektleitung wird daraus erst eine Arbeitsgrundlage, wenn gleiche Ursachen gruppiert, Prioritäten im ausgewählten Commerce-Flow eingeordnet und manuelle Prüfpunkte sichtbar bleiben.
Warum eine Rohliste nicht reicht
Ein Scan-Tool meldet Befunde meist an einer konkreten URL und an einem konkreten HTML-Element. Das ist als technische Evidenz wichtig. Für die Planung einer Korrektur reicht es allein aber oft nicht.
- Wiederholungen verschleiern die Ursache. Derselbe Kontrastfehler kann an vielen URLs erscheinen, obwohl eine Korrektur an einem zentralen Theme-Token mehrere Fundstellen behebt.
- Die Reihenfolge des Tools ist nicht automatisch die Reihenfolge der Umsetzung. Ein Befund in einem ausgewählten Checkout-Flow kann für die nächste Sprintplanung wichtiger sein als ähnliche Hinweise auf einer nicht ausgewählten Content-Seite.
Die Rohliste bleibt deshalb im technischen Bericht erhalten. Für Entwicklung und Projektleitung wird sie zusätzlich gruppiert und priorisiert.
Nach Problemtyp und Komponente gruppieren
Der erste Schritt ist, Fundstellen nach gemeinsamer technischer Ursache zu bündeln. In Commerce-Projekten treten häufig wiederkehrende Muster auf:
- Kontrast und sichtbarer Fokus, oft in wiederverwendeten Theme-Komponenten
- Bildinhalte und Textalternativen, etwa bei Produkt-, Kategorie- oder Teaserbildern
- Tastaturbedienung und Fokusführung, besonders in Filtern, Dialogen, Warenkorb und Checkout
- Formularfelder und Fehlermeldungen, häufig in individuell erweiterten Checkout-Schritten
- Struktur und Semantik, etwa Überschriften, Listen, Rollen oder zugängliche Namen
- Dynamische Statusmeldungen, etwa nach Variantenwahl, Mengenänderung oder Preisaktualisierung
Das Ziel ist nicht, URL-Fundstellen zu verstecken. Es macht sichtbar, welche Komponenten oder Problemtypen hinter den Fundstellen stehen.
Priorität im ausgewählten Flow einordnen
Eine Priorität ist kein rechtliches Urteil. Sie hilft bei der technischen Reihenfolge innerhalb eines klar definierten Scopes.
| Stufe | Praktische Einordnung |
|---|---|
| Kritisch | Eine ausgewählte Kernfunktion ist für einen Teil der Nutzenden im geprüften Zustand nicht nutzbar, etwa ein nicht erreichbarer Checkout-Schritt oder ein nicht schließbarer Dialog. |
| Hoch | Die Nutzung eines ausgewählten Flows ist erheblich erschwert, etwa durch unklare Formularfehler oder fehlende zugängliche Namen bei relevanten Steuerelementen. |
| Mittel | Der Befund sollte geplant behoben werden, weil er Wahrnehmung, Verständlichkeit oder Bedienbarkeit beeinträchtigt, ohne den ausgewählten Flow unmittelbar zu blockieren. |
| Gering | Der Befund ist dokumentiert und kann im Rahmen einer Komponentenpflege oder eines späteren Sprints behandelt werden. |
Die vier Stufen beschreiben technische Prioritäten. Manuell zu prüfende Punkte werden davon getrennt ausgewiesen und sind keine zusätzliche Prioritätsstufe. Die tatsächliche Einordnung hängt vom geprüften Flow, der betroffenen Komponente und dem vereinbarten Scope ab.
Automatisiert erkannt, manuell prüfen, nicht im Scope
Ein technischer Bericht sollte nicht so wirken, als könne Automatisierung den gesamten Accessibility-Zustand eines Shops abschließend bewerten.
- Automatisch erkannte technische Befunde. Fundstellen im autorisiert geprüften Umfang, etwa fehlende Formularlabels, Kontrastwerte, zugängliche Namen oder bestimmte semantische Fehler.
- Manuell zu prüfende Punkte. Aspekte wie sinnvolle Alternativtexte, tatsächliche Tastaturreihenfolge, Screenreader-Ausgabe, Verständlichkeit von Fehlermeldungen und dynamische Komponenten.
- Nicht geprüfte oder technisch nicht erreichte Bereiche. Zum Beispiel eingeloggte Bereiche, externe Zahlungsanbieter, nicht ausgewählte Seitentypen, nicht autorisierte URLs oder nicht erreichbare Zustände.
Diese Trennung verhindert, dass aus einem begrenzten technischen Scan eine Aussage über den gesamten Shop abgeleitet wird.
Was ein entwicklungsfähiges Ticket enthält
| Information | Zweck |
|---|---|
| Commerce-Flow und betroffene Komponente | Einordnung in den Projektumfang |
| Beispiel-URL und Selektor | Reproduzierbarkeit |
| Problemtyp und technische Erklärung | Ursache verständlich machen |
| WCAG-Bezug | Technischen Referenzrahmen dokumentieren |
| Priorität im Scope | Reihenfolge der Umsetzung |
| Erster technischer Hinweis | Startpunkt für die Korrektur |
| Manuelle Prüfpunkte | Grenzen der Automatisierung sichtbar halten |
| Re-Check-Kriterium | Nach Umsetzung erneut prüfen |
Nicht jedes Ticket braucht einen Codevorschlag. Bei wiederkehrenden Komponenten kann ein konkreter technischer Hinweis sinnvoll sein. Bei komplexen Interaktionen muss die Entwicklung den jeweiligen Kontext prüfen.
Vom Befund zum Fix-Sprint-Scope
Für ein Commerce-Projekt muss nicht jede Fundstelle sofort Teil desselben Auftrags werden. Ein technischer Fix-Sprint-Scope macht die Auswahl nachvollziehbar:
So kann eine Agentur zum Beispiel Produktdetailseite, Warenkorb, Checkout und Consent für einen ersten Sprint auswählen. Konto, Wunschliste, nicht geprüfte Landingpages oder externe Zahlungsdialoge bleiben sichtbar außerhalb des Scopes, statt unbeabsichtigt mitversprochen zu werden.
Eine fiktive Darstellung dieses Workflows zeigt die Fix-Sprint-Demo. Ein vollständiger technischer Beispielaufbau mit Evidenz und Fix-Hinweisen steht im Musterreport.
Kurz zusammengefasst
Eine technische Rohliste ist ein Ausgangspunkt. Für die Umsetzung braucht sie zusätzlich:
- Gruppierung nach Problemtyp und Komponente
- Priorität im ausgewählten Commerce-Flow
- Trennung von automatischen Befunden, manuellen Prüfpunkten und nicht geprüften Bereichen
- Technische Evidenz für Entwicklung und Re-Check
Damit bleibt die Übergabe an Entwicklung nachvollziehbar, ohne aus einem automatisierten Scan mehr abzuleiten, als er tatsächlich prüfen kann.
Weiterführende Quellen
Praxis-Test
Den Workflow an einem autorisierten Projekt prüfen.
Der Praxis-Test ist nur für eigene oder autorisierte Shop-Projekte vorgesehen. Er dient dazu, Scope, Entwicklungsreport und technischen Re-Check in einem realen Commerce-Kontext zu erproben.