Speisekarten-Fotos und Werbebanner nach WCAG 2.2 prüfen: ein Audit-Workflow

Ein Speisekarten-Foto, das für sehende Gäste appetitlich wirkt, kann für Nutzer von Screenreadern oder für Menschen mit eingeschränktem Sehvermögen vollständig unzugänglich sein. Die kurze Antwort auf die Frage, wie man Speisekarten-Bildmaterial nach WCAG 2.2 prüft: Man geht jedes Bild, jeden Banner und jedes PDF-Menü gegen vier konkrete Erfolgskriterien durch – 1.1.1 Nicht-Text-Inhalte, 1.4.3 Kontrast (Minimum), 1.4.5 Bilder von Text und 1.4.11 Nicht-Text-Kontrast – und dokumentiert für jedes Element, ob es das Kriterium erfüllt, teilweise erfüllt oder nicht erfüllt. Dieser Artikel beschreibt ein wiederholbares Vorgehen dafür, getrennt von der Prüfung von Bestell- oder Reservierungsformularen, die eigenen WCAG-Kriterien unterliegen.

Was dieses Audit umfasst – und was es bewusst ausklammert

Dieses Audit befasst sich ausschließlich mit statischem und semi-statischem Bildmaterial: Gerichtfotos in Galerien, Hero-Banner mit Aktionsangeboten, Speisekarten als PDF-Download und ähnliche Nicht-Text-Inhalte. Es klammert bewusst aus: Online-Bestellformulare, Reservierungswidgets, Warenkorb-Prozesse und jede Form von interaktiver Eingabe. Diese Bereiche fallen unter andere WCAG-Erfolgskriterien, etwa zu Beschriftungen, Fehlermeldungen und Tastaturbedienbarkeit, und benötigen ein eigenes Prüfverfahren.

Das 4-Kriterien-Framework für Speisekarten-Bildmaterial

Für die Praxis hat sich ein Vorgehen bewährt, das wir hier als 4-Kriterien-Framework bezeichnen: Jedes Bildelement wird nacheinander gegen vier WCAG-2.2-Kriterien geprüft, bevor es als „geprüft" markiert wird.

Entscheidungsraster: Alt-Text oder leer?

Nicht jedes Bild braucht eine lange Beschreibung. Ein einfaches Entscheidungsraster hilft bei der Einordnung:

1. Ist das Bild rein dekorativ und trägt keine Information (z. B. ein Hintergrundmuster)? → Alt-Attribut leer lassen (alt="").
2. Wiederholt das Bild eine Information, die im Fließtext bereits steht (z. B. ein Foto neben der Textbeschreibung eines Gerichts)? → Kurzer, nicht redundanter Alt-Text, der das Bild beschreibt, ohne den Text zu wiederholen.
3. Enthält das Bild Informationen, die sonst nirgends stehen (z. B. ein Aktionsbanner mit Datum und Preis nur als Grafik)? → Vollständiger, informativer Alt-Text oder besser: die Information zusätzlich als echten Text bereitstellen.
4. Ist das Bild Teil eines bedienbaren Elements (z. B. ein Icon-Button)? → Alt-Text beschreibt die Funktion, nicht das Aussehen.

Workflow: Schritt für Schritt durch die Seite

1. Inventar erstellen. Alle Bilder, Banner und PDF-Dateien auf der Speisekarten-Seite und verlinkten Unterseiten auflisten.
2. Kategorisieren. Jedes Element als „dekorativ", „informativ" oder „funktional" (bedienbares Element) einordnen.
3. Alt-Texte prüfen. Für jedes informative und funktionale Bild den vorhandenen Alt-Text lesen und fragen: Würde eine Person, die das Bild nicht sehen kann, die gleiche Information erhalten wie eine sehende Person?
4. Kontrast messen. Für Text über Bildern und für grafische UI-Elemente die Kontrastwerte gegen die in WCAG 2.2 festgelegten Mindestverhältnisse prüfen.
5. PDF-Menüs separat behandeln. Prüfen, ob das PDF getaggt ist, eine logische Lesereihenfolge hat und ob eine HTML-Alternative existiert.
6. Ergebnisse dokumentieren. Für jedes Element Kriterium, Status (erfüllt/teilweise/nicht erfüllt) und nötige Korrektur festhalten.
7. Nachprüfen nach Korrektur. Geänderte Elemente erneut gegen dasselbe Kriterium prüfen.

