Sprachzugängliches Menü für Sehbehinderte Gäste mit WCAG 2.2 AA

Ein 12-Tische-Teegarten in Istanbul Kadıköy gewann nach dem Wechsel auf ein VoiceOver/TalkBack-fähiges QR-Menü 240 neue Gäste pro Monat. Barrierefreiheit ist kein Luxus, sondern direkter Umsatztreiber.

WCAG 2.2 AA Grundlagen

Screenreader benötigen semantisches HTML: Produktnamen als h3, Preise mit aria-describedby, Allergen-Icons mit aria-label="enthält Gluten". Mindestkontrast 4.5:1, Touch-Ziele 44×44 px, logische Tab-Reihenfolge.

Emojis allein reichen nicht — sehende Gäste sehen das Weizen-Symbol, blinde hören nichts ohne ARIA-Label.

ARIA Live Regions für Warenkorb

Bei Hinzufügen eines Artikels meldet eine role="status"- oder aria-live="polite"-Region: "Linsensuppe hinzugefügt, 3 Artikel insgesamt." Fehler bekommen role="alert".

thMenus ToastProvider nutzt standardmäßig aria-live="polite". Das Allergen-Leerzustands-Fallback "Bitte fragen Sie das Servicepersonal" ist Pflicht.

Test vor dem Launch

Aktivieren Sie VoiceOver (iPhone) oder TalkBack (Android) und navigieren Sie den kompletten Bestellfluss. Pausen über 1 Sekunde deuten auf Fokus-Probleme. Axe DevTools oder WAVE finden 80% der Verstöße in 30 Sekunden.

Lassen Sie zusätzlich eine sehbehinderte Person testen — automatische Tools erfassen den Kontext nicht.

FAQ

Brauche ich eine separate Audio-Version? Nein, korrektes HTML dient beiden Nutzergruppen gleichzeitig.

Eigene TTS einbauen? Nicht nötig, OS-Screenreader übernimmt das.

WCAG-Zertifikat möglich? Offizielles Zertifikat existiert nicht; VPAT-Bericht ist Standard.

Hilfreich? Teilen Sie es.