Data-icon et accessibilité

Question 1: attention au fait que la propriété CSS Content est tout de même rendue par certains lecteurs d'écran. Donc les deux constructions que tu proposes risquent toutes deux de laisser apparaître des caractères parasites ou des « imprononçable ».

Selon moi, la propriété CSS Content est à bannir totalement: certains lecteurs d'écran la rendent alors que d'autres l'ignorent; il n'y a pas moyen de la faire rendre quand elle est ignorée, et il n'y a pas moyen de la faire ignorer quand elle est rendue. Donc dans tous les cas il y aura toujours au moins une configuration qui posera potentiellement problème.

Si l'exemple précis avec Content reproduisant le contenu de l'attribut data-XXX exposé par Raphaël dans son article fonctionne aujourd'hui, il ne fonctionnera peut-être plus demain; c'est ni plus ni moins qu'un genre de hack comme les patch CSS pour IE6, ce truc. Par ailleurs, sans avoir testé, je suis à peu près sûr que ton exemple corrigé casse l'astuce. Le bug réside très probablement dans le fait très précis de vouloir reproduire le contenu d'un attribut.

Je préconiserais à la place aria-hidden :

<a href="#"><span aria-hidden="true">T</span>Tralala pouêt pouêt</a>

Testé et approuvé avec jaws 14, NVDA 2013.2 et Voice Over iOS 7.0.3 en tout cas, et à mon avis bien plus certain que ça marchera toujours à plus ou moins long terme.

Question 2: oui, bien sûr !
Sous windows: NVDA http://nvda-fr.org/ gratuit
et
Jaws http://freedomscientific.com/ payant et très cher mais disponible en version de démonstration

