Ja: WCAG 2.2 unterscheidet nicht zwischen gastseitigen und personalseitigen Oberflächen. Läuft ein Reservierungs-Dashboard oder ein Kassenterminal als Web- oder webbasierte Anwendung, gelten dieselben Erfolgskriterien für die Art, wie sie Informationen darstellen und Eingaben von Mitarbeitenden entgegennehmen. Die folgende Checkliste übersetzt zentrale WCAG-2.2-Kriterien – Tastaturbedienung, Farbkontrast, Fokus-Sichtbarkeit, Zielgrößen und Screenreader-Kompatibilität – in konkrete Prüfpunkte für interne Gastro-Software. Sie ersetzt keine vollständige Konformitätsprüfung, gibt Betreibern aber einen Ausgangspunkt, um zu erkennen, wo Kassenterminals und Buchungssysteme Mitarbeitende mit visuellen, motorischen oder kognitiven Einschränkungen ausschließen könnten.

Warum die Diskussion meist beim Gast aufhört

Barrierefreiheit in der Gastronomie wird meist im Kontext von Speisekarten, Online-Reservierungssystemen und Website-Buchungsflows diskutiert – also dort, wo Gäste direkt mit digitalen Angeboten interagieren. Das ist nachvollziehbar, weil dort die rechtlichen und geschäftlichen Erwartungen am sichtbarsten sind. Die Software, mit der Servicekräfte, Hostessen und Kassenpersonal während des laufenden Betriebs tatsächlich arbeiten, bleibt dabei häufig außen vor. Reservierungs-Dashboards und Point-of-Sale-Terminals sind Arbeitswerkzeuge, die unter Zeitdruck, bei wechselndem Licht und oft im Stehen bedient werden müssen – Bedingungen, unter denen unzureichende Kontraste, fehlende Tastaturpfade oder unklare Fehlermeldungen besonders stark ins Gewicht fallen.

Der Prüfrahmen: Staff Interface Accessibility Audit

Der hier vorgestellte Prüfrahmen – der Staff Interface Accessibility Audit – ordnet ausgewählte WCAG-2.2-Erfolgskriterien vier praxisnahen Prüfbereichen zu, die für Kassensysteme und Reservierungssoftware relevant sind. Er ist keine eigenständige Norm, sondern eine Anwendung der offiziellen W3C-Kriterien auf einen Software-Kontext, der in vielen Betrieben noch nicht systematisch geprüft wird.

Tastaturbedienung

Kriterien wie 2.1.1 (Keyboard) und 2.1.2 (No Keyboard Trap) verlangen, dass sich jede Funktion ohne Maus oder Touch bedienen lässt und der Fokus nicht in einem Element hängen bleibt. Für Kassensysteme heißt das: Kann ein Bestellvorgang, eine Stornierung oder ein Tischwechsel vollständig per Tastatur oder externem Eingabegerät ausgeführt werden? Die neuen Kriterien 2.4.11 und 2.4.12 (Focus Not Obscured) verlangen zusätzlich, dass der aktuell fokussierte Bedienpunkt nicht durch Pop-ups, Tastenfelder oder Zusatzleisten verdeckt wird – ein Problem, das bei kompakten POS-Bildschirmen häufig auftritt.

Farbkontrast und visuelle Klarheit

1.4.3 (Contrast Minimum) und 1.4.11 (Non-text Contrast) betreffen sowohl Text als auch Bedienelemente wie Rahmen, Icons und Statusanzeigen. Auf hell beleuchteten Küchendisplays oder in gedämmt beleuchteten Gastbereichen wirken sich niedrige Kontrastwerte unmittelbar auf die Lesbarkeit von Tischstatus, Bestellpositionen oder Preisänderungen aus. Das Kriterium 2.5.8 (Target Size Minimum) verlangt zudem eine Mindestgröße für interaktive Elemente, was bei dicht gepackten Kassen-Tastenfeldern oft ein reales Problem ist.

Screenreader- und Statusmeldungen

4.1.3 (Status Messages) verlangt, dass Statusänderungen – etwa eine bestätigte Reservierung, ein fehlgeschlagener Zahlungsvorgang oder eine aktualisierte Tischbelegung – auch ohne visuelle Wahrnehmung, etwa über einen Screenreader, angekündigt werden. Viele Dashboards zeigen solche Änderungen nur als kurze visuelle Einblendung, ohne dass sie programmatisch als Statusmeldung ausgezeichnet sind.

Kognitive Zugänglichkeit und Eingabefehler

