1178 sujets
Accessibilité du Web
Bonjour,
Si tu parles des lecteurs de texte, il faut probablement rajouter un attribut aria- (par exemple un aria-label="texte barré" pour être certain que ça marche partout).
On peut aussi barrer un texte en le mettant dans une balise <s> ou <del>. Mais le contenu est lu par les lecteurs de texte comme un texte normal.
Amicalement,
Si tu parles des lecteurs de texte, il faut probablement rajouter un attribut aria- (par exemple un aria-label="texte barré" pour être certain que ça marche partout).
On peut aussi barrer un texte en le mettant dans une balise <s> ou <del>. Mais le contenu est lu par les lecteurs de texte comme un texte normal.
Amicalement,
Oui, <del> semble une bonne solution, avec l'attribut aria-label ou bien via les pseudo-classes CSS (cf https://developer.mozilla.org/fr/docs/Web/HTML/Element/del) qui ont le mérite d'indiquer la fin du texte barré.
Bonjour,
je confirme ce qu'écrit parsimonhi : le contenu de <del> sera lu par un lecteur d'écran (et autres technologies d'assistance) comme un texte normal.
L'ajout de MDN est bien formulé pour un usage un peu générique, ceci dit 2 remarques pour améliorer selon ton usage :
1. L'usage de contenu généré par des pseudo-éléments c'est pas idéal. C'est restitué par tous les lecteurs d'écran modernes mais SI tu as la main sur le contenu HTML que génère ton CMS, il est préférable d'utiliser du contenu masqué :
Meilleure maintenance (je m'attend pas en tant que dév / inté à devoir chercher du texte perceptible par les visiteurs dans les CSS !) et ce que fait le code est réuni en 1 seul endroit, 1 seule techno.
Meilleure gestion du multi-lingue si c'est ton cas : JS ça a longtemps pas été ça pour les concepteurs de plugins mais alors CSS et multilingue les bonnes pratiques sont à réinventer dans chaque équipe.
2. Quel est ton usage justement ? Est-ce pour un prix barré, pour du contenu libre textuel créé par les contributeurs de contenu, un diff des modifications de ce contenu ou un vrai diff pour les dévs ?
Dans ce dernier cas, les + et - ne sont pas non plus restitués par les lecteurs d'écran (joie...) parce que ça a tellement été abusé dans le contenu de milliards de pages pour créer des liste à la place de UL / LI que JAWS, NVDA, Voiceover et cie ont bien été obligés de s'adapter à la situation existante pourrie et ont donc choisi d'ignorer les + - en début de ligne.
Un dév doit - j'imagine - savoir comment forcer la restitution mais dans un contexte hors dév c'est pas le cas.
EDIT : aria-label sur des input, button, select, textarea ou lien (éléments interactifs), sur des section, nav, etc et quelques autres cas oui c'est fait pour remplacer l'intitulé visible par un autre texte qui sera lu par les TA (technos d'assistance càd lecteurs d'écran, commandes vocales et autres).
Sur des éléments pas interactifs, pas sectionnants j'ai de gros doutes : ce ne sera peut-être plus valides avec ARIA 1.2 (ou 1.3 ?), pas forcément restitué actuellement et peut-être plus d'ici quelques années.
"Ajouter un aria-label" n'est pas une recette magique si tu sais pas pourquoi. Rarement la bonne solution hors formulaires (input et cie, button) et gabarits de page (nav et section pour résumer).
Modifié par Felipe (17 May 2023 - 11:59)
je confirme ce qu'écrit parsimonhi : le contenu de <del> sera lu par un lecteur d'écran (et autres technologies d'assistance) comme un texte normal.
L'ajout de MDN est bien formulé pour un usage un peu générique, ceci dit 2 remarques pour améliorer selon ton usage :
1. L'usage de contenu généré par des pseudo-éléments c'est pas idéal. C'est restitué par tous les lecteurs d'écran modernes mais SI tu as la main sur le contenu HTML que génère ton CMS, il est préférable d'utiliser du contenu masqué :
<del><span class="visually-hidden">Prix barré</span>110 €</del>
<span><span class="visually-hidden">Nouveau prix </span>80 €</span>
Meilleure maintenance (je m'attend pas en tant que dév / inté à devoir chercher du texte perceptible par les visiteurs dans les CSS !) et ce que fait le code est réuni en 1 seul endroit, 1 seule techno.
Meilleure gestion du multi-lingue si c'est ton cas : JS ça a longtemps pas été ça pour les concepteurs de plugins mais alors CSS et multilingue les bonnes pratiques sont à réinventer dans chaque équipe.
2. Quel est ton usage justement ? Est-ce pour un prix barré, pour du contenu libre textuel créé par les contributeurs de contenu, un diff des modifications de ce contenu ou un vrai diff pour les dévs ?
Dans ce dernier cas, les + et - ne sont pas non plus restitués par les lecteurs d'écran (joie...) parce que ça a tellement été abusé dans le contenu de milliards de pages pour créer des liste à la place de UL / LI que JAWS, NVDA, Voiceover et cie ont bien été obligés de s'adapter à la situation existante pourrie et ont donc choisi d'ignorer les + - en début de ligne.
Un dév doit - j'imagine - savoir comment forcer la restitution mais dans un contexte hors dév c'est pas le cas.
EDIT : aria-label sur des input, button, select, textarea ou lien (éléments interactifs), sur des section, nav, etc et quelques autres cas oui c'est fait pour remplacer l'intitulé visible par un autre texte qui sera lu par les TA (technos d'assistance càd lecteurs d'écran, commandes vocales et autres).
Sur des éléments pas interactifs, pas sectionnants j'ai de gros doutes : ce ne sera peut-être plus valides avec ARIA 1.2 (ou 1.3 ?), pas forcément restitué actuellement et peut-être plus d'ici quelques années.
"Ajouter un aria-label" n'est pas une recette magique si tu sais pas pourquoi. Rarement la bonne solution hors formulaires (input et cie, button) et gabarits de page (nav et section pour résumer).
Modifié par Felipe (17 May 2023 - 11:59)
Bonsoir,
Réactions ou précisions pêle-même sur les posts précédents.
Je confirme qu'il faut utiliser <s> ou <del> pour marquer le texte barré.
A noter que dans la plus pure des théories de sémantique, <del> est à utiliser pour indiquer quelque chose qui a été supprimé ou qui n'est plus valable, alors que <s> indique simplement un texte barré visuellement sans notion de suppression ou de non-validité.
C'est le même parralèle que <strong> vs. <b>, ou <em> vs. <i>, où avec les premiers on veut indiquer une importance, une mise en évidence, alors que pour les seconds on insiste sur la mise en forme plutôt que sur une mise en évidence.
Une application concrète de <i> par exemple, est que, par convention, les noms scentifiques latins des espèces animales ou végétales s'écrivent en italique. Dans ce cas-là, on doit utiliser <i> et non pas <em> car on ne veut en général pas particulièrement mettre le nom latin en évidence, on veut juste respecter la convention de mise en forme.
Pour en revenir à <del> vs. <s>, utiliser <del> me parait tout à fait approprié dans l'exemple du prix barré, dans le sens où ça représente une information qui était valable à un moment donné mais plus maintenant.
Dans le cas du diff, c'est évidemment aussi plutôt <del> qu'il faut utiliser, avec son pendant <ins> pour marquer le texte ajouté.
Les lecteurs d'écran ne font effectivement par défaut rien avec <del> et <ins>, mais on peut les configurer pour qu'ils prononcent le texte avec une autre voix, qu'un son soit joué, ou qu'ils disent quelque chose comme "texte barré" et "fin du texte barré".
Avec Jaws par exemple, cette configuration se passe dans les schémas de sons et de voix, c'est assez compliqué à configurer mais on peut faire pas mal de choses.
De même les + et - ne sont effectivement pas prononcés la plupart du temps dans la configuration par défaut, mais un petit réglage peut se faire dans la gestion des ponctuations.
La solution la plus accessible est donc effectivement d'utiliser du texte caché à l'écran, avec des classes CSS comme visually-hidden ou sr_only, précisant explicitement quelque chose comme "prix d'origine" ou "promotion".
Maintenant concernant ARIA, il ne faut jamais oublier que la règle n°1 d'ARIA et de ne pas l'utiliser si on peut éviter.
Ce n'est pas moi qui le dit, c'est écrit en clair dans les WCAG et l'authoring practice.
Certaines plate-formes et frameworks l'utilisent ou encouragent à l'utiliser beaucoup trop, alors qu'il existe souvent des solutions standard beaucoup plus simples aujourd'hui. ON peut faire pas mal de choses avec ARIA et des choses très bien, le gros problème c'est qu'il est aussi très très facile de casser complètement la'ccessibilité d'une application entière pour pas grand chose.
Exemple symtômatique, des aria-hidden=true|false qui se retrouvent un peu partout sans aucune raison autre qu'un copier-coller irréfléchi et/ou qu'une ignorance de ce que ça fait et/ou qu'un jemenfoutisme total, et qui, d'un seul coup d'un seul, réduisent tous les efforts d'accessibilité à néant.
C'est généralement bien pire quand ARIA est mal utilisé, plutôt que quand il n'est pas utilisé du tout, donc dans le doute, ne l'utilisez pas plutôt que de l'utiliser mal.
Enfin, pour info, vous ne pouvez être totalement certain que aria-label sera effectivement restitué que sur les éléments interactifs focusables (champs de formulaire, boutons, liens, etc.). et les landmarks.
Sur tous les éléments non-interactifs et non landmarks comme <div>, <span> ou <p>, certains lecteurs d'écran sur certains systèmes avec certains navigateurs les prendront parfaitement en compte, tandis que d'autres pas, donc il vaut mieux éviter.
IL y a des centaines de questions qui expliquent ça très bien sur stackoverflow.
Réactions ou précisions pêle-même sur les posts précédents.
Je confirme qu'il faut utiliser <s> ou <del> pour marquer le texte barré.
A noter que dans la plus pure des théories de sémantique, <del> est à utiliser pour indiquer quelque chose qui a été supprimé ou qui n'est plus valable, alors que <s> indique simplement un texte barré visuellement sans notion de suppression ou de non-validité.
C'est le même parralèle que <strong> vs. <b>, ou <em> vs. <i>, où avec les premiers on veut indiquer une importance, une mise en évidence, alors que pour les seconds on insiste sur la mise en forme plutôt que sur une mise en évidence.
Une application concrète de <i> par exemple, est que, par convention, les noms scentifiques latins des espèces animales ou végétales s'écrivent en italique. Dans ce cas-là, on doit utiliser <i> et non pas <em> car on ne veut en général pas particulièrement mettre le nom latin en évidence, on veut juste respecter la convention de mise en forme.
Pour en revenir à <del> vs. <s>, utiliser <del> me parait tout à fait approprié dans l'exemple du prix barré, dans le sens où ça représente une information qui était valable à un moment donné mais plus maintenant.
Dans le cas du diff, c'est évidemment aussi plutôt <del> qu'il faut utiliser, avec son pendant <ins> pour marquer le texte ajouté.
Les lecteurs d'écran ne font effectivement par défaut rien avec <del> et <ins>, mais on peut les configurer pour qu'ils prononcent le texte avec une autre voix, qu'un son soit joué, ou qu'ils disent quelque chose comme "texte barré" et "fin du texte barré".
Avec Jaws par exemple, cette configuration se passe dans les schémas de sons et de voix, c'est assez compliqué à configurer mais on peut faire pas mal de choses.
De même les + et - ne sont effectivement pas prononcés la plupart du temps dans la configuration par défaut, mais un petit réglage peut se faire dans la gestion des ponctuations.
La solution la plus accessible est donc effectivement d'utiliser du texte caché à l'écran, avec des classes CSS comme visually-hidden ou sr_only, précisant explicitement quelque chose comme "prix d'origine" ou "promotion".
Maintenant concernant ARIA, il ne faut jamais oublier que la règle n°1 d'ARIA et de ne pas l'utiliser si on peut éviter.
Ce n'est pas moi qui le dit, c'est écrit en clair dans les WCAG et l'authoring practice.
Certaines plate-formes et frameworks l'utilisent ou encouragent à l'utiliser beaucoup trop, alors qu'il existe souvent des solutions standard beaucoup plus simples aujourd'hui. ON peut faire pas mal de choses avec ARIA et des choses très bien, le gros problème c'est qu'il est aussi très très facile de casser complètement la'ccessibilité d'une application entière pour pas grand chose.
Exemple symtômatique, des aria-hidden=true|false qui se retrouvent un peu partout sans aucune raison autre qu'un copier-coller irréfléchi et/ou qu'une ignorance de ce que ça fait et/ou qu'un jemenfoutisme total, et qui, d'un seul coup d'un seul, réduisent tous les efforts d'accessibilité à néant.
C'est généralement bien pire quand ARIA est mal utilisé, plutôt que quand il n'est pas utilisé du tout, donc dans le doute, ne l'utilisez pas plutôt que de l'utiliser mal.
Enfin, pour info, vous ne pouvez être totalement certain que aria-label sera effectivement restitué que sur les éléments interactifs focusables (champs de formulaire, boutons, liens, etc.). et les landmarks.
Sur tous les éléments non-interactifs et non landmarks comme <div>, <span> ou <p>, certains lecteurs d'écran sur certains systèmes avec certains navigateurs les prendront parfaitement en compte, tandis que d'autres pas, donc il vaut mieux éviter.
IL y a des centaines de questions qui expliquent ça très bien sur stackoverflow.