Applications React, Vue et Angular : les points durs
Une application monopage remplace la navigation du navigateur par une navigation programmée. Tout ce que le navigateur faisait gratuitement — déplacer le focus, annoncer le titre de la page, gérer l'historique — devient à votre charge. C'est de là que viennent la quasi-totalité des non-conformités spécifiques à ces architectures.
Le changement de route
Lors d'une navigation classique, le navigateur annonce le nouveau titre et replace le focus en début de document. Dans une application monopage, rien de tout cela ne se produit : l'utilisateur de lecteur d'écran clique sur un lien, et rien n'est annoncé.
Trois corrections à appliquer ensemble : mettre à jour le titre du document, déplacer le focus vers le titre principal de la nouvelle vue, et annoncer le changement dans une région dédiée.
Les contenus qui changent sans navigation
Résultats filtrés, chargement à la demande, validation en direct, notifications. Tous doivent être annoncés sans voler le focus à l'utilisateur, via une région de statut. La règle pratique : une région de statut doit exister dans le document au chargement, pas être créée au moment du message — sinon rien n'est restitué.
Les composants maison
| Approche | Accessibilité | Coût |
|---|---|---|
| Élément natif du langage | Acquise, y compris au clavier et au lecteur d'écran | Nul |
| Bibliothèque de composants accessibles | Prise en charge, à vérifier | Faible |
| Composant maison | Entièrement à votre charge : rôle, états, clavier, focus | Élevé, et récurrent |
La première règle reste la moins coûteuse : utiliser l'élément natif chaque fois qu'il existe. Voir ARIA : quand l'utiliser, quand s'en passer.
La gestion du focus
- Ouverture d'une modale — le focus entre dedans et y reste tant qu'elle est ouverte.
- Fermeture — le focus revient sur l'élément qui l'avait ouverte, jamais en haut de page.
- Suppression d'un élément — le focus est replacé sciemment, sinon il retombe sur le document et l'utilisateur est perdu.
- Chargement asynchrone — le focus ne bouge pas tout seul.
Le rendu côté serveur
Une application dont le contenu n'existe qu'après exécution du JavaScript pose un double problème : de robustesse au sens du référentiel, et d'exploitation par les robots d'indexation comme par les moteurs de réponse. Le rendu côté serveur ou la prégénération traitent les deux d'un coup.
C'est l'un des rares points où l'argument d'accessibilité et l'argument de visibilité se confondent exactement — voir accessibilité et SEO.
Comment tester
- Parcourir l'application au clavier seul, en changeant plusieurs fois de vue.
- Refaire le même parcours au lecteur d'écran, en vérifiant que chaque changement est annoncé.
- Brancher des tests automatisés sur les parcours critiques — voir axe DevTools.
- Vérifier le rendu sans JavaScript, ou la présence d'un rendu serveur.
Poursuivre
Pour le cas des constructeurs de pages, voyez l'accessibilité et Elementor.