Moins connus, il y a aussi Window Eyes distribué par GWMicro, Supernova/HAL distribué par Dolphin, Cobra distribué par Baume, ZoomText distribué par AISquaired (c'est avant tout une loupe mais il possède un module lecteur d'écran), narrator (le lecteur d'écran intégré à windows 8 -- piètre qualité). En tout il y a une douzaine de lecteurs d'écran pour windows.


Sur Mac: le lecteur d'écran gratuit intégré au système s'appelle Voice Over. Tu trouveras des informations sur comment l'activer, il y a aussi un raccourci du genre Pomme+une touche de fonction pour l'activer/désactiver à la volée. JE ne peux pas t'en dire plus, je n'ai pas de mac.

Sur iOS : il y a aussi Voice Over gratuit.
Selon comment le téléphone est paramétré, pour l'activer/désactiver, soit trois fois rapidement le bouton physique, ou alors dans réglages>général>accessibilité.

Pour Android: il y a Talkback gratuit.
Je ne connais pas ce système donc cherche sur le net pour savoir comment faire, on est censé pouvoir l'activer/désactiver assez facilement comme sur iOS.

Sous linux: tu peux avoir Orca avec ubuntu; si je me souviens bien il est quelque part dans le menu démarrer (qu'on ouvre avec Alt+F1). Mais peut-être qu'il a disparu depuis que j'ai testé (c'était ubuntu 10.04).
Modifié par QuentinC (01 Nov 2013 - 23:21)

salut,
je ne pense pas qu'il y ait une différence avec la construction classique ou celle que tu proposes. Perso j'utilise la même technique en insérant les caractères directement dans le HTML. J'ajoute cependant au niveau du CSS "speak:none". Je ne me suis pas énormément penché la dessus et je ne sais pas est-ce que cette propriété est prise en charge pas l'ensemble des lecteurs m'enfin...

Merci pour vos réponses, j'en attends encore d'autres si possible !

@QuentinC : merci pour tous les liens de lecteurs d'écran, j'ai déjà téléchargé NVADA et fais quelques tests (personnellement, je crois que je ne pourrais jamais m'habituer à ce genre de logiciel ).
Par rapport à ta remarque sur l'avenir de la technique que je présentais, je ne suis pas d'accord avec toi. Elle utilise un nouveau standard venu avec HTML5, à savoir l'attribut "data-", dont la valeur est récupéré via "content:attr(data-icon)" qui est une propriété existante depuis CSS2 (on utilisait déjà "content:attr(title)"), je pense alors qu'on a rien à craindre sur le futur de cette technique. Mais je suis d'accord quand tu dis que le fait qu'elle ne soit pas rendue relève peut-être d'une sorte de "bug" des lecteurs d'écran.
A propos de "aria-hidden", cela demande une nouvelle fois de "polluer" le html, ce qui était le cas avec les font-icon auparavant où l'on devait utiliser un <span>, ou <i>... Personnellement, dans mon agence nous utilisons un CMS qui génère parfois des balises HTML mais nous n'avons pas toujours accès à la source de cette balise, et donc je ne peux pas forcément ajouter le html souhaité....

@Zelalsan : merci pour ton retour, par rapport à la propriété "speak:none", IcoMoon (voir plus bas) l'ajoute également dans le CSS généré lors de la création d'une font-icon. Elle sera à l'avenir également la propriété la plus "propre" afin de garder une sémantique sans balises superflues, c'est donc, à mon humble avis, une bonne pratique

J'ai été voir du côté d'IcoMoon qui propose plusieurs librairies de font-icon, et également la possibilité de créer ses propres fonts-icon (pour ceux qui ne connaissent pas ). En ayant épluché la doc, je suis tombé sur ça, qui préconise donc la technique que je présentais (avec une vidéo explicative), mais en insérant bien la valeur du "content" directement dans le html :

<a href="#" data-icon="&#xe000;">
<span class="visuallyhidden">Home</span></a>

Dans l'exemple donné on permet également de rendre lisible une icône seule via la classe visuallyhidden (utile pour les icônes de retour à l'accueil par exemple qui n'ont généralement pas de texte associé visuellement, pour ceux que ça intéresse) :

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
}

Je crois donc que la technique que je présentais, mais en insérant la valeur de l'icône directement en HTML, se démocratise et est donc une technique testée et approuvée. Je crois donc que je vais modifier mon code pour m'y tenir.
Je viens de trouver un article sur CSS Tricks, combinant à la fois l'attribut "data-" et "aria-hidden". J'ai posté un commentaire afin d'obtenir d'autres avis sur la question, je vous tiens au courant.

a écrit :
Par rapport à ta remarque sur l'avenir de la technique que je présentais, je ne suis pas d'accord avec toi. Elle utilise un nouveau standard venu avec HTML5, à savoir l'attribut "data-",

Le problème n'est pas les attributs data de HTML5, mais la propriété Content: personne n'a jamais clairement défini si le contenu qu'il représentait devait être rendu dans un lecteur d'écran ou non. Donc chaque lecteur fait ce qu'il veut: jaws ne le rend jamais; NVDA et VO le rendent toujours.
Le problème c'est que tout le monde a raison:
- Si je me range du côté jaws, la logique sera: c'est du CSS, donc de la présentation; tout ce qui relève de la présentation n'a pas à être rendu.
- Si je me range du côté NVDA et VO, la logique, c'est la suivante: un lecteur d'écran, comme son nom l'indique, est fait pour lire ce qui se trouve à l'écran. LE contenu généré par Content est affiché à l'écran, donc il doit être lu (c'est surtout Apple qui a ce crédo)

En l'occurence le comportement de NVDA et de VO est clair: ils lisent systématiquement le contenu généré par Content. Si pour un cas précis et une version précise rien n'est rendu, c'est que c'est un bug. SE fier sur des bugs, c'est risquer un comportement aléatoire dès qu'une prochaîne version du navigateur et/ou du lecteur d'écran sort.

Les ingénieurs du W3C n'ont pas pensé à ce gros problème quand ils ont inventé la propriété CSS Content. Mais en réalité c'est une propriété battarde. Posez-vous seulement cette question et vous verrez où je veux en venir: le contenu généré par la propriété CSS Content, est-ce de la présentation, ou du contenu ?

Désolé de vous décevoir, mais après un test rapide avec NVDA et firefox dernières versions publiquement disponibles :

<html><head>
<title>Test</title>
<style type="text/css">
#p1:before { 
font-family: Windings;
Content: "T"; 
}
#p2:before { 
font-family: Windings;
Content: attr(data-content); 
}
</style>
</head><body>
<p id="p1">Paragraphe 1</p>
<p id="p2" data-content="T">Paragraphe 2</p>
</body></html>

