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-KriteriumKonkreter TestBestanden, wenn
1.1.1 Nicht-Text-InhalteAlt-Text jedes Gerichtsfotos per Screenreader vorlesen lassenBeschreibung ist inhaltlich sinnvoll, kein Platzhaltertext
1.4.3 / 1.4.11 KontrastKontrastverhältnis mit einem Prüfwerkzeug messenText ≥ 4,5:1, grafische Elemente ≥ 3:1
2.1.1 TastaturGesamte Bestellstrecke nur mit Tab, Enter, Pfeiltasten durchlaufenKeine Funktion erfordert Maus oder Touch
2.4.3 FokusreihenfolgeTab-Reihenfolge mit visueller Lesereihenfolge vergleichenFokus folgt logisch der Seitenstruktur
2.4.7 Fokus sichtbarFokusrahmen bei jedem interaktiven Element prüfenFokus ist deutlich erkennbar, nicht durch CSS entfernt
2.4.11 Fokus nicht verdecktFokussiertes Element bei aktivem Sticky-Header prüfenElement bleibt vollständig sichtbar
2.5.7 ZiehbewegungenSchieberegler-Funktionen ohne Ziehen testenGleichwertige Alternative ohne Drag vorhanden
2.5.8 ZielgrößeTouch-Ziele mit Lineal oder Dev-Tools messenZielgröße entspricht dem Kriterium, oder Ausnahme greift nachweislich
3.3.7 Redundante EingabeMehrstufigen Checkout durchlaufen und Wiederholungen prüfenBereits erfasste Daten werden vorausgefüllt oder nicht erneut verlangt
4.1.2 Name, Rolle, WertButtons und Formularfelder mit Screenreader prüfenName, Rolle und Zustand werden korrekt angesagt

Messung: Wie eine Prüfrunde konkret abläuft

  1. Automatisierte Vorprüfung mit einem etablierten Accessibility-Scanner durchführen, um offensichtliche Kontrast- und Auszeichnungsfehler zu identifizieren.
  2. Manuellen Tastatur-Durchlauf der gesamten Bestellstrecke protokollieren: jede Station aus der Checkliste einzeln abhaken.
  3. Screenreader-Test mit mindestens einem gängigen Screenreader auf Desktop und einem auf Mobilgerät durchführen, da sich Ansageverhalten unterscheiden kann.
  4. Ergebnisse pro Kriterium als Bestanden/Nicht bestanden mit Bildschirmfoto oder Aufzeichnung dokumentieren, nicht nur als Gesamteindruck.
  5. 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.

    SchweregradBeispielEmpfohlene Reaktion
    BlockierendCheckout per Tastatur nicht abschließbar (2.1.1)Vor Veröffentlichung beheben, kein Livegang mit offenem Blocker
    Erheblich einschränkendFokus nach Warenkorb-Update springt an unerwartete Stelle (2.4.3)Zeitnah beheben, im nächsten Release-Zyklus
    Teilweise einschränkendGrafisches Allergen-Icon unter 3:1 Kontrast (1.4.11)Im laufenden Wartungsplan einplanen
    GeringAlt-Text vorhanden, aber knapp formuliertBei 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:

    1. Einführung neuer Zusatzoptionstypen, etwa Schieberegler oder Drag-Elemente, die zuvor nicht existierten.
    2. Wechsel des Bestell- oder Zahlungsanbieters, da eingebettete Komponenten eigene Konformitätsstände haben können.
    3. Strukturelle Änderungen an der Fokusreihenfolge, etwa durch ein neues Layout des Warenkorbs.
    4. 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.