Notes de bas de page

Lorsque ce procédé est employé, il convient de mettre en place une structure de navigation qui facilite les déplacements entre l’appel de note et son contenu, à l’aller et au retour. Cette préoccupation, qui bénéficie à l’ensemble des internautes, demeure essentielle pour certaines clientèles. Elle vise à éviter, entre autres, une perte de contexte de lecture pour les personnes ayant des limitations visuelles, ainsi qu’une navigation laborieuse pour des personnes qui n’utilisent pas la souris.

Voici les principaux comportements attendus avec les outils d’adaptation (lecteurs d’écran, commandes vocales, etc.) ainsi que la navigation au clavier.

• Pour chaque note de bas de page, la structure de navigation prévoit deux types de liens :
  • un lien d’appel de note (aussi appelé « référence »), qui conduit vers la note elle-même;
  • un lien qui retourne vers l’appel de note.
• Ces liens ont un libellé évocateur de leur fonction, qui permet de les distinguer dans un contexte non visuel.
  • Exemple pour l’appel de note : « Note de bas de page 1 »
  • Exemple pour le lien de retour : « Retour à la référence de la note de bas de page 1 »
• De même, ces liens sont activables avec des logiciels de commandes vocales, en dictant les nombres et/ou mots qui apparaissent dans la portion visible de leur libellé.
• Lorsque l’utilisateur active le lien d’appel de note : le focus se déplace sur le contenu de la note concernée.
  • (Recommandé) Ce déplacement devrait survenir sur le premier paragraphe de contenu de la note, plutôt que sur la note toute entière. Sinon, les lecteurs d’écran lisent d’un seul bloc le numéro de la note, le texte de la note et le lien de retour. Ce comportement crée de la confusion, car il faut tout de même naviguer au prochain élément pour atteindre le lien de retour. Cela est également moins adapté au rendu de plus longues notes.
• Lorsque l’utilisateur active le lien de retour à l’appel de note : le focus est ramené sur le lien qui constitue l’appel de note.
• Les notes de bas de page sont structurées dans une liste non ordonnée, ce qui facilite la navigation tout en évitant des confusions d’ordre sémantique.
• Le contenu de chaque note commence par une mention explicite de la note concernée (Ex. : « Note 1 : ») et se termine par un lien de retour vers l’appel de note.
  • Remarque : Pour respecter un ordre de lecture logique, la mention du numéro de note qui figure au début de celle-ci ne devrait pas servir de lien de retour. Le lien de retour est plutôt lu à la fin des contenus de la note, indépendamment de son positionnement visuel. (Pour en savoir plus sur le positionnement du lien de retour à l’aide des styles, consulter la section Explications techniques.)

Autres points à surveiller

• Lorsque des caractères (ex. : crochets) sont employés pour délimiter visuellement des appels de note, ceux-ci sont masqués aux outils d’adaptation.
• S’il y a plusieurs occurrences d’appels de note pour une même note : le libellé du lien de retour précise également l’occurrence concernée. Ex. : « Retour à la deuxième référence de la note de bas de page 1 ».
  • Remarque : Nous suggérons d’écrire les occurrences en toutes lettres (première, deuxième, etc.) plutôt qu’en chiffres (1re, 2e, etc.). Plusieurs lecteurs d’écran ont des difficultés à prononcer les graphies françaises officielles de ces abréviations. De plus, pour les outils de commandes vocales, cela limite la détection de résultats non pertinents lorsqu’un numéro de note est dicté.

Il n’existe pas d’attributs ARIA spécifiques ni d’approche standardisée pour la création de notes de bas de page accessibles dans une page Web. Dans cette section, nous proposons une approche technique éprouvée qui favorise une prise en main adéquate avec les outils d’adaptation et la navigation au clavier.

L’appel de note

• Il est balisé sous forme de lien (<a>), lui-même enchâssé dans une balise <sup>.
• Ce lien pointe vers l’identifiant unique (ID) donné au contenu de la note.
• Ce lien porte lui-même un identifiant unique (ID), qui sert de point d’ancrage lorsqu’on souhaite retourner vers l’appel de note.
  • Attention : S’assurer de bien attribuer l’identifiant au lien de l’appel de note, et non à la balise <sup> englobante. Cela assure un retour adéquat du focus sur le lien, dans certains environnements tels que MacOs.
• Le libellé complet du lien d’appel de note contient, en plus du numéro visible de la note, des informations qui contextualisent sa fonction. Dans l’exemple fourni, ces informations additionnelles sont intégrées en texte hors écran.
• Si des caractères (ex. : crochets) délimitent visuellement des appels de note, ceux-ci sont masqués aux outils d’adaptation. Exemples d’approches possibles :
  • Lorsque les caractères sont intégrés à même le texte de l’appel de note : encadrer ces caractères par une balise <span> à laquelle on assigne aria-hidden="true".
  • Lorsque les caractères sont ajoutés depuis un pseudo-élément CSS (::before ou ::after) : prévoir un texte de remplacement vide dans la valeur de la propriété content. Ex. : content: "[" / "";
