Rendre une application Angular accessible : les cinq points qui comptent

Une application métier est utilisée huit heures par jour par les mêmes personnes. Parmi elles, certaines naviguent au clavier parce que c’est plus rapide, d’autres parce qu’elles n’ont pas le choix. Les deux attendent la même chose : que chaque action soit atteignable sans souris, et que l’écran dise ce qui vient de se passer.

Le défaut le plus répandu tient en une ligne de gabarit : un « (click) » posé sur une « div » ou un « span ». À la souris, tout fonctionne. Au clavier, l’élément n’est jamais atteint ; au lecteur d’écran, il n’est même pas annoncé comme une action.

• Un bouton est un « <button> », un lien qui change d’adresse est un « <a routerLink> ». Ils reçoivent le focus, réagissent à Entrée et à Espace, et s’annoncent correctement, sans une ligne de code en plus.
• Un composant maison (liste déroulante, onglets, menu) doit reproduire ce comportement à la main : « role », « tabindex », gestion des flèches. Le CDK d’Angular fournit « ListKeyManager » et « FocusKeyManager » pour la navigation aux flèches, au lieu de la réécrire à chaque composant.
• Les attributs ARIA se lient avec « [attr.aria-…] », par exemple « [attr.aria-expanded]="ouvert" », pour que l’état affiché et l’état annoncé ne divergent jamais.

Dans une application monopage, cliquer sur un lien ne recharge rien : le routeur remplace une partie de l’écran. Pour un utilisateur voyant, c’est instantané. Pour un utilisateur de lecteur d’écran, rien ne se passe : le focus reste sur le lien qu’il vient d’activer, et aucune annonce ne signale la nouvelle page.

• Donnez un titre à chaque route avec la propriété « title » de la configuration du routeur : l’onglet change, et c’est souvent la première chose qu’un lecteur d’écran annonce.
• Déplacez le focus après la navigation, sur le titre principal de la nouvelle page ou sur la zone de contenu, en écoutant la fin de navigation du routeur. C’est la recommandation de la documentation d’Angular elle-même.

Une fenêtre modale ouverte doit garder le clavier à l’intérieur, se fermer avec Échap, et rendre le focus à l’élément qui l’a ouverte. Sans cela, la touche Tabulation part se promener dans la page grisée derrière, et l’utilisateur perd sa place en refermant.

Angular Material et le « Dialog » du CDK font tout cela par défaut. Une modale écrite à la main peut s’appuyer sur la directive « cdkTrapFocus » pour la même retenue du focus. C’est l’un des cas où réutiliser l’existant est plus accessible que de construire soi-même.

Une application métier vit d’opérations asynchrones : enregistrer, filtrer, importer un fichier. Un indicateur de chargement qui tourne et un message « Enregistré » qui apparaît en haut à droite sont visibles, mais muets pour un lecteur d’écran.

• Annoncez le résultat des opérations avec le service « LiveAnnouncer » du CDK, ou une zone « aria-live » dans le gabarit : le message est lu sans que le focus bouge.
• Reliez chaque erreur à son champ : « aria-invalid » sur le champ en erreur, « aria-describedby » vers le message. Les composants de formulaire d’Angular Material le font ; un formulaire réactif écrit à la main doit le faire explicitement.
• À la soumission d’un formulaire invalide, placez le focus sur le premier champ en erreur plutôt que de laisser l’utilisateur chercher ce qui bloque.

La grille de données est le cœur de la plupart des applications métier, et souvent leur partie la moins accessible : cent lignes de cellules cliquables, des filtres dans les en-têtes, des actions au survol. Au clavier, la parcourir case par case avec Tabulation devient impraticable.

• Une grille se parcourt aux flèches, une seule cellule à la fois dans l’ordre de tabulation. Les bibliothèques sérieuses le prévoient : sur Kendo UI pour Angular, c’est l’option « navigable » de la grille, désactivée par défaut.
• Une action au survol (le crayon qui apparaît en passant la souris sur une ligne) doit aussi apparaître au focus.
• Un tableau simple reste un « <table> » avec ses « <th> » : c’est ce qui permet au lecteur d’écran d’annoncer l’en-tête de colonne avec chaque valeur.

Sur une application existante, je procède dans cet ordre, du moins coûteux au plus fin :

• Activer les règles d’accessibilité d’angular-eslint et corriger ce qu’elles relèvent dans les gabarits.
• Brancher axe-core sur les tests de bout en bout (Playwright ou Cypress) : chaque écran testé est aussi vérifié, et une régression bloque l’intégration continue.
• Parcourir les trois parcours principaux au clavier seul, puis au lecteur d’écran : ce sont eux qui révèlent les changements de page et les annonces manquantes.

Ce site est passé par les deux premières étapes le 24 octobre 2026 : le test automatique de toutes ses pages n’a relevé qu’une famille de défauts, des couleurs trop pâles, corrigées le jour même. Le détail est dans sa déclaration d’accessibilité.

L’accessibilité d’une application Angular ne se rajoute pas à la fin. Elle se perd composant par composant, et se regagne de la même façon.

Si vous maintenez une application Angular et que vous voulez savoir où elle en est, l’accessibilité fait partie de ce que je reprends dans une application web métier, au même titre que la maintenance ou les performances. Décrivez-moi votre application : je vous réponds sous 48 heures avec ce qu’un premier passage permettrait de vérifier.