Chargements asynchrones de données : bonnes pratiques pour l’accessibilité numérique

9 commentaires

Les chargements de données dynamiques sont monnaie courante, mais peuvent poser des problèmes aux personnes qui naviguent avec des technologies d’assistance.

Voyons comment mettre en place une solution accessible et éviter les pertes d’information !

Problématique et impacts d’un chargement asynchrone de données pour l’accessibilité

Certaines pages proposent une fonctionnalité permettant de charger des contenus supplémentaires par l’action sur un bouton, ce qui peut prendre plus ou moins de temps, mais évite un rechargement complet de la page.

Il peut s’agir par exemple du chargement d’offres supplémentaires sur une page listant les offres d’emploi, comme c’est le cas sur la page des offres de stages du ministère de la Défense : 

Bouton de chargement asynchrone
Bouton de chargement asynchrone. Présence d’un bouton « + Plus de résultats » qui charge des données supplémentaires sans recharger complètement la page.

Une image de chargement (type spinner) est affichée visuellement le temps du chargement.

Or, il est absolument nécessaire de restituer correctement ces évènements aux technologies d’assistance afin que tous les utilisateurs et utilisatrices en situation de handicap soient en mesure de comprendre et d’interagir avec la page, notamment les personnes aveugles et plus généralement celles qui utilisent un lecteur d’écran et naviguent au clavier.

Comment charger des données de manière asynchrone de manière accessible ? Solutions proposées

Pour rendre accessible ce type de chargement asynchrone, la solution à privilégier consiste à utiliser le rôle ARIA progressbar.

Néanmoins, dans certains cas, ce type d’adaptation peut s’avérer compliqué, voire impossible à mettre en œuvre à cause des technologies utilisées par la page ou de la charge de travail que cela demanderait.

Une implémentation conforme au RGAA consiste alors à s’assurer que toutes les informations soient correctement restituées à l’aide de la méthode suivante.

Au moment du chargement

Insérer un passage de texte indiquant le statut de l’action (par exemple : « Chargement en cours ») n’importe où dans le DOM. Ce texte devra posséder la propriété ARIA role="alert".

Par exemple : <p id="loading" class="sr-only" role="alert">Chargement en cours</p>

Note : on peut ajouter la classe .sr-only au texte pour qu’il soit invisible à l’écran, mais qu’il puisse quand même être lu par les technologies d’assistance. On s’assure ainsi que ce texte soit bien restitué aux personnes utilisant un lecteur d’écran, sans affecter l’interface visuelle de la page.

À la fin du chargement

  1. Repositionner le focus sur le 1er élément ajouté de la liste (par exemple sur le titre qui devra alors avoir la propriété tabindex="-1" afin de lui permettre de prendre le focus).
  2. Supprimer le passage de texte (id="loading") indiquant le chargement en cours.

Conclusion

Cette solution simple permet de rendre accessibles les chargements de données asynchrones aux personnes utilisant un lecteur d’écran, en les avertissant qu’un chargement est en cours et en re-positionnant leur focus au bon endroit sur la page.

Ainsi, on facilite leur navigation dans la page et on s’assure qu’elles aient bien accès à l’information au moment où le chargement se produit.

Références

Ressources

Besoin d’aide pour développer des scripts accessibles ?

Rejoignez-nous lors d’une prochaine session de formation Développer et coder des sites accessibles pour voir d’autres exemples et approfondir vos connaissances de l’accessibilité numérique côté développement front-end et intégration web.

À l’issue de votre formation, vous aurez la possibilité d’obtenir une certification professionnelle en accessibilité numérique, reconnue par l’État.

Des possibilités de financement existent. N’hésitez pas à nous contacter pour obtenir un devis gratuit !

À propos

  • Christophe Goujon

    Expert accessibilité numérique

    Christophe Goujon est expert accessibilité numérique chez Access42 depuis 2020. Avant de rejoindre notre Scop, il a travaillé plusieurs années dans des entreprises de services numériques où il s’est spécialisé dans la conception d’outils e-commerce. Aujourd’hui, il réalise des audits d’accessibilité, des missions d’accompagnement et anime la formation « Développer des sites web accessibles et conformes au RGAA ».

9 commentaires

Bonjour, concernant l'ajout de l'attribut tabindex="-1", cela permet de rendre "focusable" le 1er nouvel élément, mais faut-il en plus lui mettre le focus dessus ?
merci

Répondre