• Les ajustements suivants permettent de maximiser la compatibilité avec certains lecteurs d’écran :
  • Lors d’un retour vers un appel de note, VoiceOver Mac éprouve des difficultés à poursuivre la lecture à partir de l’emplacement du lien d’appel mis en focus. Un contournement connu consiste à attribuer un tabindex="-1" à la balise <sup> qui encadre le lien d’appel de note. NVDA rencontre un problème similaire découlant de ses logiques de navigation, mais on ne peut pas le contourner actuellement (voir Enjeux connus avec les outils d’adaptation).
  • (Recommandé) Pour éviter la lecture d’un élément vide par TalkBack avant chaque appel de note, l’ajout de l’attribut tabindex (mentionné au point précédent) devrait se faire uniquement au moment où l’on clique sur le lien de retour vers l’appel de note correspondant. Par la suite, quand le focus quitte l’appel de note, l’attribut tabindex est retiré. 

Exemple de code HTML d’un appel de note

<sup tabindex="-1"><a id="fn1-ref" href="#fn1"><span class="sr-only">Note de bas de page </span>1</a></sup>

Le contenu des notes et le lien de retour

• Les notes de bas de page sont regroupées dans une liste non ordonnée (<ul>). Chaque note est elle-même enchâssée dans une balise <li>.
• Le contenu de chaque note commence par une mention explicite de la note concernée (« Note 1 : »). Dans l’exemple fourni, cette mention est placée en texte hors écran et logée dans le tout premier paragraphe de la liste.
• Un point d’ancrage est créé sur chaque note de bas de page, par l’ajout d’un identifiant unique. C’est vers cet ID que pointe l’appel de note correspondant.
  • Attention : Le choix de l’élément qui reçoit l’identifiant revêt une grande importance. Il convient de l’attribuer au premier paragraphe du contenu de la note, plutôt qu’à la balise <li> englobante. Dans le cas contraire, les lecteurs d’écran lisent d’un seul bloc le numéro de la note, le texte de la note et le lien de retour, ce qui crée de la confusion.
  • Dans l’exemple fourni, le premier paragraphe qui reçoit l’identifiant contient la mention hors écran du numéro de note. Ce court segment est idéal pour servir de point d’ancrage. En effet, il évite la lecture automatique de longs paragraphes de notes lors de la mise en focus. Cette structure est également indépendante du contenu même de la note, ce qui en fait une approche plus robuste et automatisable.
• À la fin du contenu de la note, on insère le lien de retour vers l’appel de note correspondant.
• Le libellé de ce lien contient, en plus du numéro de la note, des informations qui contextualisent sa fonction. Dans l’exemple fourni, seul le numéro de la note est visible : les autres informations sont logées en texte hors écran. Un positionnement CSS place le lien de retour à gauche de la note, ce qui permet une identification visuelle de la numérotation sans compromettre l’ordre de lecture.

Exemple de code HTML d’une note

<ul>
<li>
<p id="fn1"><span class="sr-only">Contenu de la note 1 :</span></p>
<p>Le contenu de la note va ici.</p>
<p class="fn-rtn">
<a href="#fn1-rf"><span class="sr-only">Retour à la référence de la note de bas de page </span>1</a>
</p>
</li>
</ul>

Autres considérations techniques

• Le nom accessible du lien d’appel de note doit reprendre tout le texte de son libellé visible, dans le même ordre relatif, afin de permettre l’activation de ce lien par commandes vocales. Tout en respectant ce critère, il demeure possible d’ajouter d’autres informations de contextualisation. Le même principe s’applique au lien de retour vers l’appel de note.
• Dans l’exemple fourni, JavaScript sert à gérer les occurrences multiples d’un même appel de note. Le libellé du lien de retour insère dynamiquement la mention d’occurrence concernée de l’appel de note. Exemple : « Retour à la deuxième référence de la note de bas de page 1 ».
• Pour faciliter l’identification de la note active, nous conseillons la création d’un encadré visuel (propriété CSS outline) qui entoure l’ensemble de cette note. Cela peut se faire depuis la pseudo-classe CSS :focus-within, appliquée à l’élément de liste. Ainsi, dès qu’un élément reçoit le focus à l’intérieur de la note (ici, le premier paragraphe), l’encadré apparaît pour englober toute la note.

Avec NVDA : mauvais calcul de l’emplacement pour reprendre la lecture à partir d’un appel de note

• Environnement d’observation : Versions les plus récentes de NVDA avec Chrome et Firefox, en date du 12 avril 2025.
• Résumé du problème : 
  • Le comportement suivant se produit avec NVDA dans Chrome, quand un appel de note est placé à l’intérieur d’un paragraphe. Si on retourne à l’appel de note par l’entremise du lien prévu à cet effet, et qu’ensuite, on poursuit la lecture avec les touches directionnelles, cette lecture ne reprend pas au même endroit que l’appel de note. Le rendu se poursuit à la fin de la ligne courante déterminée par NVDA. (La longueur de cette ligne n’a pas de correspondance visuelle; elle est calculée selon un nombre de caractères spécifié dans les paramètres du lecteur d’écran.) 
  • Le problème n’est pas observé dans Chrome si l’appel de note est à la toute fin d’un paragraphe, car le changement de paragraphe entraîne un recalcul de la ligne courante par NVDA.
  • Le problème n’est aucunement présent avec Firefox.