Die in WCAG 2.2 neu hinzugekommenen Kriterien 3.3.7 (Redundant Entry) und 3.3.8 (Accessible Authentication Minimum) reduzieren unnötige Wiederholungseingaben und komplexe Anmeldeverfahren. In einem Schichtbetrieb, in dem sich Mitarbeitende mehrfach am Tag an einem Terminal anmelden, wirkt sich das direkt auf kognitive Belastung und Fehleranfälligkeit aus.

WCAG-2.2-KriteriumTypischer Anwendungsfall in POS/DashboardPrüffrage
2.1.1 / 2.1.2 TastaturBestellung, Stornierung, TischverwaltungIst jede Funktion ohne Zeigegerät erreichbar und verlässt der Fokus jedes Element wieder?
2.4.11 / 2.4.12 Fokus nicht verdeck

Vom Kriterium zur Prüfpraxis: Ablauf eines internen Audits

Die Zuordnung von WCAG-2.2-Kriterien zu Prüffragen ist nur der erste Schritt. Ohne einen klaren Ablauf bleibt ein solcher Kriterienkatalog eine Liste guter Absichten. Der folgende Ablauf beschreibt, wie ein Betrieb den Staff Interface Accessibility Audit tatsächlich durchführen kann, ohne externe Prüfstelle und ohne Annahme, dass ein einzelner Testlauf eine dauerhafte Konformität belegt.

  1. Inventar erstellen: Alle internen Tools auflisten, die während einer Schicht genutzt werden – Kassenterminal, Reservierungs-Dashboard, Küchenmonitor, Zeiterfassung. Für jedes Tool klären, ob es sich um eine Webanwendung, eine webbasierte Kiosk-Oberfläche oder eine native App handelt, da dies bestimmt, ob WCAG 2.2 direkt anwendbar ist oder nur sinngemäß als Orientierung dient.
  2. Kernworkflows definieren: Statt die gesamte Oberfläche zu prüfen, konkrete Abläufe auswählen, die im Service tatsächlich unter Zeitdruck ausgeführt werden – etwa „Reservierung anlegen“, „Zahlung stornieren“, „Tisch zusammenlegen“.
  3. Testmethoden kombinieren: Automatisierte Prüfwerkzeuge erkennen nur einen Teil der Kriterien (etwa Farbkontrast), während Tastaturbedienung, Fokusreihenfolge und Statusmeldungen manuell durchgespielt werden müssen, idealerweise mit angeschlossener Tastatur oder Screenreader statt nur mit der Maus.
  4. Ergebnis pro Kriterium festhalten: Für jeden geprüften Workflow dokumentieren, ob ein Kriterium erfüllt, teilweise erfüllt oder nicht erfüllt ist, statt nur eine Gesamteinschätzung „barrierefrei“ oder „nicht barrierefrei“ zu vergeben.
  5. Nach Software-Updates erneut prüfen: Da POS- und Reservierungssysteme regelmäßig aktualisiert werden, sollte der Audit nicht als einmaliges Projekt, sondern als wiederkehrender Prüfpunkt bei jedem größeren Update behandelt werden.

Randfälle, die Standard-Audits oft übersehen

Bedienung mit Handschuhen oder eingeschränkter Fingerfertigkeit

Kriterium 2.5.8 (Target Size Minimum) legt eine Mindestgröße für interaktive Elemente fest, doch reale Bediensituationen in der Küche – etwa mit Einweghandschuhen oder feuchten Händen – erhöhen die faktisch benötigte Zielgröße zusätzlich. Ein Audit sollte deshalb nicht nur prüfen, ob das Kriterium formal erfüllt ist, sondern ob Bedienelemente unter realen Servicebedingungen tatsächlich zuverlässig getroffen werden können.

Wechselnde Lichtverhältnisse zwischen Küche und Gastraum

Die in der bestehenden Checkliste genannten Kontrastkriterien 1.4.3 und 1.4.11 werden häufig unter Laborbedingungen mit neutraler Bildschirmbeleuchtung geprüft. Ein vollständigerer Test berücksichtigt zusätzlich die tatsächlichen Lichtverhältnisse am Terminal-Standort – grelles Küchenlicht, gedimmtes Restaurantlicht oder Reflexionen auf Touchscreens – auch wenn WCAG 2.2 selbst keine Umgebungsbeleuchtung vorschreibt.

Vorübergehende Einschränkungen im Schichtbetrieb

Nicht nur dauerhafte Behinderungen sind relevant: eine verletzte Hand, ein lauter Gastraum, der akustische Signale übertönt, oder Ermüdung nach einer langen Schicht wirken sich ähnlich aus wie motorische oder sensorische Einschränkungen. Statusmeldungen nach 4.1.3, die ausschließlich visuell und ohne programmatische Auszeichnung erfolgen, betreffen damit potenziell einen größeren Teil der Belegschaft als nur Mitarbeitende mit dauerhafter Sehbeeinträchtigung.

