Accessibilité · architecture de l’information
Concevoir la navigation accessible d’un catalogue d’applications
Classer des services par besoins, rendre les états compréhensibles et construire une navigation utilisable au clavier, au tactile, au zoom et avec un lecteur d’écran.
Une taxonomie répond à une question
Un catalogue peut classer par marque, métier, public, tâche, disponibilité ou plateforme. Aucun classement n’est neutre : il facilite certaines recherches et en ralentit d’autres. Pour un portail grand public, l’entrée par besoin — organiser le foyer, préparer un déplacement, communiquer, comparer — est généralement plus compréhensible qu’un organigramme interne.
La fiche conserve ensuite le nom du produit, son statut et ses destinations. Une même application peut apparaître dans plusieurs parcours contextuels, mais une seule page canonique porte sa description complète. Les autres liens fournissent un contexte réel au lieu de dupliquer le texte.
Inventaire des tâches utilisateur
Commencez par relever les tâches : découvrir une solution, comprendre ses limites, lire un guide, essayer une démo, ouvrir une application, s’inscrire, installer ou demander de l’aide. Chaque tâche doit mener vers une destination exacte ou rester absente. Une navigation qui affiche tous les verbes par symétrie fabrique des attentes fausses.
Le tri par fréquence ne suffit pas : une tâche rare mais critique, comme retrouver la politique de confidentialité ou signaler une erreur, doit rester prévisible. Le test consiste à donner une intention à une personne sans lui apprendre la structure du portefeuille et à observer le chemin qu’elle choisit.
Hiérarchie et repères de page
Chaque page possède un titre principal unique, un fil d’Ariane lorsque la profondeur l’exige, un sommaire pour les dossiers longs et des titres qui décrivent le contenu suivant. Les cartes utilisent un lien principal explicite ; les actions secondaires sont distinguées. Le pied de page réunit gouvernance, correction, confidentialité et plan du site sans devenir une seconde navigation exhaustive.
Le focus clavier suit l’ordre visuel. Un menu mobile n’emprisonne pas le focus et annonce son état. Au zoom, les titres, tableaux et URL reviennent à la ligne sans créer de défilement horizontal global.
Rendre les statuts perceptibles
« Public », « Démo fictive », « Compte requis », « Installation Web » et « En cours de qualification » doivent être écrits en toutes lettres. Une couleur peut renforcer le repère mais ne le porte jamais seule. Le bouton reprend le verbe exact : lire, essayer, ouvrir, installer ou s’inscrire.
Une destination masquée n’est pas remplacée par un bouton désactivé sans explication. La fiche indique ce qui reste disponible — le guide, la démo ou le contact — et évite de promettre une date non confirmée.
| Libellé | Ce que le lecteur peut attendre | À ne pas déduire |
|---|---|---|
| Lire le guide | Contenu public autonome | Application disponible |
| Essayer la démo | Parcours fictif identifié | Compte ou données réelles |
| Ouvrir l’application | Service public à cette URL | Installation ou Store |
| Installer la PWA | Instructions Web qualifiées | Paquet natif |
| S’inscrire | Création de compte ouverte | Fédération obligatoire |
Clavier, tactile et lecteurs d’écran
Toutes les fonctions sont atteignables au clavier et présentent un focus visible non masqué. Les cibles rapprochées conservent une taille et un espacement suffisants. Un lecteur d’écran doit entendre le nom du produit, le statut et l’action sans dépendre d’un logo. Les images informatives reçoivent une alternative utile ; les décorations restent ignorées.
Sur mobile, la navigation primaire est courte. La liste complète des domaines appartient au hub, pas à un ruban horizontal. Les cartes ne contiennent pas plusieurs zones cliquables superposées, situation qui crée des destinations ambiguës au tactile et à la technologie d’assistance.
Recherche, filtres et absence de résultat
Une recherche tolère accents et variantes connues sans réécrire les noms officiels. Les filtres indiquent combien de résultats restent et peuvent être réinitialisés. Leur état n’est indexé que s’il correspond à une page éditoriale substantielle ; une combinaison personnalisée ne devient pas une page satellite.
L’absence de résultat explique le filtre actif et propose de revenir au catalogue complet. Elle ne transforme pas automatiquement une application éloignée en recommandation. Les requêtes ne doivent pas contenir de donnée personnelle ou métier sensible.
Tests avec des scénarios concrets
Les contrôles automatiques détectent titres absents, liens inatteignables, contrastes insuffisants ou débordement. Ils ne prouvent pas que la taxonomie est compréhensible. Ajoutez des scénarios : trouver une démo sans compte, distinguer site et application, retrouver une politique de confidentialité, identifier une capacité indisponible et revenir au hub.
Réalisez ces scénarios au clavier, sur écran étroit, avec zoom et, lorsque possible, avec un lecteur d’écran. Consignez l’obstacle observé, pas seulement un score global.
Checklist de publication
Une navigation accessible reste un travail de maintenance. Vérifiez à chaque nouvelle fiche ou nouveau CTA les éléments suivants.
- L’entrée correspond à un besoin réel.
- Le titre et le verbe d’action restent compréhensibles hors contexte.
- Statut et limite ne reposent pas sur la couleur.
- Le focus est visible et l’ordre cohérent.
- La cible tactile ne chevauche pas une autre action.
- Le zoom et les URL longues ne créent pas de débordement.
- Les filtres se réinitialisent et ne génèrent pas de pages minces.
- Le contact et la correction restent faciles à trouver.
Sources
- Web Content Accessibility Guidelines 2.2 · W3C · vérifié le 2026-09-09
- Web Application Manifest · W3C · vérifié le 2026-09-09
- RFC 3986 — Uniform Resource Identifier · RFC Editor / IETF · vérifié le 2026-09-09
- Minimiser les données collectées · CNIL · vérifié le 2026-09-09