• Comportement attendu : Une fois que le focus revient sur l’appel de note, la lecture devrait se poursuivre à cet endroit. Dans le cas contraire, cela peut générer de la confusion et des manipulations additionnelles.
• Pistes et analyses techniques : 
  • Un obstacle similaire survient avec VoiceOver Mac et Safari, mais il peut être contourné en assignant tabindex="-1" à la balise <sup> de l’appel de note. Malheureusement, ce correctif est sans effet sur NVDA dans Chrome.
  • Le comportement observé n’est pas spécifique à notre exemple de composant. Le problème survient de manière plus générale, dès qu’on crée un lien interne qui pointe vers un élément spécifique situé à l’intérieur d’un paragraphe.
  • Une partie du problème semble reposer sur la manière dont la combinaison NVDA / Chrome gère la lecture des éléments ayant un rendu CSS « en ligne » (display:inline). En effet, le problème disparaît si les appels de note utilisent un rendu CSS display:block. Cependant, le rendu block n’est pas autorisé à l’intérieur d’un paragraphe en HTML5, ce qui exclut cette possibilité de contournement. Par ailleurs, le rendu inline-block, bien qu’autorisé, ne résout pas le problème.
• Impact estimé : Modéré à important. Pour les personnes qui utilisent NVDA avec Chrome, le problème entraîne une perte du contexte immédiat de navigation. Cependant, cet enjeu se manifeste de manière constante et prévisible. Des personnes utilisatrices de NVDA sensibilisées au comportement de leur outil pourraient remonter à la ligne précédente pour reprendre la lecture. Afin de limiter les inconvénients, nous suggérons de privilégier des appels de note en fin de paragraphe, lorsque possible. 
• Décision : Le bon fonctionnement dans Firefox est révélateur d’un bogue d’interaction spécifique entre NVDA et Chrome. Un suivi sera effectué auprès des équipes de développement de NVDA et de Chrome. Il est aussi intéressant de noter que, selon divers sondages sur les lecteurs d’écran conduits par l’organisation WebAIM, le navigateur Chrome est beaucoup plus employé que Firefox par les personnes utilisant NVDA. Cette tendance enregistrée depuis plusieurs années renforce l’importance d’en arriver à un comportement adéquat et prévisible pour les personnes qui combinent Chrome et NVDA.

Certains ajustements ont dû être apportés au modèle de la BOEW. Voici les principaux :

• Structure de liste : Retrait de la liste de définitions pour présenter les notes et changement pour une liste non ordonnée. Certains lecteurs d’écran ne gèrent pas bien les listes de définitions et annoncent deux fois plus d’éléments de liste qu’il y a de notes. Cela porte à confusion.
• Point d’ancrage (ID) donné au contenu de la note : Au lieu de donner l’identifiant à l’ensemble de la note, nous l’attribuons au premier paragraphe du contenu de la note. (Revoir les explications techniques pour les motifs de cet ajustement.)
• Point d’ancrage (ID) donné à l’appel de note : Dans le composant d’origine de la BOEW, l’identifiant est porté par la balise <sup>. Le script se charge ensuite de rediriger le focus sur le lien encadré par cette balise, lors du retour vers l’appel de note. Toutefois, l’exécution de cette fonction dépend de la présence d’une liste de définitions pour structurer les notes (que nous avons remplacée par une liste non ordonnée). Nous avons donc produit un petit correctif, basé sur l’approche décrite à la section Explications techniques :
  • Dans le code HTML, l’identifiant est désormais attribué à la balise <a> de l’appel de note, plutôt qu’à la balise <sup>. Cette approche simplifiée assure de manière native la mise en focus adéquate du lien lors d’un retour vers l’appel de note.
  • Un correctif JavaScript intervient pour l’ajout dynamique de tabindex="-1" sur la balise <sup> des appels de note. À la différence du script de la BOEW, nous tenons compte de la précaution technique maximisant la compatibilité avec TalkBack.  
• Occurrences multiples d’appels de note : Dans l’exemple, certains appels de note utilisent à répétition la même numérotation. Les versions plus récentes de la BOEW gèrent correctement ce cas de figure, en s’assurant que le retour à l’appel de note conduise à la dernière occurrence consultée. Malheureusement, la fonction codée dans le script d’origine dépend des listes de définitions du composant. Nous avons donc créé un correctif JavaScript pour maintenir le bon comportement. Ce correctif rectifie au passage un problème toujours présent dans les versions actuelles de la BOEW : le lien de retour ne précise pas vers quelle occurrence de l’appel de note il conduit. Désormais, une mention hors écran insérée dynamiquement dans le lien de retour indique cette information.
• Encadré visuel identifiant la note active : Le procédé de mise en forme qui permet d’encadrer la note active a été revu, puisque ce n’est plus toute la note qui reçoit le focus, mais seulement le premier paragraphe.