Accessibilité : comment gérer le rechargement de page dans les « Single Page Applications » ?

1 commentaire

Attention ! Cet article a été écrit en 2019. Son contenu a peut-être besoin d’une mise à jour. Complétez votre veille avec des articles plus récents, par exemple en consultant les nouveautés de notre blog accessibilité numérique, ou en lançant une recherche pour trouver des articles similaires, mais à jour.

Dans les frameworks JavaScript modernes, appelés Single Page Applications (SPA), l’utilisateur ne change plus de « page », mais de « contexte ».

Les codes de navigation sont donc perturbés puisque l’utilisateur expérimente une navigation qui n’est plus standard : le focus du navigateur n’est plus repositionné en haut de page et très souvent, le titre de la page n’est jamais modifié.

Voyons ensemble comment résoudre ces problèmes.

Problématiques

Dans les frameworks SPA type Angular, Backbone, etc. :

  • il n’y a pas plus de rechargement de page à proprement parler, mais uniquement un changement de contexte ;
  • le titre de page n’est jamais redéfini en fonction de ces changements de contexte : toutes les « pages » ont souvent le même titre ;
  • le focus du navigateur est laissé sur l’élément qui a permis de charger le nouveau contexte, mais n’est pas repositionné en haut de page, comme il le serait dans le cas d’une navigation hypertextuelle standard.

Pour vous rendre compte du problème, faites le test sur la page « Simulation d’un rechargement de page SPA non conforme » :

  1. Naviguez en tabulant (touche Tab) jusqu’au lien « Cliquez sur le lien pour charger un nouveau contexte de page ». La prise de focus est visible avec un outline volontairement renforcé.
  2. Appuyez sur la touche Entrée pour valider l’action.
  3. Le contenu a changé. On est passé de « Page 1 » à « Page 2 », mais le focus est resté sur le lien qui a permis de charger ce nouveau contexte.

Or, pour les personnes aveugles utilisant un lecteur d’écran, le focus reste donc positionné au milieu, voire à la fin, du nouveau contenu ainsi chargé, alors qu’il devrait être repositionné au début de celui-ci pour leur permettre de le découvrir en entier.

Dans ces cas particuliers de navigation, il faut donc veiller à :

  1. mettre à jour le titre de la page dès qu’une nouvelle page est chargée ;
  2. simuler le rechargement de page pour les personnes utilisant une technologie d’assistance en :
    1. forçant la restitution du titre de page, qui vient d’être mis à jour ;
    2. repositionnant le focus du navigateur en haut de page.

1. Mettre à jour le titre de la page

Le titre de la page, c’est la balise <title> dans le <head> du code source HTML.

Sur un site web classique, lorsqu’une nouvelle page se charge, le titre de page est la première information restituée automatiquement par un lecteur d’écran.

Dans une SPA, dès qu’un nouveau contexte est chargé de manière dynamique, le titre de la page doit être modifié afin de décrire le contenu fraîchement chargé, notamment aux utilisateurs de technologies d’assistance.

C’est l’objet du critère 8.6 du RGAA 4 : Pour chaque page web ayant un titre de page (balise <title>), le contenu de cette balise est-il pertinent ? .

Quel titre ?

Dans la majorité des cas, le titre de la page reprend le contenu du titre principal (<h1> ou <h2>) du document, auquel on peut ajouter le titre du site – cela étant à définir avec les personnes en charge de la gestion éditoriale du projet.

Pour la page d’accueil, on a souvent :

<head>
<title>Accueil - [Nom du site]</title>
</head>

Et ainsi de suite pour chacune des pages de contenus du site.

Certaines situations sont plus délicates à gérer et vont demander une gestion au cas par cas.

Dans les collections de pages, c’est-à-dire les résultats paginés, par exemple des résultats de recherche ou des pages d’archives : il faut indiquer la pagination en cours de lecture, et si possible, le nombre total de pages dans la collection. Par exemple : 

<head>
<title>Mes dossiers en cours – page 3/5 – [Nom du site]</title>
</head>

Dans les pages de résultats de recherche : on va indiquer tout ou partie des termes de recherche et des filtres de tri, si c’est pertinent. Par exemple :

<head>
<title>Recherche pour « informatique » – page 3/18 - [Nom du site]</title>
</head>

Dans les formulaires : lorsqu’une erreur de saisie est signalée à l’utilisateur dans la page, on peut indiquer dans ce titre la présence d’erreurs dans le formulaire. Par exemple :

<head>
<title>Erreur dans le formulaire - Contactez-nous - [Nom du site]
</title>
</head>

Comment modifier le titre de la page ?

Selon le framework utilisé, modifiez directement le titre de la page avec la fonction fournie.

Par exemple, Angular fournit la méthode setTitle.

Sinon, en JavaScript, il est simple de surcharger le titre de la page avec la propriété title : document.title().

Par exemple : document.title = ’Le nouveau titre de ma page’;.

Avertir les utilisateurs de lecteurs d’écran de la mise à jour du titre

Cependant, attention, modifier le titre de la page de manière dynamique avec ces méthodes ne suffit pas.