Software von Drittanbietern ohne Quellcode-Zugriff

Viele Betriebe nutzen POS- oder Reservierungssysteme, deren Quellcode sie nicht kontrollieren. In diesem Fall kann ein interner Audit die Kriterien prüfen und dokumentieren, aber keine Behebung erzwingen. Sinnvoll ist es, geprüfte Abweichungen als konkrete Anfrage an den Softwareanbieter zu formulieren, statt sie unkommentiert zu lassen.

Mehrsprachige und rotierende Teams

Kriterien wie 3.3.7 (Redundant Entry) und 3.3.8 (Accessible Authentication Minimum) wirken sich besonders in Betrieben mit häufig wechselndem oder mehrsprachigem Personal aus, da wiederholte oder komplexe Eingaben zusätzliche kognitive Last erzeugen. Ein Audit sollte deshalb auch prüfen, ob Anmelde- und Wiederholungsschritte über verschiedene Rollen und Schichtmuster hinweg konsistent gehalten werden.

Messung und Dokumentation ohne erfundene Kennzahlen

Ein Staff Interface Accessibility Audit liefert keine Prozentzahlen zu Nutzerzufriedenheit oder Fehlerreduktion, da solche Werte ohne belastbare Erhebung nicht seriös angegeben werden können. Stattdessen empfiehlt sich eine kriterienbasierte Dokumentation, die über Zeit vergleichbar bleibt.

WorkflowGeprüftes KriteriumStatusNächster Schritt
Reservierung anlegen2.1.1 TastaturTeilweise erfülltRückmeldung an Softwareanbieter
Zahlung stornieren4.1.3 StatusmeldungenNicht erfülltErneute Prüfung nach Update
Tisch zusammenlegen2.5.8 ZielgrößeErfülltKeine weitere Maßnahme

Diese Form der Dokumentation macht sichtbar, welche Workflows und Kriterien bereits geprüft wurden und welche nicht – ohne den Eindruck einer abschließenden, zertifizierten Konformitätsaussage zu erwecken.

Grenzen dieses Prüfrahmens

WCAG 2.2 wurde für Web-Inhalte formuliert; native, nicht webbasierte Kassenanwendungen fallen unter Umständen nicht direkt in ihren formalen Anwendungsbereich, auch wenn sich die zugrunde liegenden Prinzipien – Tastaturzugang, Kontrast, verständliche Statusmeldungen – sinngemäß übertragen lassen. Ein interner Audit durch das eigene Team ersetzt zudem keine unabhängige oder rechtlich verbindliche Konformitätsprüfung; er dient der frühzeitigen Erkennung offensichtlicher Hürden, nicht dem Nachweis einer bestimmten Konformitätsstufe. Ergebnisse hängen außerdem stark davon ab, wer testet und mit welchem Hilfsmittel: Ein Audit ohne Beteiligung von Mitarbeitenden, die tatsächlich mit visuellen, motorischen oder kognitiven Einschränkungen arbeiten, bleibt notwendigerweise unvollständig. Schließlich ist jede Prüfung nur so aktuell wie der zuletzt getestete Softwarestand – nachfolgende Updates können neue Barrieren einführen, die erst im nächsten Auditzyklus auffallen.

Primärquellen

FAQ

Gilt WCAG 2.2 auch für interne Personal-Software, nicht nur für gastseitige Websites?

Ja. WCAG 2.2 ist allgemein für Webinhalte formuliert und unterscheidet nicht zwischen gastseitigen und personalseitigen Oberflächen. Läuft ein Reservierungs-Dashboard oder ein Kassenterminal als Web- oder webbasierte Anwendung, gelten dieselben Erfolgskriterien für Darstellung und Eingabe.

Erfassen automatisierte Barrierefreiheits-Scanner alle Punkte dieser Checkliste?

Nein. Automatisierte Tools können bestimmte Probleme wie fehlende Textalternativen oder zu geringe Kontrastwerte erkennen. Viele WCAG-2.2-Kriterien, etwa Tastaturbedienbarkeit oder die Ansage dynamischer Inhalte durch Screenreader, lassen sich nur durch manuelle Tests mit tatsächlicher assistiver Technologie prüfen.

Reicht die Konformitätsstufe AA aus, um sicherzustellen, dass ein Personal-Tool nutzbar ist?

Konformität auf Stufe AA deckt einen breiten, häufig referenzierten Satz an Barrieren ab, ist aber ein technischer Konformitätsstandard und keine Nutzbarkeitsgarantie für jede Person oder jede Einschränkung. Betriebe sollten AA als Grundlage betrachten und sie mit direkten Tests durch oder mit Mitarbeitenden ergänzen, die assistive Technologie nutzen.

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-11.