WCAG-2.2-Prüfliste für Navigation und Suche auf Restaurant-Websites

Warum Navigation und Suche eine eigene Prüfung verdienen

Viele Zugänglichkeitsprüfungen für Restaurant-Websites konzentrieren sich auf Bestellformulare oder Reservierungswidgets, weil dort der unmittelbare Umsatz entsteht. Hauptmenü, Footer-Links und die interne Suchfunktion sind jedoch die Oberflächen, die Besucherinnen und Besucher zuerst nutzen, oft bevor sie überhaupt eine Speisekarte oder ein Buchungsformular erreichen. Wenn diese vorgeschalteten Elemente nicht per Tastatur bedienbar sind, kommt es nie so weit, dass eine Bestell- oder Buchungsstrecke überhaupt getestet werden kann. WCAG 2.2 selbst unterscheidet nicht zwischen "wichtigen" und "weniger wichtigen" Interaktionselementen; die Kriterien gelten gleichermaßen für ein Dropdown-Menü im Header wie für ein Datumsfeld im Reservierungsformular.

Der KFE-Prüfrahmen: Keyboard, Focus, Error

Für die praktische Durchführung eignet sich ein dreiteiliger Rahmen, den wir hier als KFE-Prüfrahmen bezeichnen: Keyboard (Tastaturbedienbarkeit), Focus (Fokusreihenfolge und -sichtbarkeit) und Error (Fehlerkennung bei der Suche). Jede der drei Spuren lässt sich unabhängig von den anderen prüfen und dokumentieren.

Spur 1: Tastaturbedienbarkeit (WCAG 2.1.1, 2.1.2)

Ziehen Sie die Maus ab oder legen Sie sie bewusst nicht an. Bewegen Sie sich ausschließlich mit Tab, Shift+Tab, Enter, Leertaste und den Pfeiltasten durch die Seite.

• Lässt sich jeder Menüpunkt im Hauptmenü per Tab erreichen, inklusive Untermenüs?
• Öffnen sich Dropdown- oder Flyout-Menüs auch ohne Hover, also allein durch Tastaturfokus?
• Lassen sich alle Footer-Links erreichen, ohne dass der Fokus in einer Wiederholungsschleife oder einem Widget "gefangen" bleibt (Tastaturfalle)?
• Kann das Suchfeld fokussiert, ein Suchbegriff eingegeben und die Suche per Enter ausgelöst werden?

Spur 2: Fokusreihenfolge und -sichtbarkeit (WCAG 2.4.3, 2.4.7, 2.4.11)

Die Reihenfolge, in der der Fokus durch die Seite wandert, sollte der visuellen und logischen Struktur entsprechen, nicht der zufälligen Reihenfolge im Quellcode.

• Springt der Fokus von links oben nach rechts unten in einer für Sehende nachvollziehbaren Reihenfolge, oder springt er unerwartet zwischen Header, Hauptinhalt und Footer hin und her?
• Ist an jeder Stelle sichtbar, welches Element aktuell den Fokus hat (sichtbarer Fokusring oder vergleichbare Kennzeichnung)?
• Wird das fokussierte Element von anderen Inhalten wie Cookie-Bannern, Sticky-Headern oder Chat-Widgets verdeckt?

Spur 3: Fehlerkennung bei der Suche (WCAG 3.3.1)

Geben Sie bewusst einen Suchbegriff ein, der keine Treffer liefert, oder lassen Sie das Suchfeld leer und lösen die Suche aus.

• Erscheint eine Rückmeldung, dass keine Ergebnisse gefunden wurden, oder wirkt die Seite einfach unverändert oder leer?
• Wird die Fehlermeldung als Text ausgegeben, der auch mit einem Screenreader wahrnehmbar ist, oder nur als visuelle Änderung?
• Enthält die Meldung einen verständlichen Hinweis, etwa einen Vorschlag zur Rechtschreibung oder alternative Suchbegriffe, sofern die Website solche Hinweise überhaupt anbietet?

Ablauf einer Prüfsitzung

1. Startpunkt festlegen: Laden Sie die Startseite neu und setzen Sie den Fokus manuell auf den Anfang der Seite (meist per Tab von der Adressleiste aus).
2. Hauptnavigation vollständig durchtaben, jeden Menüpunkt und jedes Untermenü dokumentieren, das nicht erreichbar oder nicht aktivierbar ist.
3. Zur Suchleiste tabben, einen Testbegriff mit Treffern eingeben, dann einen Testbegriff ohne Treffer eingeben und jeweils die Rückmeldung protokollieren.
4. Zum Footer weiterrollen und durchtaben, insbesondere Links zu Impressum, Öffnungszeiten, Kontakt und Social-Media-Icons.
5. Bei jedem Element prüfen, ob ein sichtbarer Fokusindikator erscheint, und Screenshots oder kurze Bildschirmaufnahmen als Beleg speichern.
6. Ergebnisse pro Kriterium (Keyboard, Focus, Error) in einer einfachen Tabelle mit Bestehen/Nicht bestehen und Anmerkung festhalten.

Zuordnung von Prüfschritt zu Erfolgskriterium

Grenzen dieser Methode

Diese Prüfliste ersetzt keine vollständige Konformitätsbewertung. Automatisierte Scanner erkennen zuverlässig strukturelle Probleme wie fehlende Fokus-Styles im CSS oder identischen Linktext, sie können aber nicht beurteilen, ob eine Fokusreihenfolge für eine tatsächliche Nutzerin sinnvoll ist oder ob eine Fehlermeldung inhaltlich verständlich ist. Ebenso deckt manuelles Tastaturtesten nicht automatisch Probleme ab, die nur mit einem Screenreader auffallen, etwa fehlende ARIA-Labels b