En effet, ce nouveau titre ne sera pas restitué par les technologies d’assistance, parce qu’il n’y aura pas eu de rechargement de page, mais uniquement un changement de contexte.

Ainsi, si le titre de la page a bien changé visuellement, les personnes utilisant un lecteur d’écran n’auront pas conscience de cette mise à jour [1].

Bien que ceci ne soit pas une non-conformité au regard du RGAA, il s’agit d’une problématique qu’il peut être utile de prendre en charge en même temps que l’on corrige les reprises de focus.

2. Simuler un rechargement de page

Outre le problème de restitution du titre de la page que nous venons de voir, le changement de contexte qui se produit dans une SPA pose un autre problème : la gestion du focus.

Sur un site web classique, lorsqu’une nouvelle page se charge, le focus de l’utilisateur est repositionné en haut de la page : cela permet aux personnes naviguant au clavier de redémarrer leur navigation depuis le début de la page.

Cependant, dans les frameworks SPA, lorsqu’on clique sur un lien de navigation interne au site :

  1. soit le focus est laissé sur ce lien (si ce lien est toujours présent dans le nouveau contexte) ;
  2. soit ce lien disparaît dans le nouveau contexte, ce qui a pour conséquence de faire disparaître le focus, que l’utilisateur ne voit même plus à l’écran.

Dans les deux cas, cela pose des problèmes d’accessibilité.

En effet, ce comportement par défaut enfreint la cohérence de la tabulation, demandée par le critère 12.8 du RGAA 4 : Critère 12.8. Dans chaque page web, l’ordre de tabulation est-il cohérent ? .

D’une part, ce comportement par défaut dans les SPA est très problématique pour les personnes aveugles. En effet, elles ne perçoivent pas les changements visuels qui ont eu lieu dans la page au clic sur le lien : or, lorsqu’elles vont démarrer la lecture de la page en naviguant vers le bas, elles vont se retrouver perdues au milieu de la page sans comprendre ce qui a changé.

D’autre part, les utilisateurs voyants qui naviguent au clavier peuvent aussi être en difficulté à ce moment-là si le lien qui a permis de charger le nouveau contexte n’existe plus. Dans ce cas, plus aucun élément n’a le focus, et l’outline a disparu visuellement, ce qui empêche l’utilisateur ou l’utilisatrice de repérer où elle se trouve.

Repositionner le focus en haut de page

Pour ces personnes-là, il est indispensable de repositionner le focus en haut de la page dès qu’un nouveau contexte est chargé.

La méthode la plus simple est de faire une reprise de focus sur le lien d’accès rapide de la page à chaque changement de page.

Ainsi l’utilisateur est toujours repositionné en haut de page :

  • les utilisateurs naviguant au clavier sont repositionnés directement sur le lien d’accès rapide et peuvent démarrer l’exploration de la page ;
  • les utilisateurs aveugles sont repositionnés sur un lien dont ils connaissent la localisation (haut de page) : c’est le signe pour eux que l’activation du lien a été suivie d’effet.

Avertir les utilisateurs de lecteurs d’écran de la mise à jour du titre

Bien que ce ne soit pas requis par le RGAA, on peut tout de même améliorer l’expérience pour les personnes déficientes visuelles utilisant un lecteur d’écran, et compléter cette simulation de rechargement de page.

Pour cela, on va implémenter deux choses :

  • un conteneur dont le contenu texte sera synchronisé avec celui du <title>. Ce conteneur sera positionné tout en haut du DOM, en tant que premier nœud texte dans la balise body ;
  • une reprise de focus sur ce même conteneur.

Un second titre synchronisé

Pour cela, on va commencer par insérer le conteneur suivant en tant que premier élément du DOM :

<p id="title-page" tabindex="-1" class="sr-only">
Le contenu de ma balise <title>
</p>

Dans ce paragraphe, il faut veiller à mettre à jour la chaîne de texte pour qu’elle soit toujours synchronisée avec le contenu de la balise <title>. Cette mise à jour doit se faire au moment où le nouveau contexte est chargé.

Ce paragraphe n’a pas besoin d’être affiché à l’écran : on peut le positionner hors écran de manière accessible (c’est-à-dire sans utiliser display:none ou d’autres propriétés CSS qui rendent le texte inaccessible aux lecteurs d’écran), par exemple avec une méthode CSS comme .sr-only.

Vous remarquerez que cette élément <p> possède l’attribut tabindex="-1". En effet, pour repositionner le focus sur un élément en JavaScript, on utilise la méthode focus().

Or, la méthode focus ne fonctionne que sur des éléments réputés « focusables », c’est-à-dire pouvant prendre le focus : les liens, les champs de formulaires, les boutons, tout élément avec l’attribut tabindex.

La propriété tabindex="-1" permet donc de déclarer un élément HTML comme pouvant recevoir le focus sans pour autant le faire entrer dans l’ordre de tabulation, même s’il s’agit d’un élément HTML sur lequel on ne peut pas tabuler nativement (paragraphe, div, etc.).

Reprise de focus sur le second titre