Bonjour,
En effet, il faut repositionner le focus sur l'élément cible avec la méthode .focus() en JavaScript.
Un exemple est visible dans la méthode cleanScreen() de la démonstration d'implémentation (https://tests.a11y.fr/chargements-asynchrones.html).

Répondre

Bonjour Christophe,

Merci pour votre réponse, que je découvre un peu tard.

Je me suis aussi posé cette question des combinaisons de lecteurs d'écrans / navigateurs, et j'ai pensé qu'il pouvait y avoir une différence entre l'utilisation de aria-live ou du role="alert".
Je me suis donc lancée dans des tests plus approfondis via un CodePen : https://codepen.io/ecedifront/full/yLrMaMo

J'ai constaté :
- KO sur NVDA avec Firefox 123 / Edge 122 / Chrome 122, si on ajoute le texte avec aria-live (que ce soit polite ou assertive) à la volée : pas de restitution
- mais OK si on utilise role="alert" (comme votre démonstration) avec les mêmes combinaisons
- OK sur VoiceOver avec Safari dans toutes les combinaisons
- je n'ai pas pu tester avec JAWS malheureusement

J'ai aussi testé sur IE11 dans le doute, car la partie "environnement de test" du RGAA parle de "Internet Explorer" et non pas Edge : https://accessibilite.numerique.gouv.fr/methode/environnement-de-test/
Et donc avec IE11 c'est KO sur NVDA, dans toutes les combinaisons, sauf celle où le aria-live est déjà présent avant l'ajout.

Au vu de ces résultats, je crois que je vais continuer à préconiser pour le moment (en "bonne pratique") que les attributs soient présents au chargement, et non pas ajoutés à la volée.

Est-ce-que vous constatez la même chose que moi, et sauriez-vous dire si les tests doivent concerner IE11 encore maintenant ?

Merci d'avance pour votre retour !

Répondre

Bonjour,
En effet, concernant l’ajout dynamique, nous sommes sûrs du support par les technologies d’assistance uniquement avec la propriété role="alert".
Dans le cas d’un usage avec une autre méthode (aria-live par exemple), il vaut mieux, en effet, privilégier de créer la zone dans la page et d’y ajouter les données dynamiquement. Des détails sont disponibles sur l'article "Live régions ARIA" disponible ici : https://access42.net/live-regions-aria-live-analogues-alert-log-status/.

Concernant les restitutions, comme indiqué, nous nous appuyons sur l’environnement de test du référentiel. Cela dit, cet environnement n’est plus réellement à jour, Internet Explorer n’est plus maintenu (et n’est plus disponible sur la plupart des Windows 11 depuis une mise à jour de Edge), nous n’avons donc pas à faire de test sur ce navigateur. Les combinaisons à tester aujourd’hui sont :
Windows/Firefox/NVDA, Windows/Firefox/JAWS et MacOS/Safari/VoiceOver.

Il y a fort à parier que la prochaine mise à jour du RGAA intégrera des changements sur l’environnement de test, pour coller au mieux aux besoins et aux usages des personnes handicapées.

Répondre

Bonjour,
J'ai une question sur la partie "Au moment du chargement" : je crois que si on insère seulement à ce moment-là le en entier avec son contenu à l'intérieur, il n'y aura pas de restitution ? En effet, il me semble qu'il faut que le conteneur avec role="alert" (ou aria-live) soit présent avant que le contenu à l'intérieur soit ajouté/modifié, pour que la restitution par les TA fonctionne : est-ce-que vous confirmez ce point ?
Dans ce cas, une solution pourrait être d'avoir plutôt une vide présente dès le départ dans la page, mais le texte à l'intérieur ajouté uniquement au moment du chargement ?
Merci d'avance pour votre confirmation ou précisions !

Répondre

Bonjour,
Il est possible que certaines combinaisons lecteur d'écran / navigateur (notamment sur des anciennes versions) posent des problèmes sur des restitutions, néanmoins, les derniers tests effectués sur l'environnement de test du RGAA montrent que même lors de l'insertion dynamique de la zone de texte, les restitutions se font correctement.
Les résultats de ces restitutions sont disponibles dans la page de démonstration.

Répondre

Répondre à Christophe Goujon Annuler

Le formulaire contient des erreurs. Veuillez vérifier votre saisie puis envoyer à nouveau votre demande s’il vous plaît.

* Champs obligatoires

Veuillez remplir ce champ s'il vous plaît.

Veuillez remplir ce champ s'il vous plaît.