SVG-Bilder: Praktische Regel und Verifikation

Was hier wirklich geprüft wird

Ein SVG über img benötigt Alt-Text wie andere Bilder; bedeutungsvolles Inline-SVG braucht je nach Nutzung einen zugänglichen Namen.

Bei „SVG-Bilder: Praktische Regel und Verifikation“ muss die Rolle des Bildes im Seitenkontext zuerst feststehen. Messen Sie danach src/currentSrc, alt, Link-Zustand, Caption, sichtbare Umgebung und intrinsische/rendered Abmessungen.

Sollverhalten und Entscheidungsgrenze

Sollzustand: Bei „SVG-Bilder: Praktische Regel und Verifikation“ muss die Rolle des Bildes im Seitenkontext zuerst feststehen. Messen 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 Messdaten erfassen

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 „SVG-Bilder: Praktische Regel und Verifikation“ muss die Rolle des Bildes im Seitenkontext zuerst feststehen. Messen Sie danach src/currentSrc, alt, Link-Zustand, Caption, sichtbare Umgebung und intrinsische/rendered Abmessungen.

<img src="example.webp" alt="Concise description of the image's relevant purpose" width="1200" height="800">

[...document.images].map(i => ({src:i.currentSrc, alt:i.getAttribute('alt'), w:i.naturalWidth, h:i.naturalHeight}))

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 tatsächlich ausgelieferten HTML/HTTP/DOM sichtbar | Backend zeigt korrekt, tatsächlich ausgelieferte Ausgabe aber nicht | | Scope | repräsentative URLs aller betroffenen Templates getestet | nur eine Beispiel-URL getestet | | Source | systemische 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 systemische 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 tatsächlich ausgelieferte technische Zustand auf repräsentativen URLs konsistent nachweisbar ist, die systemische 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 erfassen; 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 systemische 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-Messdaten speichern.
8. PASS: erwartetes Verhalten ist konsistent nachweisbar, keine angrenzende SEO-/Accessibility-Regel regressiert und der Fix benötigt keine manuellen Einzel-Workarounds.