Le menu de navigation à tiroir, souvent appelé menu off-canvas, s’est largement imposé sur les sites WordPress destinés au mobile : une icône « hamburger » ouvre un panneau qui glisse depuis le bord de l’écran, recouvrant tout ou partie du contenu principal. Ce composant, séduisant visuellement, cumule pourtant plusieurs pièges d’accessibilité classiques que nous retrouvons régulièrement lors de nos audits.
Voici la check-list de neuf points que notre équipe applique systématiquement avant de considérer un menu off-canvas comme prêt à livrer, avec le raisonnement derrière chaque vérification.
Les neuf points de contrôle
- Le bouton d’ouverture est-il un vrai
<button>, et non un<a href="#">ou un<div>? - Ce bouton porte-t-il un texte accessible clair, comme « Ouvrir le menu de navigation », plutôt qu’un simple pictogramme sans nom ?
- L’attribut
aria-expandeddu bouton passe-t-il bien defalseàtrueà l’ouverture ? - Le tiroir porte-t-il
aria-hidden="true"tant qu’il reste fermé, pour éviter qu’un lecteur d’écran ne parcoure son contenu invisible ? - Le focus est-il déplacé automatiquement vers le premier élément du tiroir à son ouverture ?
- Le focus reste-t-il piégé à l’intérieur du tiroir tant qu’il est ouvert, sans possibilité d’atteindre le contenu masqué en arrière-plan via Tab ?
- La touche Échap ferme-t-elle le tiroir et restaure-t-elle le focus sur le bouton d’ouverture ?
- Le défilement de la page en arrière-plan est-il bloqué tant que le tiroir reste ouvert ?
- Un clic ou un appui en dehors du tiroir referme-t-il celui-ci sans provoquer d’action indésirable sur le contenu masqué ?

Le point le plus souvent oublié : le blocage du défilement
Sur les neuf points de cette liste, celui du blocage du défilement en arrière-plan revient le plus fréquemment absent lors de nos audits initiaux. Sans cette précaution, un utilisateur de lecteur d’écran qui active un geste de défilement continue de faire défiler le contenu masqué visuellement derrière le tiroir, ce qui désynchronise complètement sa position de lecture par rapport à ce qui est réellement affiché à l’écran.
function ouvrirTiroir() {
document.body.classList.add('tiroir-ouvert');
document.body.style.overflow = 'hidden';
tiroir.setAttribute('aria-hidden', 'false');
boutonOuverture.setAttribute('aria-expanded', 'true');
premierLienTiroir.focus();
}
function fermerTiroir() {
document.body.classList.remove('tiroir-ouvert');
document.body.style.overflow = '';
tiroir.setAttribute('aria-hidden', 'true');
boutonOuverture.setAttribute('aria-expanded', 'false');
boutonOuverture.focus();
}
Un cas particulier : le tiroir contenant lui-même un sous-menu
Sur un site e-commerce récent, le tiroir contenait un menu à deux niveaux, avec des catégories dépliables à l’intérieur même du panneau. Ce cas ajoute une couche de complexité : chaque bouton de catégorie à l’intérieur du tiroir doit lui-même porter son propre aria-expanded, indépendant de celui du bouton principal d’ouverture du tiroir, et le piège de focus global doit continuer à englober ces sous-niveaux sans laisser d’échappatoire vers l’arrière-plan.
Vérification finale avec les technologies d’assistance
Une fois les neuf points cochés sur le code, nous rejouons systématiquement le scénario complet avec NVDA et VoiceOver : ouverture du tiroir au clavier, parcours des liens à l’intérieur, tentative volontaire de sortir du tiroir avec Tab pour confirmer que le piège de focus fonctionne, puis fermeture avec Échap et vérification que le focus revient précisément sur le bouton d’ouverture, jamais ailleurs sur la page.
- Ouverture et annonce correcte du bouton par le lecteur d’écran
- Focus initial positionné sur le premier lien du menu
- Impossibilité d’atteindre le contenu masqué en arrière-plan pendant l’ouverture
- Fermeture propre avec restauration du focus au point de départ
Un menu off-canvas mal construit ne se contente pas d’être inaccessible : il devient activement trompeur, en laissant croire à un utilisateur qu’il navigue dans le tiroir alors qu’il agit en réalité sur le contenu masqué derrière.
En résumé
Cette check-list de neuf points, appliquée systématiquement, nous a permis d’éviter la quasi-totalité des retours clients liés à ce composant depuis sa mise en place. Le menu off-canvas reste un choix de conception tout à fait viable pour l’accessibilité, à condition de traiter chacun de ces neuf points comme une exigence de livraison, au même titre que le rendu visuel sur les différentes tailles d’écran.