Messung: Was sich automatisieren lässt und was nicht

Automatisierte Kontrast-Checker können das Verhältnis zwischen Vordergrund- und Hintergrundfarbe zuverlässig berechnen und damit direkt gegen die Schwellenwerte aus 1.4.3 und 1.4.11 prüfen. Sie sind dafür ein sinnvolles erstes Filterwerkzeug. Sie können jedoch nicht beurteilen, ob ein Alt-Text inhaltlich sinnvoll ist, ob ein Bild reine Dekoration ist oder ob ein PDF korrekt strukturiert wurde. Diese Einschätzungen erfordern eine Person, die den Kontext der Seite kennt. Eine sinnvolle Messpraxis kombiniert daher:

• Automatisierte Kontrastprüfung für alle Text-über-Bild-Kombinationen und grafischen Bedienelemente.
• Manuelle Stichprobenprüfung aller Alt-Texte, insbesondere bei Bannern mit zeitlich begrenzten Angeboten.
• Manuelle Prüfung der PDF-Tag-Struktur mit einem PDF-Barrierefreiheits-Prüfwerkzeug oder durch Öffnen im Screenreader.

Menü-PDFs: ein eigener Prüfpunkt

PDF-Speisekarten verdienen besondere Aufmerksamkeit, weil sie oft als gescanntes Bild oder als reines Layout-Dokument ohne Textstruktur veröffentlicht werden. Ein solches PDF ist für Screenreader-Nutzer faktisch unlesbar, unabhängig davon, wie gut die restliche Website zugänglich ist. Die Prüfung sollte klären: Liegt eine textbasierte, getaggte PDF-Version vor? Existiert zusätzlich eine HTML-Version der Speisekarte als Alternative? Ist die Lesereihenfolge der Tags logisch (Gerichtname vor Beschreibung vor Preis)?

Grenzen dieses Audits

Dieses Verfahren deckt Nicht-Text-Inhalte ab, aber es ersetzt keine vollständige WCAG-Konformitätsprüfung der gesamten Website. Es sagt nichts über Tastaturbedienbarkeit von Menüs, über Formularlogik b

Randfälle im Bildmaterial, die eine eigene Prüfung erfordern

Der 4-Kriterien-Workflow deckt den Regelfall ab – ein <img>-Element mit oder ohne Alt-Attribut. Einige auf Speisekarten-Seiten häufige Muster passen jedoch nicht in dieses einfache Schema und müssen im Audit gesondert vermerkt werden.

CSS-Hintergrundbilder statt echter Bild-Elemente

Wird ein Gerichtfoto per CSS als background-image statt als <img> eingebunden, existiert technisch kein Alt-Attribut. Enthält ein solches Hintergrundbild Information (z. B. der einzige Träger eines Sonderangebots), muss diese Information an anderer Stelle im sichtbaren oder für Screenreader zugänglichen Text stehen. Reine Dekoration per Hintergrundbild ist unkritisch, sollte im Audit aber dennoch als Fall dokumentiert werden, um spätere Verwechslungen mit fehlenden Alt-Texten zu vermeiden.

Automatisch wechselnde Foto-Karussells

Bei Slidern mit mehreren Gerichtfotos ist zu prüfen, ob jedes einzelne Bild im Karussell einen eigenen, dem jeweiligen Inhalt entsprechenden Alt-Text hat, statt eines einzigen generischen Textes für alle Folien. Zusätzlich sollte dokumentiert werden, ob Bedienelemente zum Steuern des Karussells (Pfeile, Punkte) selbst wieder gegen 1.1.1 und 1.4.11 geprüft wurden.

Eingebettete Social-Media-Feeds