Zusätzliche Randfälle, die im Grundprüfrahmen leicht übersehen werden

Der KFE-Prüfrahmen deckt die drei Kernfragen ab, stößt aber bei bestimmten Navigationsmustern an seine Grenzen. Diese Randfälle sollten separat vermerkt werden, weil sie häufig erst bei genauerem Hinsehen auffallen.

• Mehrstufige Flyout-Menüs: Wenn ein Hauptmenüpunkt ein Untermenü mit weiteren Ebenen öffnet, prüfen Sie, ob sich jede Ebene einzeln per Tab betreten und mit Escape oder Shift+Tab wieder verlassen lässt, ohne dass der Fokus in der untersten Ebene verschwindet.
• Mobile Hamburger-Navigation: Der Umschalt-Button für das mobile Menü muss selbst per Tastatur fokussierbar und mit Enter oder Leertaste aktivierbar sein; nach dem Öffnen muss der Fokus in das aufklappende Menü wandern oder zumindest dort verbleiben können.
• Autovervollständigung in der Suche: Erscheinen Vorschläge während der Eingabe, testen Sie, ob sich diese Vorschlagsliste mit den Pfeiltasten durchgehen und mit Enter auswählen lässt, ohne dass der Fokus unkontrolliert zurück ins Eingabefeld oder auf die Seite springt.
• Cookie-Banner und Overlays: Prüfen Sie gezielt, ob ein beim Laden erscheinender Consent-Banner den Fokus abfängt (Fokus-Trap) und ob nach dem Schließen der Fokus an eine sinnvolle Stelle zurückkehrt statt an den Seitenanfang oder ins Leere.
• Eingebettete Drittanbieter-Widgets im Footer: Reservierungs- oder Kartenwidgets, die per iframe eingebunden sind, können eigene Tastaturlogiken mitbringen. Dokumentieren Sie solche Widgets separat, da sie unter Umständen nicht der Kontrolle der Website selbst unterliegen.

Sprung- und Hilfelinks als eigene Prüfpunkte

Zwei Kriterien aus WCAG 2.2, die im ursprünglichen Prüfrahmen nicht explizit auftauchen, betreffen speziell Navigation und wiederkehrende Hilfsangebote:

• Bypass Blocks (2.4.1): Testen Sie, ob ein "Zum Inhalt springen"-Link vorhanden ist und ob er beim ersten Tab-Druck nach dem Laden der Seite sichtbar erscheint und tatsächlich zum Hauptinhalt springt, statt lediglich einen Anker ohne Fokuswechsel zu setzen.
• Consistent Help (3.2.6): Falls Header oder Footer einen Kontakt-, Hilfe- oder Chat-Link enthalten, prüfen Sie auf mehreren Unterseiten, ob dieser Link an einer relativ konsistenten Position innerhalb der Navigationsreihenfolge steht, statt auf jeder Seite an anderer Stelle zu erscheinen.

Zielgrößen für Footer-Icons und Such-Buttons

Für kleine interaktive Elemente wie Social-Media-Icons im Footer oder das Lupensymbol eines Such-Buttons ist zusätzlich die Zielgröße relevant. Prüfen Sie mit den Entwicklerwerkzeugen des Browsers die gerenderte Klickfläche und vermerken Sie, ob sie deutlich kleiner ausfällt als vergleichbare Elemente auf derselben Seite. Ist die Fläche sehr klein und liegen keine ausreichenden Abstände zu benachbarten Elementen vor, sollte dies als eigener Befund unter dem Kriterium für Zielgrößen dokumentiert werden.

Messung, Dokumentation und Wiederholprüfung

Damit die Prüfung über die Zeit vergleichbar bleibt, empfiehlt sich eine feste Bewertungsskala statt einer reinen Ja/Nein-Angabe.

1. Legen Sie pro Befund einen Schweregrad fest, etwa: Blockierend (Bedienung insgesamt unmöglich), Wesentlich (Bedienung stark erschwert, aber mit Mehraufwand möglich), Gering (störend, aber Ziel erreichbar).
2. Notieren Sie zu jedem Befund Browser, Betriebssystem und verwendete Eingabemethode, da sich Tastaturverhalten zwischen Browsern unterscheiden kann.
3. Testen Sie dieselbe Navigation und Suche in mindestens zwei unterschiedlichen Browser-Kombinationen, bevor Sie einen Befund als generelles Problem einstufen.
4. Wiederholen Sie die Prüfung nach jeder Änderung an Menüstruktur, Footer-Inhalten, Suchfunktion oder nach Aktualisierung eines Navigationsplugins.

Beispielhafte Dokumentationstabelle

Weitere Grenzen dieser Vorgehensweise

Diese Checkliste bleibt eine manuelle, stichprobenhafte Prüfung durch eine sehende Person mit Tastatur und ist kein Ersatz für Tests mit tatsächlichen Screenreader-Nutzenden oder für automatisierte Konformitätsprüfungen. Touch- und Wischgesten auf mobilen Geräten werden hier nicht erfasst, ebenso wenig wie die inhaltliche Verständlichkeit von Texten jenseits der reinen Fehlerkennung. Für eine rechtlich belastbare Konformitätsaussage ist der vollständige normative Text der WCAG 2.2 heranzuziehen; diese Checkliste dient ausschließlich als operative Ausgangsprüfung für Navigation, Footer und interne Suche.

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