Dans les deux cas le T est prononcé...
J'en conclus donc que ce hack n'est plus valable, ou alors que ses conditions exactes de fonctionnement sont extrêmement sensibles. La solution la plus durable et la plus fiable est par conséquent aria-hidden, qui marche à tous les coups.
Modifié par QuentinC (02 Nov 2013 - 17:17)

Je viens également de tester ton code qui effectivement est bien lu par le lecteur d'écran. CEPENDANT, en passant comme valeur l'unicode d'une font-icon :

*soit dans le html de type " data-icon='&#xe600' " et la récupérer via "content:attr(data-icon)" en CSS
*soit en passant une valeur de type "data-icon='icon-pen'" dans le html, puis lui associer une valeur dans le css de type " content:'\e600' "

Cela n'est pas repris par le lecteur d'écran. J'ai l'impression que lorsque la valeur du "content" n'est pas reconnu comme un mot, il n'en tient pas compte... J'ai fais seulement le test avec NVDA car je ne peux tester VoiceOver et autres...

Mais on peut quand même noter que cette technique n'est pas obsolète ! Si certains d'entre vous peuvent faire le test avec d'autres lecteurs qu'ils ont à leur disposition... En testant notamment cette page.
Pour le aria-hidden, je ne suis pas du tout contre son utilisation, mais simplement ajouter du html "superflu" pour cela me semble laborieux....

Quand à ta remarque sur "design" ou "contenu" pour le "content", je dirai le maître mot du domaine du web : "ça dépend" , cette propriété peut à la fois être utilisée pour générer du contenu, mais aussi appliqué des background, ou encore lui appliquer une valeur vide et générer des éléments de design en css (ombre portée, triangle css sur une liste à puce...). Je ne pense donc pas que tel ou tel lecteur d'écran a "raison", mais que justement leur parti pris nous posent désormais des problèmes pour respecter l'accessibilité d'un site web...
Modifié par hd7 (02 Nov 2013 - 18:07)

a écrit :
Je viens également de tester ton code qui effectivement est bien lu par le lecteur d'écran. CEPENDANT, en passant comme valeur l'unicode d'une font-icon, cela n'est pas repris par le lecteur d'écran. J'ai l'impression que lorsque la valeur du "content" n'est pas reconnu comme un mot, il n'en tient pas compte...

Tu fais erreur. Observes mieux, plus attentivement, et tu verras qu'il y a bien un caractère inconnu qui n'est soit pas prononcé, soit indiqué comme étant « inprononçAble » lorsqu'on passe dessus avec les flèches.

a écrit :
Mais on peut quand même noter que cette technique n'est pas obsolète ! Si certains d'entre vous peuvent faire le test avec d'autres lecteurs qu'ils ont à leur disposition... En testant notamment cette page.

... et je renchéris en te disant que ces caractères inconnus peuvent donner lieu à des bugs de prononciation. Dans cet exemple, écoutes attentivement et tu verras qu'il dit "Lien? blog" et non pas "lien blog" en faisant une pause et en augmentant le ton de la voix comme s'il y avait réellement une virgule ou un point d'interrogation. Minime, certes, mais si ton site en est truffé, ça peut devenir un peu gênant.

Mais en fait c'est surtout gênant pour les braillistes, qui, eux, peuvent réellement lire un caractère parasite. Ne pas oublier que sur le web, il y a trois principaux profils de non-voyants: ceux qui fonctionnent à la voix uniquement, comme moi, ceux qui lisent en braille uniquement, et ceux qui font un peu les deux.

Tant qu'à faire de l'accessibilité, autant aller jusqu'au bout.

a écrit :
Quand à ta remarque sur "design" ou "contenu" pour le "content", je dirai le maître mot du domaine du web : "ça dépend"

Bonne réponse ! ET c'est là justement le problème.

a écrit :
Je ne pense donc pas que tel ou tel lecteur d'écran a "raison", mais que justement leur parti pris nous posent désormais des problèmes pour respecter l'accessibilité d'un site web...

