1178 sujets

Accessibilité du Web

Bonjour,

Après avoir passé pas mal de temps à refaire mes composants de site web, j'en viens maintenant aux templates. Pour les microdonnées j'ai décidé de migrer des microdata au JSON-LD, ça règle la problématique du placement côté html.

Pour les attributs d'accessibilité par contre je me pose une question : faut-il mettre l'attribut sur l'élément parent du texte ou sur un élément frère (par exemple une icône SVG signifiante pour les voyants mais pas pour les lecteurs d'écran).

Concrètement, entre ces deux codes, lequel serait-il le plus approprié/juste (donner un nombre de commentaires pour le topic d'un forum) :
<!-- aria-label sur l'élément parent : -->
<div aria-label="Nombre de commentaires">
  <svg class="icon-inline" role="img" focusable="false">
    <use href="/sprites/util.svg#bubbles"></use>
  </svg>2</div>

<!-- aria-label sur un élément frère du texte (l'icône) : -->
<div>
  <svg class="icon-inline" role="img" focusable="false" aria-label="Nombre de commentaires">
    <use href="/sprites/util.svg#bubbles"></use>
  </svg>2</div>


Voir un exemple dans son contexte (les items d'un forum) : Sample forum template

Au début j'étais parti pour mettre ces attributs sur l'élément parent, cela me semblait évident car j'avais commencé par créer des mots clefs placés dans une liste (donc aria-label sur le ul), et par les aria-label plus génériques pour le template de base, mais en rencontrant maintenant d'autres cas d'utilisation j'ai un doute.
Modifié par Olivier C (08 Mar 2023 - 06:14)
Bonjour,

Il n'est pas certain que aria-label et aria-labelledby soient correctement interprétés par les lecteurs d'écran sur des éléments non interactifs.
Ils sont normalement à réserver à des éléments focusables, tels que des boutons, champs de formulaire, etc.

En plus dans ton premier exemple, tu fais une deuxième erreur: aria-label et aria-labelledby remplacent complètement le contenu de l'élément.
Vu que le nombre de commentaires est inclus dans le <div>, le lecteur d'écran, en supposant qu'il traite aria-label (vu ce que je viens de dire), ne rendrait pas cette information à l'utilisateur.

En fait ici, tu as plutôt besoin d'un texte alternatif sur l'image. Sauf erreur en SVG inline, c'est la balise <title> qui joue ce rôle.

Alternativement, tu pourrais masquer l'image aux lecteurs d'écran et le remplacer par du texte spécifique qui n'est pas affiché à l'écran.
Exemple rapide:


<div>
<svg aria-hidden="true"> ... </svg>
<span class="visually-hidden">Nombre de commentaires: </span>
2
</div>


Avec la définition en CSS de .visually-hidden qui va bien, que tu pourras trouver sur knacss, ou l'équivalent bootstrap qui s'appelle .sr_only.
Bonjour messieurs,

Et ben ! moi qui avait tendance à supprimer tous mes .sr- only au profit des aria-label...

Ce qui est pénible avec les ARIA c'est que le développeur se retrouve à faire l'aveugle à la place de l'aveugle : on est dans le jeu des devinettes, à suivre des tutoriels sur des forums en tentant de les adapter au mieux, espérant que le code sera bien interprété par les lecteurs d'écran. C'est d'un pénible.

Si ça continue je vais finir par suivre un conseil souvent retrouvé sur MDN, en gros : si vous ne savez pas ne faites rien, vous risquez de faire plus de mal que de bien.

Je vais investiguer encore. Dans ce domaine les outils de test en ligne que j'ai trouvé ne sont pas forcément top. Bien sûr, si vous avez une suggestion qui change la donne je suis preneur. Le top serait d'avoir un lecteur d'écran, mais bon, il me faut raison garder : je reste un amateur (perfectionniste, c'est ça qui me tue), il n'y a pas d'enjeu.

Merci à vous deux.

... et spécialement à toi Quentin, ça fait un petit moment que je ne t'avais croisé sur le forum. Ça fait plaisir de te revoir.
Modérateur
Bonjour,

Olivier C a écrit :
Si ça continue je vais finir par suivre un conseil souvent retrouvé sur MDN, en gros : si vous ne savez pas ne faites rien, vous risquez de faire plus de mal que de bien.

+1

Quand tu te retrouves à devoir mettre un aria-xxx, la plupart du temps, ça indique que ton code html pose problème.

Amicalement,
a écrit :
Ce qui est pénible avec les ARIA c'est que le développeur se retrouve à faire l'aveugle à la place de l'aveugle : on est dans le jeu des devinettes, à suivre des tutoriels sur des forums en tentant de les adapter au mieux, espérant que le code sera bien interprété par les lecteurs d'écran. C'est d'un pénible.


Le mieux, comme partout en développement, c'est toujours de tester.

Ce qui est pénible par contre, c'est qu'il faudrait idéalement tester avec un maximum de combinaisons de plate-formes, navigateurs et lecteurs d'écran.
Ca c'est long, pas simple, et la prise en main d'un lecteur d'écran est tout sauf simple, alors possiblement trois ou plus, on n'en parle même pas.

a écrit :
Si ça continue je vais finir par suivre un conseil souvent retrouvé sur MDN, en gros : si vous ne savez pas ne faites rien, vous risquez de faire plus de mal que de bien.


S'agissant d'ARIA, ce n'est pas un mauvais conseil.

La première grande règle d'ARIA est en effet de ne pas l'utiliser si tu peux faire autrement.

a écrit :
Je vais investiguer encore. Dans ce domaine les outils de test en ligne que j'ai trouvé ne sont pas forcément top.


Les outils de test d'accessibilité automatiques ne peuvent te donner que des indications très basiques.
C'est une petite aide, mais ça ne peut absolument pas remplacer une analyse humaine.

a écrit :
Bien sûr, si vous avez une suggestion qui change la donne je suis preneur. Le top serait d'avoir un lecteur d'écran, mais bon, il me faut raison garder : je reste un amateur (perfectionniste, c'est ça qui me tue), il n'y a pas d'enjeu.


Mais essaye seulement ! NVDA est gratuit et facile à installer, VoiceOver et Talkback sont déjà dans ton téléphone.
Tu apprendras plein de choses, assurément.