White-Label Deep-Dive

Ein Musterreport mit echter Tiefe — ohne Kundenrisiko.

Dieser anonymisierte Demo-Report zeigt nicht nur eine Oberfläche. Er zeigt die volle Argumentationskette: Scope, Management-Priorität, neun gruppierte technische Problemtypen, Evidenz, Code, Fix-Hinweise und vier manuelle Prüfpunkte.

30 Tage kostenlos testen Preise ansehen

Management-Überblick

Technische Barrieren im definierten Scope priorisieren.

Im Demo-Scope wurden neun gruppierte technische Problemtypen erkannt. Die folgenden Maßnahmen unterstützen die Entwicklung und Kundenkommunikation. Sie ersetzen keine vollständige WCAG-/BFSG-Bewertung und keine Rechtsberatung.

12geprüfte Seiten

9gruppierte Problemtypen

27automatisch erkannte Stellen

4manuell zu prüfen

Priorität2Kritischgruppierte technische Befunde

Priorität3Hochgruppierte technische Befunde

Priorität2Mittelgruppierte technische Befunde

Priorität2Geringgruppierte technische Befunde

Diese Maßnahmen zuerst

Drei Maßnahmen, die Entwicklungszeit und Kaufbarrieren verbinden.

Der Executive-Bereich zeigt nur die wichtigsten Startpunkte. Die technische Tiefe folgt anschließend pro Problemtyp.

Checkout-Fehler programmatisch ankündigen

Fehlermeldungen müssen für Screenreader hörbar und mit dem betroffenen Feld verknüpft sein.

2 Stellen · 2 Seiten

Cookie-Consent-Fokus absichern

Dialog, Fokus, Escape und Rückgabe an den Auslöser zuerst sauber umsetzen.

1 Stelle · 12 Seiten

Kontrast-Tokens theme-weit korrigieren

Sekundär-Buttons, Fehlermeldungen und Fokusindikatoren wiederverwendbar verbessern.

11 Stellen · 5 Seiten

Maßnahmenplan

Vom Sofort-Fix bis zur wiederholbaren Qualitätsarbeit.

Priorisierung

Sofort

Kritische Kauf- und Bedienbarrieren zuerst sichern.

Kritisch Checkout-Fehlermeldungen
Kritisch Consent-Fokus

Priorisierung

Kurzfristig

Hohe Prioritäten im nächsten Sprint bündeln.

Hoch Kontrast-Tokens
Hoch Mengensteuerung
Hoch dynamische Preisupdates

Priorisierung

Geplant

Komponenten standardisieren und Regressionen beobachten.

Mittel Link-/Button-Namen
Mittel ARIA-Zustände
Mittel Sprache und Eingabezwecke

Technischer Deep-Dive

Neun Gruppen. 27 Fundstellen. Evidenz, Code und erste Fix-Schritte.

Die folgenden Karten repräsentieren die Technical-Ansicht. In echten Reports kommen selektierte URLs, gespeicherte Regeln und projektspezifische Befunde aus dem autorisierten Scan.

Checkout-Fehlermeldungen werden nicht angekündigt

2 Fundstellen · Checkout / Zahlung / Prüfung · WCAG 4.1.3

KritischAutomatisch

Fehler nach Zahlungs- oder Adressvalidierung erscheinen visuell, werden aber nicht zuverlässig als Statusmeldung für assistive Technologien ausgegeben.

Evidenz

#checkout-payment .error-message
#checkout-review .alert-danger

/checkout/payment
/checkout/review

Beispiel: vor der Korrektur

<div class="alert alert-danger">
  Kreditkarte abgelehnt.
</div>

Beispiel: erste Korrektur

<div role="alert" id="payment-error">
  Kreditkarte abgelehnt.
</div>
<input aria-describedby="payment-error">

Erste Maßnahme

Live-Region ergänzen, Fehlermeldung mit Feld verknüpfen und den Ablauf mit Screenreader manuell prüfen.

Cookie-Consent-Dialog ohne vollständiges Fokusmanagement

1 Fundstelle · alle Demo-Seiten · WCAG 2.4.3 / 4.1.2

KritischAutomatisch

Der Consent-Dialog besitzt keine verlässliche Fokusführung. Tastaturnutzende können den Dialog verlassen oder ihn nicht nachvollziehbar schließen.

Evidenz

#cookie-banner
.cc-banner
[data-consent-banner]

/
/kategorie/demo
/checkout/payment

Beispiel: vor der Korrektur

<div id="cookie-banner">
  <button>Alle akzeptieren</button>
  <button>Ablehnen</button>
</div>

Beispiel: erste Korrektur

<div role="dialog" aria-modal="true"
     aria-labelledby="consent-title">
  ...
</div>

Erste Maßnahme

Fokus beim Öffnen setzen, Tab-Reihenfolge begrenzen, Escape prüfen und Fokus danach kontrolliert zurückgeben.