Ce n'est pas les lecteurs d'écran les fautifs, aucune des deux interprétations n'est ni complètement juste, ni complètement fausse; les deux ont de bons arguments. Si le standard ne te dis pas quoi faire, tu fais ce que tu veux, c'est aussi simple que ça... à comparer avec les nombreux cas de « undefined behaviors » (comportements indéfinis) du standard C; les compilateurs ont pris leurs libertés, et en général aucun n'a foncièrement tort.

Je le dis et je le répète (et j'assume), Content a été une erreur de conception depuis le début.
Je m'explique: on clame, en gros résumé, il me semble, assez fort, que le contenu, c'est HTML; la présentation c'est CSS, et le comportement c'est JavaScript. "Content" veut dire ... "Contenu". Déjà là, cherchez ll'erreur. Dans les faits, Content est utilisé pour quoi ? ajouter un peu de texte avant ou après un élément. Pourquoi c'est pas dans le HTML alors ? Le texte par définition c'est du contenu; donc ça n'a rien à faire dans une feuille CSS.

a écrit :
, cette propriété peut à la fois être utilisée pour générer du contenu,

Le contenu, ça n'a rien à faire dans une feuille CSS

a écrit :
mais aussi appliqué des background,

IL y a plus simple il me semble, surtout avec CSS3

a écrit :
(ombre portée,

IL y a text-shadow.

a écrit :
triangle css sur une liste à puce...)

Là par contre je t'accorde que pour celui-là, les concepteurs de CSS ont oublié un mécanisme pour le faire proprement. Ils auraient pu rajouter des choses du genre list-item-text et list-item-text-font. Parce que là, c'est bien de la présentation qui ne devrait pas être présente dans le code HTML.

Je vais finir ce long post (désolé) en disant qu'en fait, tout n'est pas perdu, tes petites icônes sont parfois bel et bien du contenu qui devrait être rendu plus clairement par les lecteurs d'écran. Par exemple, je vois de plus en plus de sites qui utilisent des flèches en caractère unicode pour la pagination plutôt que des images de flèches. C'est très bon pour l'accessibilité ça, car un texte est forcément plus accessible qu'une image (je pense aux malvoyants qui utilisent des loupes d'écran et qui ont le problème des images pixélisées en étant agrandies, là où le texte s'agrandit sans problème; et ceux qui doivent imposer des couleurs bien précises pour leur confort, car le texte peut changer de couleur sans problème alors que les images beaucoup moins).

Le souci, c'est que ces caractères unicode ne sont par défaut pas reconnus par les lecteurs d'écran. Donc un lien qui n'est constitué que d'une simple flèche en unicode ne voudra juste rien dire du dout, alors que c'est du vrai contenu qui devrait être intelligible.

Là, par contre, la solution n'est pas du côté des standards web, mais des lecteurs d'écran. Ils devraient tous intégrer d'office les caractères les plus courants dans leurs dictionnaires. J'ai déjà commencé de le faire chez moi mais il y en a tellement que c'est quasiment mission impossible. Par exemple j'ai mappé &larr; en « flèche gauche », et maintenant je peux reconnaître les liens de pagination modernes facilement alors qu'avant c'était juste des liens vides. ET ça sans attendre que le webmaster du site ne daigne bien ajouter un quelconque texte alternatif, c'est surtout ça qui est génial.

Si la désignation de ce caractère était présent dans tous les dictionnaires de tous les lecteurs d'écran, ce serait toujours une chose en moins à penser pour le webmaster, et donc moins de problèmes potentiels.

Si quelqu'un a ajouté des icônes twitter, facebook & co dans les tables unicode, c'est très bien. Par contre ce serait encore mieux si tous ces codes étaient listés quelque part pour qu'on puisse les faire reconnaître par les lecteurs d'écran, à terme.

Message au concepteur de ces polices d'icônes: merci d'utiliser des zones unicodes propres et de ne surtout pas réutiliser ce qui existe déjà et surtout pas des caractères ASCII; sinon vous allez jeter la confusion et la technique des dictionnaires sera inutilisable.
Modifié par QuentinC (03 Nov 2013 - 00:37)