← Blog Guides

Logiciel de navigation intérieure accessible : ADA, WCAG et orientation inclusive

Un adulte américain sur quatre vit avec un handicap, selon le CDC. Si votre système d'orientation ne fonctionne que pour les visiteurs valides et voyants qui lisent l'anglais, il exclut des millions de personnes — et peut violer la loi fédérale. La navigation intérieure accessible n'est pas facultative. C'est une exigence de conception. Voici comment bien faire, en complément de nos principes d'orientation inclusive.

Le paysage juridique et éthique

L'Americans with Disabilities Act (ADA) exige que les locaux ouverts au public et les installations commerciales soient accessibles aux personnes handicapées. Le Titre II couvre les entités gouvernementales ; le Titre III couvre les entreprises privées ouvertes au public — hôtels, hôpitaux, centres commerciaux, bureaux et lieux événementiels.

La mise à jour 2024 du Département de la Justice américain sur le Titre II de l'ADA a explicitement étendu les exigences d'accessibilité aux services web fournis par les gouvernements locaux et les États, en référençant WCAG 2.1 Niveau AA comme standard. Bien que le Titre III n'ait pas encore codifié un standard web spécifique, les tribunaux appliquent de plus en plus WCAG 2.1 AA aux services numériques du secteur privé.

Pour les logiciels d'orientation, cela signifie : si vous déployez un outil de navigation numérique dans un bâtiment ouvert au public, il doit répondre aux standards WCAG 2.1 AA. Un système d'orientation qui ne fonctionne que pour les utilisateurs valides et voyants crée une expérience à deux vitesses qui peut constituer une discrimination en vertu de la loi fédérale.

Les besoins d'accessibilité sont divers

L'« accessibilité » n'est pas une exigence unique — elle englobe un large éventail de besoins :

Handicaps moteurs : les utilisateurs de fauteuils roulants doivent connaître les rampes, ascenseurs, entrées accessibles et itinéraires sans obstacles. Un raccourci par un escalier n'est pas un itinéraire pour un utilisateur de fauteuil roulant.

Handicaps visuels : les utilisateurs aveugles et malvoyants ont besoin de compatibilité avec les lecteurs d'écran, d'un contraste de couleurs suffisant et d'indices de navigation non visuels. Une carte interactive qui repose entièrement sur le balayage visuel exclut ces utilisateurs.

Handicaps cognitifs : les utilisateurs avec des déficiences intellectuelles, une démence ou des lésions cérébrales traumatiques ont besoin d'interfaces simples avec un minimum de points de décision. Les structures de menus complexes et les processus à plusieurs étapes créent des barrières.

Handicaps auditifs : bien que l'orientation soit principalement visuelle, les annonces ou alertes audio ont besoin de sous-titres ou d'alternatives visuelles.

Le CDC rapporte que 26 % des adultes américains — 61 millions de personnes — ont une forme de handicap. Dans les établissements de santé, le pourcentage est significativement plus élevé. Concevoir pour l'accessibilité, c'est concevoir pour une part substantielle de vos visiteurs.

Exigences WCAG 2.1 AA pour l'orientation

WCAG 2.1 Niveau AA fournit des critères spécifiques et testables pertinents pour les logiciels d'orientation :

Perceptible : tout contenu doit avoir des alternatives textuelles. Les marqueurs de carte nécessitent du texte descriptif, pas seulement des icônes visuelles. La couleur ne doit pas être le seul moyen de transmettre l'information — si vous codez les zones par couleur, étiquetez-les également.

Utilisable : toutes les fonctionnalités doivent être accessibles au clavier. Les cibles tactiles doivent mesurer au moins 44x44 pixels CSS. Pas de limites de temps sur les interactions (une carte qui se ferme automatiquement après 30 secondes échoue à ce critère).

Compréhensible : la navigation doit être cohérente et prévisible. Les messages d'erreur doivent être clairs. La langue doit être déclarée pour que les lecteurs d'écran utilisent la bonne prononciation.

Robuste : le contenu doit fonctionner avec les technologies d'assistance actuelles et raisonnablement futures. Sémantique HTML appropriée, étiquettes ARIA et schémas d'interface standards.

QRCodeMaps délivre des cartes web à travers le navigateur natif du téléphone, ce qui signifie que les fonctionnalités d'accessibilité intégrées — VoiceOver, TalkBack, mise à l'échelle de l'affichage, modes haut contraste — fonctionnent automatiquement sans « version accessible » séparée.

Informations sur les itinéraires accessibles en fauteuil roulant

Pour les utilisateurs de fauteuils roulants et les visiteurs à mobilité réduite, savoir qu'une destination existe ne suffit pas — ils doivent savoir comment y accéder par un itinéraire accessible. Un marqueur pour « Salle de conférence B » qui n'est accessible que par des escaliers est inutile sans information sur l'alternative par ascenseur.