Zu geringer Kontrast in wiederkehrenden Komponenten

11 Fundstellen · 5 Seiten · WCAG 1.4.3 / 1.4.11

HochAutomatisch

Sekundär-Buttons, Fehlermeldungen und Fokusindikatoren unterschreiten in mehreren Komponenten die erforderliche Les- oder Wahrnehmbarkeit.

Evidenz

.button--secondary
.invalid-feedback
:focus-visible

/warenkorb
/checkout/address
/konto/login

Messwerte

#999 auf #fff      2.8:1
#dc3545 auf #fff   3.9:1
#1667e8 auf #fff   5.2:1

Empfohlene Token

--color-secondary: #5a6a85;
--color-error: #b42318;
--focus-ring: #1d63c4;

Erste Maßnahme

Farbwerte als zentrale Design-Tokens korrigieren und die wiederverwendeten Komponenten erneut prüfen.

Mengenauswahl ohne eindeutigen zugänglichen Namen

3 Fundstellen · Warenkorb / PDP · WCAG 4.1.2

HochAutomatisch

Mengenfelder und Icon-Buttons sind für Screenreader nicht ausreichend dem jeweiligen Produkt zugeordnet.

Evidenz

.cart-item-qty input
.quantity-selector select
.product-qty .qty-btn

Beispiel: vor der Korrektur

<label>Menge</label>
<input type="number" value="1">

Beispiel: erste Korrektur

<label for="qty-123">
  Menge: Demo-Produkt
</label>
<input id="qty-123" type="number">

Erste Maßnahme

Label-Verknüpfung und aria-labels mit Produktbezug ergänzen; danach Tastatur und Screenreader testen.

Dynamische Preis- und Versandupdates ohne Live-Region

2 Fundstellen · PDP / Warenkorb · WCAG 4.1.3

HochAutomatisch

Nach Variantenwahl oder Mengenänderung verändern sich Preis und Versandkosten, ohne dass die Änderung für Screenreader eindeutig angekündigt wird.

Evidenz

.product-price .amount
.cart-totals .total-amount

Beispiel: erste Korrektur

<output aria-live="polite"
        aria-atomic="true">
  Preis: 49,99 €
</output>

Manuell verifizieren

Ansage nur bei tatsächlicher Änderung, keine Informationsflut bei jeder Zwischeneingabe.

Erste Maßnahme

Live-Region im Komponentenstandard implementieren und Varianten-/Versandwechsel mit NVDA oder VoiceOver prüfen.

Link- und Button-Namen ohne ausreichenden Kontext

3 Fundstellen · Footer / Produktteaser · WCAG 2.4.4

MittelAutomatisch

Linktexte wie „Mehr“ oder „Weiter“ beschreiben das Ziel nicht zuverlässig, wenn sie isoliert vorgelesen werden.

Evidenz

a.more-link
.product-teaser a
.footer a.read-more

Vorher

<a href="https://shop.example/versand">Mehr erfahren</a>

Nachher

<a href="https://shop.example/versand">
  Versandkosten und Lieferzeiten
</a>

Erste Maßnahme

Komponenten mit generischen CTA-Texten inventarisieren und pro Kontext eindeutige Bezeichnungen festlegen.

ARIA-Zustand an sichtbarer Navigation inkonsistent

2 Fundstellen · Mobile Navigation / Filter · WCAG 4.1.2

MittelAutomatisch

Sichtbare Elemente werden mit versteckenden ARIA-Attributen versehen oder Statusattribute nicht synchron zum visuellen Zustand aktualisiert.

Evidenz

nav[aria-hidden="true"]
.filter-toggle[aria-expanded]

Vorher

<nav aria-hidden="true">
  <a href="https://shop.example/kategorie">Kategorie</a>
</nav>

Nachher

button.setAttribute(
  "aria-expanded", String(isOpen)
)

Erste Maßnahme

Komponentenstatus zentral steuern und Sichtbarkeit, Fokus und ARIA-Zustand gemeinsam testen.

Seitensprache nicht konsistent ausgezeichnet

1 Fundstelle · Landing-/Content-Template · WCAG 3.1.1

GeringAutomatisch

Ein Template besitzt kein eindeutiges oder falsches Sprachattribut. Screenreader können die Vorlesesprache dadurch falsch wählen.

Evidenz

<html>

Erste Korrektur

<html lang="de">

Erste Maßnahme

Im Basistemplate festlegen und bei mehrsprachigen Bereichen Sprachwechsel gezielt auszeichnen.

Scope

1 betroffene Template-Ausgabe im Demo-Scope.

Eingabezwecke im Checkout nicht vollständig ausgezeichnet

2 Fundstellen · Adresse / Zahlung · WCAG 1.3.5

GeringAutomatisch