Une fois que le nouveau contexte est chargé et que le texte du paragraphe reprenant le titre est modifié, on va forcer la reprise de focus sur ce conteneur, ce qui permettra sa restitution par les lecteurs d’écran.

Pour vous rendre compte, faites le test sur la page Simulation d’un rechargement de page SPA conforme :

  1. naviguez à la tabulation (touche Tab) jusqu’au lien « Cliquez sur le lien pour charger un nouveau contexte de page ». La prise de focus est visible avec un outline volontairement renforcé ;
  2. appuyez sur la touche Entrée pour valider l’action ;
  3. le contenu a changé : on est passé de « Page 1 » à « Page 2 ». De plus, si on tabule (touche Tab), le focus a bien été repositionné en haut de page.

Pour comprendre tout l’intérêt de cette implémentation, nous vous conseillons de faire le test avec un lecteur d’écran.

Ainsi, vous vous rendrez compte de la différence d’expérience entre une SPA qui ne gère pas cette simulation de rechargement (changement de contexte sans restitution du nouveau titre) et une SPA qui le gère (changement de contexte avec restitution du nouveau titre et repositionnement du focus).

Conclusion

Grâce à ces différents correctifs, lorsque l’utilisateur cliquera sur un lien de navigation interne :

  • le nouveau contexte sera chargé ;
  • le titre de la page sera mis à jour ;
  • et, selon votre choix d’implémentation :
    • le focus du navigateur sera repositionné sur le lien d’accès rapide,
    • ou le focus du navigateur sera repositionné sur le conteneur reprenant le titre de la page pour que les lecteurs d’écran puissent restituer ce nouveau titre sans problème.

Côté développement

Pour les développeurs et développeuses, il s’agit ici d’un point d’attention très particulier et spécifique aux SPA.

En effet, dès que vous commencez à développer un site ou une application avec ce type de framework JavaScript, vous devez veiller à faire respecter ces principes et à les tester avec un lecteur d’écran.

Côté audit

Lors d’un audit d’accessibilité, il s’agit aussi d’une problématique à laquelle il va falloir faire attention, puisque les sites web modernes sont de plus en plus développés avec des frameworks SPA.

Voici les étapes essentielles pour tester cette gestion de la navigation :

  • renforcez l’outline à la prise de focus pour percevoir exactement votre position, tabulez sur les liens internes (touche Tab) et activez un lien interne ;
  • constatez ensuite la position du focus :
    • soit vous voyez le focus : s’il est toujours sur le lien que vous avez cliqué, alors il y a un défaut,
    • soit vous ne voyez plus le focus : à ce moment-là, tabulez pour constater sur quel élément se déplace le focus lors de la prochaine tabulation :
      • si vous constatez que la tabulation se fait sur les premiers de la page, alors il y a de bonnes chances pour que le focus ait bien été repositionné en haut de la page,
      • si vous constatez que la tabulation continue au milieu ou après le nouveau contenu chargé, alors le focus n’a pas été repositionné en haut de page et vous avez affaire à un problème d’accessibilité.

Envie d’apprendre à (mieux) vous servir d’un lecteur d’écran ?

Découvrez notre formation Tester l’accessibilité avec les lecteurs d’écran de bureau : NVDA, JAWS, VoiceOver.

Animée par Sylvie Duchateau, experte accessibilité aveugle spécialiste des lecteurs d’écran, vous apprendrez à :

  • vous servir de NVDA, JAWS et VoiceOver ;
  • à détecter rapidement les problèmes d’accessibilité présents sur les interfaces que vous développez et intégrez.

Notes

  • [1] Même si les utilisateurs de lecteurs d’écran disposent d’un raccourci clavier pour restituer à volonté le titre de la page depuis n’importe quelle position dans la page, il semble important que ce changement majeur leur soit signifié sans qu’ils aient à réaliser une action.

Publié le 17 décembre 2019 – Mis à jour le 11 août 2023

Catégorie : Développement

À propos

  • Audrey Maniez

    Co-gérante et experte accessibilité numérique

    Audrey Maniez est experte senior en accessibilité numérique, formatrice, directrice pédagogique et co-gérante d’Access42. Grâce à une maîtrise poussée des différentes normes d’accessibilité numérique, Audrey réalise des audits d’accessibilité et accompagne nos clients dans leur démarche de mise en conformité aux normes en vigueur. Formatrice chevronnée, Audrey anime nos formations les plus techniques. Par ailleurs, elle a encadré la traduction officielle en français des WCAG 2.1 publiée par le W3C, et encadre en ce moment celle des WCAG 2.2.

1 commentaire

Accessibilité : comment gérer le rechargement de page dans les « Single Page Applications » ?
Bonjour,

Merci pour cet article qui m'a beaucoup servi aujourd'hui. J'ai cependant rencontré un problème avec le tabIndex="-1" qui bloquait tous les liens du navbar pour la navigation entre plusieurs étapes d'une même page. J'ai résolu le problème avec l'aria-live="polite" qui met bien à jour le rendu du title sur le lecteur d'écran. :)

A bientôt,
Emmanuelle.

Les commentaires sont désormais fermés, mais vous pouvez toujours nous contacter pour réagir à cet article !