Comment créer un menu vocal accessible pour les clients malvoyants

Un salon de thé de 12 tables à Kadıköy, Istanbul, a gagné 240 nouveaux visiteurs mensuels après être passé à un menu QR compatible VoiceOver/TalkBack, partagé par l'Association turque des aveugles. L'accessibilité vocale n'est plus optionnelle.

Fondamentaux WCAG 2.2 AA

Les lecteurs d'écran exigent du HTML sémantique : noms de produits en h3, prix liés via aria-describedby, icônes allergènes avec aria-label="contient du gluten". Contraste minimum 4.5:1, cibles tactiles 44×44 px, ordre de tabulation logique.

Les emojis seuls ne suffisent pas : l'utilisateur voyant voit l'icône, l'aveugle n'entend rien sans étiquette ARIA.

ARIA Live pour le panier

À l'ajout d'un article, une zone role="status" ou aria-live="polite" annonce : « Soupe de lentilles ajoutée, 3 articles au total ». Les erreurs utilisent role="alert" pour interrompre immédiatement.

Le ToastProvider de thMenu est aria-live="polite" par défaut. Le message de repli « Veuillez consulter le serveur » sécurise les choix.

Tests avant lancement

Activez VoiceOver (iPhone) ou TalkBack (Android) et naviguez tout le parcours. Un silence de plus d'une seconde indique un problème de focus. Axe DevTools ou WAVE détectent l'essentiel en 30 secondes.

Testez avec une vraie personne malvoyante : les outils automatiques manquent le contexte d'usage.

FAQ

Faut-il une version audio séparée ? Non, un bon HTML sémantique sert tout le monde.

Dois-je ajouter ma propre synthèse vocale ? Non, le lecteur d'écran du système suffit.

Peut-on obtenir une certification WCAG ? Pas officiellement ; un rapport VPAT est l'équivalent.

Cet article vous a été utile ? Partagez-le.