responsive Bilder: srcset-Varianten konsistent halten

Was hier wirklich geprüft wird

Alle srcset-Kandidaten müssen dieselbe semantische Aussage darstellen, damit ein gemeinsamer Alt-Text für jede ausgewählte Quelle korrekt bleibt.

Bei „responsive Bilder: srcset-Varianten konsistent halten“ muss die Rolle des Bildes im Seitenkontext zuerst feststehen. Kontrollieren Sie danach src/currentSrc, alt, Link-Zustand, Caption, sichtbare Umgebung und intrinsische/rendered Abmessungen.

Sollverhalten und Entscheidungsgrenze

Sollzustand: Bei „responsive Bilder: srcset-Varianten konsistent halten“ muss die Rolle des Bildes im Seitenkontext zuerst feststehen. Kontrollieren Sie danach src/currentSrc, alt, Link-Zustand, Caption, sichtbare Umgebung und intrinsische/rendered Abmessungen. Die Bildrolle (informativ, dekorativ, funktional) ist zuerst definiert; danach passen alt, Linkfunktion, Caption und Responsive-Asset zu genau dieser Rolle.

Diagnose: welche Nachweise protokollieren

Erfassen Sie src, currentSrc, alt, Link-Zustand, Caption, intrinsische und gerenderte Maße sowie die Rolle des Bildes (informativ, dekorativ, funktional). Bei Responsive Images zusätzlich das tatsächlich geladene Candidate-Asset prüfen.

Alt-Text kann nicht ohne Kontext bewertet werden: dieselbe Zeichenfolge kann für ein wiederkehrendes Logo korrekt und für unterschiedliche Produktwinkel falsch sein.

Technische Umsetzung

Bei „responsive Bilder: srcset-Varianten konsistent halten“ muss die Rolle des Bildes im Seitenkontext zuerst feststehen. Kontrollieren Sie danach src/currentSrc, alt, Link-Zustand, Caption, sichtbare Umgebung und intrinsische/rendered Abmessungen.

<img
  src="product-800.webp"
  srcset="product-400.webp 400w, product-800.webp 800w"
  sizes="(max-width: 600px) 100vw, 800px"
  alt="Black ergonomic office chair, front view"
  width="800" height="800">

Erfassen Sie src/currentSrc, alt, Rolle des Bildes, Link-Zustand, sichtbare Caption sowie intrinsische/rendered Abmessungen. Bewerten Sie Alt-Text immer im Seitenkontext; derselbe String kann bei Logo, Produktwinkel und Diagramm unterschiedlich korrekt sein.

Konkretes Entscheidungsbeispiel

Bildrolle: dekorativ       -> alt=""
Bildrolle: Produktansicht  -> alt="Black chair, side view"
Bildrolle: Link/Control    -> Accessible Name beschreibt Ziel/Aktion

Die Entscheidung startet bei der Funktion des Bildes. Ein Audit, das nur „alt leer/nicht leer“ bewertet, erzeugt bei dekorativen Assets systematisch Fehlalarme.

Typische Ursachen

Häufige Ursachen: CMS erzwingt Alt-Text für jedes Asset ohne Kontext, Medienbibliothek teilt einen generischen Text über mehrere Verwendungen, Templates behandeln dekorative und informative Bilder gleich, Lazy-/Responsive-Komponenten verlieren Attribute oder Redakteure beschreiben Dateinamen statt Bildfunktion.

Sonderfälle und Fehlalarme

alt="" ist für dekorative Bilder korrekt; deshalb darf ein Audit „empty alt“ nicht blind als Fehler zählen. Ein Link-Bild braucht dagegen einen sinnvollen Accessible Name. Bei komplexen Grafiken reicht ein sehr langer Alt-Text oft nicht—die ausführliche Erklärung gehört sichtbar in HTML.

Verifikation nach dem Fix

| Check | PASS | FAIL | | --- | --- | --- | | Output | erwartete Regel ist im ausgelieferten HTML/HTTP/DOM sichtbar | Backend zeigt korrekt, ausgelieferte Ausgabe aber nicht | | Scope | repräsentative URLs aller betroffenen Templates getestet | nur eine Beispiel-URL getestet | | Source | zentrale Ursache/Owner dokumentiert | manuelle Einzel-Edits ohne Root Cause | | Regression | angrenzende Canonical/Robots/Accessibility/Link-Regeln bleiben korrekt | Fix erzeugt neuen Fehler in derselben Component | | Evidence | Vorher/Nachher-Werte und Testzeitpunkt gespeichert | nur visueller Eindruck oder Screenshot |

Verantwortung und Übergabe

Content/SEO-Owner: definiert den erwarteten Seitenzweck und ob die Abweichung wirklich behoben werden muss.
Developer/Platform: behebt die gemeinsame Template-, Routing-, Header- oder Component-Ursache.
QA: testet repräsentative Edge States und führt einen Re-Crawl/Re-Request nach Deployment aus.
Release Owner: dokumentiert Zeitpunkt, Scope und Rollback-Punkt, damit Monitoring-Signale später eindeutig zugeordnet werden können.

Abnahmekriterien

PASS, wenn der ausgelieferte technische Zustand auf repräsentativen URLs wiederholbar ist, die zentrale Ursache behoben wurde, erlaubte Ausnahmen dokumentiert sind und Re-Crawl/Re-Request keine neue Regression bei Canonical, Robots, Accessibility, internen/externen Links oder Rendering zeigt.

1. Betroffene URL-/Template-Klasse definieren und Expected Behavior schriftlich festlegen.
2. Raw HTTP/HTML protokollieren; bei clientseitigen Änderungen zusätzlich den gerenderten DOM prüfen.
3. Bildrolle, alt, currentSrc, Link-Zustand und Maße gemeinsam bewerten.
4. Den Fehler auf die gemeinsame Schicht zurückführen: DNS/CDN, Routing, Template, Component, CMS-Feld oder Editor-Inhalt.
5. Den kleinsten systemischen Fix umsetzen und vorher einen Rollback-Punkt sichern.
6. Positive Fälle, leere/fehlende Daten und mindestens einen Edge Case testen.
7. Alle betroffenen Templates/URLs erneut crawlen bzw. requesten und Vorher/Nachher-Nachweise speichern.
8. PASS: erwartetes Verhalten ist wiederholbar, keine angrenzende SEO-/Accessibility-Regel regressiert und der Fix benötigt keine manuellen Einzel-Workarounds.