Instagram- oder Facebook-Widgets, die Gerichtfotos aus einem externen Konto einbinden, liegen häufig außerhalb der eigenen Kontrolle des Betreibers. Im Audit sollte vermerkt werden, dass solche Einbettungen separat beim Anbieter des Widgets zu prüfen sind, und dass fehlende Alt-Texte in diesem Fall nicht durch die eigene Website behoben werden können.

Farbcodierte Kennzeichnungen

Symbole für vegan, scharf oder Allergene, die ausschließlich über Farbe unterschieden werden, fallen nicht unter die vier hier behandelten Kriterien, sondern unter ein eigenes Kriterium zur Verwendung von Farbe in WCAG 2.2. Ein Audit der Menü-Bildsprache sollte diesen Fall zumindest als offenen Punkt notieren, auch wenn seine vollständige Prüfung außerhalb des hier beschriebenen 4-Kriterien-Rahmens liegt.

Lazy-Loading nachgeladener Bilder

Wird ein Bild erst beim Scrollen geladen, kann eine automatisierte Prüfung es je nach Testverfahren übersehen. Bei der manuellen Stichprobe sollte deshalb aktiv bis zum Seitenende gescrollt werden, bevor die Prüfung als abgeschlossen gilt.

Erweiterte Checkliste für Randfälle

• Wurden CSS-Hintergrundbilder mit Informationsgehalt identifiziert und deren Inhalt textlich dupliziert?
• Hat jedes Einzelbild in einem Karussell einen eigenen, passenden Alt-Text?
• Sind Karussell-Steuerelemente selbst gegen 1.1.1 und 1.4.11 geprüft?
• Wurden eingebettete Social-Media-Bilder als „außerhalb der eigenen Kontrolle" markiert statt als „nicht erfüllt" gewertet?
• Wurden farbcodierte Symbole als offener Punkt für eine gesonderte Prüfung vermerkt?
• Wurde bis zum Seitenende gescrollt, um lazy-loaded Bilder zu erfassen?

Stichprobenumfang und Berichtsstruktur

Bei Seiten mit sehr vielen Gerichtfotos ist eine Vollprüfung aller Bilder nicht immer praktikabel. Sinnvoll ist eine Einteilung nach Schweregrad, damit Korrekturen priorisiert werden können.

Der Bericht sollte pro Element Kriterium, Schweregrad, Fundstelle (URL oder Seitenbereich) und empfohlene Korrektur enthalten, damit spätere Nachtests denselben Stand referenzieren können.

Wann ein Nachtest nötig ist

• Nach jeder saisonalen Änderung der Speisekarte, da neue Fotos und Banner neue Alt-Texte benötigen.
• Nach einem Relaunch oder Theme-Wechsel der Website, da sich CSS-Hintergrundbilder und Kontrastwerte ändern können.
• Nach dem Austausch des PDF-Menüs, auch wenn nur Preise aktualisiert wurden.
• In regelmäßigen Abständen als Stichprobe, unabhängig von erkennbaren Änderungen.

Was dieses Audit weiterhin nicht beantwortet

Die hier beschriebene Prüfung bewertet Nicht-Text-Inhalte gegen vier ausgewählte Kriterien aus WCAG 2.2. Sie beantwortet nicht, ob die Website insgesamt konform ist, da weitere Kriterien – etwa zur Verwendung von Farbe, zu Bewegtbildinhalten oder zu Tastaturfokus – nicht Teil dieses Rahmens sind. Ebenso wenig trifft dieses Audit eine rechtliche Aussage über Konformität; dafür ist eine vollständige, dokumentierte Prüfung gegen alle anwendbaren Kriterien notwendig. Video-Inhalte, animierte GIFs mit Bewegungseffekten und mobile Apps, die dieselben Speisekarten-Fotos anzeigen, liegen außerhalb dieses Audits und benötigen eigene Prüfverfahren.

Primärquellen

• W3C: Web Content Accessibility Guidelines 2.2

FAQ

Redaktioneller Hinweis: ChefNet veröffentlicht diesen Leitfaden und entwickelt Produkte für Restaurantsuche und -betrieb. Allgemeine Betriebshinweise sind von Produktaussagen getrennt. Funktionen können sich im Verlauf der Pilotphase ändern. Veröffentlicht 2026-08-12.