Adress- und Zahlungsfelder fehlen teilweise die standardisierten autocomplete-Werte für unterstützende Technologien und Browserhilfe.

Evidenz

#checkout-address input
#payment-card input

Beispiel

autocomplete="given-name"
autocomplete="street-address"
autocomplete="postal-code"
autocomplete="cc-number"

Erste Maßnahme

Feldschema in Checkout-Komponenten dokumentieren und Werte nach Eingabezweck ergänzen.

Manuell verifizieren

Autofill-Verhalten und reale Checkout-Validierung in Zielbrowsern prüfen.

Manuelle Prüfpunkte

Vier Fragen, die ein technischer Scan offen lässt.

Sie sind im Report bewusst nicht als automatisch bestätigte Verstöße dargestellt.

Manuell prüfen

Diese Checkliste zeigt der Agentur, was zusätzlich mit Tastatur, assistiven Technologien und fachlichem Kontext geprüft werden sollte.

Checkout nur mit Tastatur

Fokusreihenfolge, sichtbarer Fokus, Escape, Modals und alle Bestellschritte ohne Maus.

Screenreader-Flow

Vorlesereihenfolge von Labels, Fehlern, Preisen, Versandoptionen und Bestellbestätigung.

Inhalt und Verständlichkeit

Sinnhaftigkeit von Alternativtexten, Fehlertexten, Liefer-/Zahlungsinformationen und Sprache.

Externe Checkout-Grenzen

Payment-Provider, eingebettete Widgets oder Login-Schritte, die nicht im technischen Scope erreichbar waren.

Was White Label im echten Report bedeutet

Der Report wird mit dem Branding der Agentur erstellt. Der Shop des Kunden bleibt der Audit-Gegenstand.

Agenturname, Logo, Primär- und Akzentfarbe im Branding-Snapshot
Executive-, White-Label- und Technical-Ansicht für unterschiedliche Empfänger
Footer-Text und Reporttitel der Agentur
Keine erfundenen Domain-, CNAME-, E-Mail-Absender- oder SLA-Versprechen

Prüfgrenzen, die der Kunde verstehen muss

Keine vollständige WCAG-/BFSG-Konformitätsbewertung
Keine Rechtsberatung und keine automatische Erklärung zur Barrierefreiheit
Erweiterte Scopes werden nicht pauschal behauptet, sondern als konkrete Coverage dokumentiert: entdeckt, zulässig, geprüft, ausgeschlossen oder technisch nicht erreichbar.
Ein fehlerfreier automatischer Scan ist keine Konformitätsbestätigung
Manuelle Prüfung und Tests mit assistiven Technologien bleiben notwendig

Ein Musterreport mit echter Tiefe — ohne Kundenrisiko.

Technische Barrieren im definierten Scope priorisieren.

Drei Maßnahmen, die Entwicklungszeit und Kaufbarrieren verbinden.

Checkout-Fehler programmatisch ankündigen

Cookie-Consent-Fokus absichern

Kontrast-Tokens theme-weit korrigieren

Vom Sofort-Fix bis zur wiederholbaren Qualitätsarbeit.

Sofort

Kurzfristig

Geplant

Neun Gruppen. 27 Fundstellen. Evidenz, Code und erste Fix-Schritte.

Checkout-Fehlermeldungen werden nicht angekündigt

Evidenz

Beispiel: vor der Korrektur

Beispiel: erste Korrektur

Erste Maßnahme

Cookie-Consent-Dialog ohne vollständiges Fokusmanagement

Evidenz

Beispiel: vor der Korrektur

Beispiel: erste Korrektur

Erste Maßnahme

Zu geringer Kontrast in wiederkehrenden Komponenten

Evidenz

Messwerte

Empfohlene Token

Erste Maßnahme

Mengenauswahl ohne eindeutigen zugänglichen Namen

Evidenz

Beispiel: vor der Korrektur

Beispiel: erste Korrektur

Erste Maßnahme

Dynamische Preis- und Versandupdates ohne Live-Region

Evidenz

Beispiel: erste Korrektur

Manuell verifizieren

Erste Maßnahme

Link- und Button-Namen ohne ausreichenden Kontext

Evidenz

Vorher

Nachher

Erste Maßnahme

ARIA-Zustand an sichtbarer Navigation inkonsistent

Evidenz

Vorher

Nachher

Erste Maßnahme

Seitensprache nicht konsistent ausgezeichnet

Evidenz

Erste Korrektur

Erste Maßnahme

Scope

Eingabezwecke im Checkout nicht vollständig ausgezeichnet

Evidenz

Beispiel

Erste Maßnahme

Manuell verifizieren

Vier Fragen, die ein technischer Scan offen lässt.

Manuell prüfen

Was White Label im echten Report bedeutet

Prüfgrenzen, die der Kunde verstehen muss

Erst die Tiefe prüfen. Dann entscheiden, ob sie zu Ihrer Agentur passt.