Incluez des détails d'accessibilité dans les descriptions des marqueurs : « Accessible par ascenseur depuis le hall principal » ou « Accès rampe depuis l'entrée sud ». Marquez les toilettes accessibles en fauteuil roulant séparément des toilettes standard. Notez les itinéraires sans marche là où ils diffèrent du chemin le plus court.

Pour les hôpitaux, où un pourcentage significatif de visiteurs a des handicaps moteurs (patients en fauteuil roulant, avec béquilles ou déambulateur), cette information est essentielle. Pour les universités, considérez que 19 % des étudiants de premier cycle déclarent avoir un handicap selon le National Center for Education Statistics.

Compatibilité lecteur d'écran et support aux malvoyants

Les visiteurs aveugles ou malvoyants s'appuient sur les lecteurs d'écran (VoiceOver sur iOS, TalkBack sur Android) pour interagir avec le contenu numérique. Un système d'orientation purement visuel — glisser une carte, localiser visuellement une épingle — est inaccessible à ces utilisateurs.

L'orientation web par QR code a un avantage ici. La page de carte chargée dans le navigateur peut inclure du HTML correctement structuré avec des étiquettes ARIA, des titres sémantiques et du texte alternatif descriptif. Les lecteurs d'écran peuvent annoncer les noms de marqueurs, les descriptions et les positions relatives.

La fonction de recherche est particulièrement importante pour les utilisateurs de lecteurs d'écran. Plutôt que de scanner visuellement une carte, un visiteur aveugle recherche « Radiologie » et entend le résultat : le nom du département, l'étage et toute description fournie. L'interaction de recherche est intrinsèquement accessible — c'est du texte en entrée, du texte en sortie.

Assurez un contraste de couleurs suffisant (ratio 4.5:1 pour le texte normal, 3:1 pour le texte large selon WCAG) et le support du zoom de texte au niveau du navigateur. De nombreux utilisateurs malvoyants augmentent la taille de texte de leur téléphone — une interface d'orientation qui se casse à un zoom de texte de 200 % ne respecte pas les exigences WCAG.

Accessibilité cognitive et conception simple

L'accessibilité cognitive est souvent négligée mais affecte une large population : personnes avec des déficiences intellectuelles, visiteurs âgés avec démence, enfants, et toute personne subissant du stress ou une surcharge cognitive (ce qui, comme le montre la recherche sur la psychologie de l'orientation, inclut la plupart des visiteurs occasionnels de bâtiments complexes).

Principes de conception pour l'accessibilité cognitive :

Minimiser les étapes. Scanner le QR code, voir la carte, rechercher la destination — trois étapes maximum. Pas d'écran de connexion, pas d'invites de permission, pas de tutoriel en superposition.

Utiliser un langage clair et simple. « Trouver une salle » et non « Naviguer vers la destination ». « Vous êtes ici » et non « Marqueur de position actuelle ».

Fournir une mise en page cohérente. La barre de recherche doit toujours être au même endroit. Les contrôles de carte doivent toujours fonctionner de la même manière. La prévisibilité réduit la charge cognitive.

Éviter la surcharge d'information. Montrer ce qui est pertinent, masquer ce qui ne l'est pas. Une carte avec 200 marqueurs visibles simultanément submerge. La divulgation progressive — montrer d'abord les marqueurs proches, révéler davantage au zoom — maintient l'interface gérable.

Tests et amélioration continue

L'accessibilité n'est pas une case à cocher ponctuelle — elle nécessite des tests avec de vrais utilisateurs et une attention continue.

Les outils de test automatisés (axe, Lighthouse, WAVE) détectent environ 30-40 % des problèmes WCAG — principalement les ratios de contraste, le texte alternatif manquant et les problèmes structurels. Les tests manuels avec un lecteur d'écran en détectent 30-40 % supplémentaires. Les problèmes restants ne sont trouvés que par des tests d'utilisabilité avec des personnes handicapées.

Si le budget le permet, recrutez 3-5 utilisateurs avec différents handicaps (un utilisateur de fauteuil roulant, un utilisateur de lecteur d'écran, un visiteur âgé) et observez-les utilisant votre système d'orientation. Les enseignements de 30 minutes d'observation dépassent ce que des mois de tests automatisés révèlent.

L'analytique QRCodeMaps peut aider ici aussi. Si vous voyez des recherches sans résultat ou des durées de session très courtes depuis certains emplacements de QR codes (par exemple, près des entrées accessibles), examinez si l'expérience échoue pour les visiteurs handicapés à ces emplacements.

Les améliorations d'accessibilité bénéficient à tous. Les abaissements de trottoir conçus pour les fauteuils roulants sont utilisés par les poussettes, les chariots de livraison et les valises. Une orientation claire et simple conçue pour l'accessibilité cognitive aide chaque visiteur stressé, pressé ou non familier à naviguer plus facilement.