Kurzantwort: Eine digitale Speisekarte gilt für diese Prüfung als brauchbar geprüft, wenn sie mindestens elf konkrete WCAG-2.2-Erfolgskriterien besteht: Textalternativen für Bilder (1.1.1), ausreichender Kontrast für Text und Nicht-Text-Elemente (1.4.3, 1.4.11), vollständige Tastaturbedienbarkeit (2.1.1), nachvollziehbare Fokusreihenfolge (2.4.3), sichtbarer Fokus (2.4.7), nicht verdeckter Fokus (2.4.11), Alternativen zu Ziehbewegungen (2.5.7), ausreichende Zielgröße (2.5.8), keine erzwungene Wiederholung bereits eingegebener Daten (3.3.7) sowie korrekt ausgezeichnete Name-Rolle-Wert-Eigenschaften für Screenreader (4.1.2). Diese Kriterien stammen direkt aus der WCAG-2.2-Empfehlung des W3C und lassen sich Punkt für Punkt gegen eine Speisekarten- und Bestell-Oberfläche testen.
Warum eine eigene Checkliste für Speisekarten sinnvoll ist
Digitale Speisekarten unterscheiden sich von generischen Websites: Sie kombinieren Bildmaterial, Preisangaben, Allergenkennzeichnungen, Mengen- und Größenoptionen sowie mehrstufige Auswahlprozesse bis zum Warenkorb. Ein allgemeiner WCAG-Audit deckt oft nicht ab, wie sich Zusatzoptionen für ein Gericht per Tastatur auswählen lassen oder ob ein Screenreader eine „glutenfrei"-Kennzeichnung überhaupt vorliest. Die folgende Struktur ordnet die relevanten WCAG-2.2-Kriterien entlang des tatsächlichen Nutzerpfads: Durchblättern, Detailansicht, Zusatzoptionen, Warenkorb, Checkout.
Das Rahmenwerk: Mobile Menü- und Bestell-Barrierefreiheits-Checkliste
Dieses Rahmenwerk gliedert die Prüfung in fünf Stationen entlang der Bestellstrecke. Jede Station wird gegen konkrete WCAG-2.2-Kriterien getestet, nicht gegen allgemeine Eindrücke.
Station 1: Durchblättern der Speisekarte
- 1.1.1 Nicht-Text-Inhalte: Jedes Gerichtsfoto besitzt einen Alternativtext, der Gericht und relevante Merkmale beschreibt, nicht nur „Foto".
- 1.4.3 / 1.4.11 Kontrast: Fließtext erreicht ein Kontrastverhältnis von mindestens 4,5:1, grafische Kennzeichnungen (z. B. Allergen-Icons) mindestens 3:1 gegenüber dem Hintergrund.
- 2.1.1 Tastatur: Kategorien lassen sich ohne Maus per Tab und Pfeiltasten durchblättern.
Station 2: Detailansicht eines Gerichts
- 2.4.7 Fokus sichtbar: Ein klar erkennbarer Fokusrahmen begleitet jede Tastaturnavigation innerhalb der Detailseite.
- 4.1.2 Name, Rolle, Wert: Buttons wie „Details anzeigen" oder „Zum Warenkorb hinzufügen" sind für Screenreader korrekt benannt und mit ihrer Rolle ausgezeichnet.
Station 3: Auswahl von Zusatzoptionen
- 2.5.8 Zielgröße: Auswahlflächen für Größen, Extras oder Mengenangaben sind groß genug für präzises Antippen.
- 2.5.7 Ziehbewegungen: Wo Schieberegler zur Mengenwahl eingesetzt werden, existiert eine gleichwertige Alternative ohne Ziehbewegung, etwa Plus-/Minus-Buttons.
- 4.1.2: Radio-Buttons und Checkboxen für Zusatzoptionen werden vom Screenreader mit Zustand (ausgewählt/nicht ausgewählt) angesagt.
Station 4: Warenkorb
- 2.4.3 Fokusreihenfolge: Nach dem Hinzufügen eines Artikels bewegt sich der Fokus nachvollziehbar, nicht willkürlich an eine unerwartete Stelle der Seite.
- 2.4.11 Fokus nicht verdeckt: Sticky Header oder Cookie-Banner verdecken den fokussierten Warenkorb-Button nicht.
Station 5: Checkout
- 3.3.7 Redundante Eingabe: Bereits im vorherigen Schritt erfasste Angaben (z. B. Tischnummer, Kontaktdaten) müssen im nächsten Schritt nicht erneut eingegeben werden, sofern sie weiterhin gültig sind.
- 2.1.1 Tastatur: Der gesamte Checkout-Prozess, einschließlich Zahlungsauswahl, ist ohne Maus abschließbar.
Prüftabelle: Kriterium, Test, Ergebnis
| WCAG-2.2-Kriterium | Konkreter Test | Bestanden, wenn |
|---|---|---|
| 1.1.1 Nicht-Text-Inhalte | Alt-Text jedes Gerichtsfotos per Screenreader vorlesen lassen | Beschreibung ist inhaltlich sinnvoll, kein Platzhaltertext |
| 1.4.3 / 1.4.11 Kontrast | Kontrastverhältnis mit einem Prüfwerkzeug messen | Text ≥ 4,5:1, grafische Elemente ≥ 3:1 |
| 2.1.1 Tastatur | Gesamte Bestellstrecke nur mit Tab, Enter, Pfeiltasten durchlaufen | Keine Funktion erfordert Maus oder Touch |
| 2.4.3 Fokusreihenfolge | Tab-Reihenfolge mit visueller Lesereihenfolge vergleichen | Fokus folgt logisch der Seitenstruktur |
| 2.4.7 Fokus sichtbar | Fokusrahmen bei jedem interaktiven Element prüfen | Fokus ist deutlich erkennbar, nicht durch CSS entfernt |
| 2.4.11 Fokus nicht verdeckt | Fokussiertes Element bei aktivem Sticky-Header prüfen | Element bleibt vollständig sichtbar |
| 2.5.7 Ziehbewegungen | Schieberegler-Funktionen ohne Ziehen testen | Gleichwertige Alternative ohne Drag vorhanden |
| 2.5.8 Zielgröße | Touch-Ziele mit Lineal oder Dev-Tools messen | Zielgröße entspricht dem Kriterium, oder Ausnahme greift nachweislich |
| 3.3.7 Redundante Eingabe | Mehrstufigen Checkout durchlaufen und Wiederholungen prüfen | Bereits erfasste Daten werden vorausgefüllt oder nicht erneut verlangt |
| 4.1.2 Name, Rolle, Wert | Buttons und Formularfelder mit Screenreader prüfen | Name, Rolle und Zustand werden korrekt angesagt |
Messung: Wie eine Prüfrunde konkret abläuft
- Automatisierte Vorprüfung mit einem etablierten Accessibility-Scanner durchführen, um offensichtliche Kontrast- und Auszeichnungsfehler zu identifizieren.
- Manuellen Tastatur-Durchlauf der gesamten Bestellstrecke protokollieren: jede Station aus der Checkliste einzeln abhaken.
- Screenreader-Test mit mindestens einem gängigen Screenreader auf Desktop und einem auf Mobilgerät durchführen, da sich Ansageverhalten unterscheiden kann.
- Ergebnisse pro Kriterium als Bestanden/Nicht bestanden mit Bildschirmfoto oder Aufzeichnung dokumentieren, nicht nur als Gesamteindruck.
- Nach Behebung gefundener Mängel
Randfälle, die die Grundprüfung oft übersieht
Die fünf Stationen der Checkliste decken den linearen Bestellpfad ab. In der Praxis treten jedoch Sonderfälle auf, die eine gesonderte Prüfung verlangen, weil sie in Standard-Audits selten mitgetestet werden.
Dynamisch nachgeladene Inhalte
Wenn Zusatzoptionen oder Preise erst nach einer Auswahl per JavaScript nachgeladen werden, ist zu prüfen, ob der Fokus danach an der erwarteten Stelle bleibt (2.4.3) und ob Screenreader die Änderung als Statusmeldung erkennen und die aktualisierte Name-Rolle-Wert-Information korrekt ausgeben (4.1.2). Ein rein visuelles Update ohne begleitende Ansage gilt als nicht bestanden, auch wenn der sichtbare Text korrekt ist.
Eingebettete Drittanbieter-Widgets
Bestell- oder Zahlungsmodule, die per iframe eingebunden sind, müssen einzeln auf Tastaturbedienbarkeit (2.1.1) und sichtbaren Fokus (2.4.7) geprüft werden. Ein Betreiber kann die eigene Speisekarte konform gestalten, während ein eingebettetes Drittmodul eigene Mängel aufweist, die separat dokumentiert und beim Anbieter adressiert werden müssen.
Allergen- und Diätfilter
Filterfunktionen, die Gerichte nach „vegan" oder „glutenfrei" ein- oder ausblenden, sind ein eigener Interaktionspfad. Nach Anwendung eines Filters ist zu prüfen, ob die Anzahl verbleibender Treffer für Screenreader-Nutzer angesagt wird und ob der Fokus nicht auf ein inzwischen ausgeblendetes Element zeigt.
Ausverkaufte oder zeitlich begrenzte Artikel
Wird ein Gericht als „ausverkauft" markiert, muss dieser Zustand auch nicht-visuell erkennbar sein. Eine reine Grauschattierung ohne Textäquivalent oder ARIA-Zustand erfüllt 4.1.2 nicht, selbst wenn der Kontrast der übrigen Schrift korrekt ist.
Grenzen dieser Checkliste
Die Prüftabelle bildet Konformität mit einzelnen WCAG-2.2-Erfolgskriterien ab, ersetzt aber keinen vollständigen Nutzertest. Mehrere Einschränkungen sind zu beachten, bevor ein „Bestanden" als abschließendes Ergebnis kommuniziert wird.
- Automatisierte Scanner erkennen strukturelle Fehler wie fehlenden Alt-Text oder fehlerhafte Kontrastwerte, können aber nicht beurteilen, ob ein Alt-Text inhaltlich sinnvoll ist oder ob eine Fokusreihenfolge für Nutzende tatsächlich nachvollziehbar ist.
- Ein Test mit einem einzelnen Screenreader auf einem Gerät deckt nicht das gesamte Spektrum unterschiedlicher assistiver Technologien und Einstellungen ab; Ansageverhalten kann je nach Kombination aus Browser und Screenreader variieren.
- Die Ausnahmeregelungen einzelner Kriterien, etwa bei Zielgröße (2.5.8), sind im WCAG-2.2-Dokument selbst nachzulesen und im Einzelfall zu prüfen, nicht pauschal anzunehmen.
- Konformität mit den geprüften Kriterien ist keine rechtliche Aussage zu Barrierefreiheitspflichten in einer bestimmten Rechtsordnung; hierzu ist gegebenenfalls eigene rechtliche Beratung einzuholen.
Entscheidungsrahmen: Priorisierung gefundener Mängel
Nicht jeder Fehler blockiert die Bestellung gleichermaßen. Eine einfache Einstufung hilft, Korrekturen sinnvoll zu priorisieren, bevor ein Redesign live geht oder direkt danach.
Schweregrad Beispiel Empfohlene Reaktion Blockierend Checkout per Tastatur nicht abschließbar (2.1.1) Vor Veröffentlichung beheben, kein Livegang mit offenem Blocker Erheblich einschränkend Fokus nach Warenkorb-Update springt an unerwartete Stelle (2.4.3) Zeitnah beheben, im nächsten Release-Zyklus Teilweise einschränkend Grafisches Allergen-Icon unter 3:1 Kontrast (1.4.11) Im laufenden Wartungsplan einplanen Gering Alt-Text vorhanden, aber knapp formuliert Bei nächster Inhaltsüberarbeitung verbessern Wiederholungsprüfung nach Änderungen
Eine einmalige Prüfung verliert an Aussagekraft, sobald sich Menüstruktur, Zusatzoptionen oder Checkout-Schritte ändern. Folgende Anlässe rechtfertigen eine erneute Durchführung der fünf Stationen:
- Einführung neuer Zusatzoptionstypen, etwa Schieberegler oder Drag-Elemente, die zuvor nicht existierten.
- Wechsel des Bestell- oder Zahlungsanbieters, da eingebettete Komponenten eigene Konformitätsstände haben können.
- Strukturelle Änderungen an der Fokusreihenfolge, etwa durch ein neues Layout des Warenkorbs.
- Hinzufügen neuer Allergen- oder Diätfilter, die zuvor nicht Teil der Speisekarte waren.
Jede Wiederholungsprüfung sollte, wie die Erstprüfung, pro Kriterium einzeln als Bestanden oder Nicht bestanden dokumentiert werden, damit Änderungen im Zeitverlauf nachvollziehbar bleiben.
Einordnung im ChefNet-Produktkontext
ChefNet entwickelt Produkte im Bereich Restaurant-Auffindbarkeit und -Betrieb. Ob und in welchem Umfang eine ChefNet-Speisekarten- oder Bestelloberfläche die hier beschriebenen WCAG-2.2-Kriterien bereits erfüllt, ist unabhängig von dieser Checkliste zu prüfen. Betreiber sollten den jeweils aktuellen Funktionsumfang direkt bei ChefNet verifizieren, bevor sie Konformitätsaussagen zu einer konkreten Speisekarten-Implementierung treffen.
Primärquellen
FAQ
Welche WCAG-2.2-Kriterien sind für eine digitale Speisekarte am wichtigsten?
Für das Durchblättern und Bestellen sind vor allem 1.1.1 Nicht-Text-Inhalte, 1.4.3 und 1.4.11 für Kontrast, 2.1.1 Tastatur, 2.4.3 Fokusreihenfolge, 2.4.7 Fokus sichtbar, 2.4.11 Fokus nicht verdeckt, 2.5.7 Ziehbewegungen, 2.5.8 Zielgröße, 3.3.7 Redundante Eingabe sowie 4.1.2 Name, Rolle, Wert relevant. Der vollständige Kriterientext ist in der WCAG-2.2-Empfehlung des W3C veröffentlicht.
Bedeutet das Bestehen dieser Checkliste, dass eine Speisekarte rechtskonform ist?
Nein. Diese Checkliste ist ein technisches Prüfhilfsmittel auf Basis der WCAG-2.2-Erfolgskriterien, keine Rechtsauskunft. Rechtliche Anforderungen unterscheiden sich je nach Land und Betriebsart, weshalb Betreiber für verbindliche Aussagen qualifizierte Accessibility-Prüfer oder Rechtsberatung hinzuziehen sollten.
Worin unterscheidet sich das von der Barrierefreiheit eines Reservierungs-Widgets?
Diese Checkliste behandelt das Durchblättern der Speisekarte, Detailseiten von Gerichten, die Auswahl von Zusatzoptionen sowie Warenkorb- und Checkout-Schritte für Self-Service-Bestellungen. Datumsauswähler, Kalender-Widgets oder reservierungsspezifische Interaktionsmuster sind nicht Gegenstand dieses Dokuments und erfordern eigene WCAG-Betrachtungen.
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-02.