Je me corrige concernant le @src : ça fera deux conditions au lieu d'une
mais ça change pas grand chose.
Romain
Le 23 avril 2015 16:36, Romain Gervois <cont...@romaingervois.fr> a écrit :
> Bonjour,
>
>
>
>
> *Olivier a écrit : "Deux lignes? Peut-être, si tu as déjà une librairie
> chargée qui permet de condenser le code nécessaire pour parcourir le DOM,
> lister les éléments IMG, comparer @src et @alt (en n'oubliant pas de
> traiter les chaines pour éviter les blagues liées aux caractères spéciaux
> et autres scories de nommage de fichiers dans différents OS), remplacer
> l'un par l'autre. En ne se plantant pas sur le moment où on le fait, pour
> être sûr que l'image modifiée soit bien celle consultée par la TA via l'API
> d'access du client. Mais sinon, oui...Ah, attends, si des images sont
> insérées dynamiquement dans le DOM, genre sur un flux d'actus?Ou si on a
> plusieurs versions de l'image dans un contexte de RWD? Faut détecter
> l'événement et relancer la routine, non? Si tu sais faire ça en deux
> lignes, sans tester, je veux bien le code."*
>
> Les 2 lignes c'est une façon de parler, je remplace par "une fonction de
> quelques lignes" ça te convient mieux ?
> Et sans librairie (derrière au final ça fait la même chose que sans
> hein... donc pour ton histoire du chargement c'est encore pire).
> Et je ne comprends rien à ce que tu m'expliques là : que vient faire la
> source de l'image là dedans ? que vient faire le moment de l'exécution
> (événementiel ou autre) ? quel rapport avec le responsive ? quel rapport
> avec la TA ? Le problème est identifié, non ?
> Si tu cherches à me faire dire que ça demande des compétences de
> développeur, je te le confirme si tu avais un doute.
> Et enfin, la remarque sur le test, là encore je ne vois pas le rapport :
> un test n'est pas dépendant d'un nombre de lignes.
>
> Donc oui, l'accessibilité ce n'est pas que de l'orthographe et ça a donc
> un coût et si pas de budget, on peut compter sur autre chose pour que ce
> soit fait (ce que j'ai appelé convictions, le terme peut être différent si
> on veut : sérieux, l'implication ou autres, bref). On peut se cacher les
> yeux mais c'est comme ça (et ça ne veut pas dire que je suis un partisan de
> ces modes de prod, très loin de là).
>
>
>
> *Olivier : "Et, oui, bien sûr, ne documentons pas cela. Cela n'arrive
> jamais qu'un bout de code, au rôle mystérieux pour quiconque sauf celui qui
> l'a écrit, traine des années dans le code sans que personne n'ose jamais le
> supprimer, y compris lorsqu'il est rendu obsolète par une autre évol. Et
> d'ailleurs, ne documentons rien, jouons-la hard core, c'est nettement plus
> fun."*
>
> Je ne me rappelle pas avoir écrit qu'il ne fallait pas documenter (comme
> je n'ai jamais dit que 2 lignes de code ça ne se teste pas). Je n'ai rien
> écrit de la sorte mais bon (j'adore le fait de faire reposer ce genre de
> problèmes sur le développeur ermite et asocial qui veut garder son code
> mystérieux).
>
> Olivier a écrit : "Pure conjecture, on ne sait pas comment est monté ce
> projet. Si chaque page (ou groupe de pages) charge la même quantité de JS
> quelque soit le contenu, et les fonctionnalités, il y a sans doute aussi un
> problème..."
>
> Certes, on a pas toutes les infos mais là encore je ne vois pas le
> problème avec ce qui nous intéresse (tu parles perfs là ça reste
> intéressant mais bon).
>
> *Olivier a écrit : "C'est pas ça qui va faire tomber le serveur, sûr...
> mais on n'a pas non plus d'indication sur le volume traité, ni sur la
> politique de cache. Mais je parlais surtout du fait que l'on va boucler sur
> le DOM à chaque page (pour *RIEN*, dans 100-epsilon% des cas). On n'a pas
> d'indication sur la taille des pages, ni sur la profondeur du DOM, ni sur
> le nombre d'images par page. Si on refait une passe à chaque màj du DOM, en
> plus... Surfant sur une machine trop courte en mémoire, je peux te dire que
> je sens la différence entre une page codée avec les pieds et une autre."*
>
> Même chose qu'au-dessus (et je n'ai pas parlé de code mal foutu). Après,
> le gros taff se fait côté du navigateur. Je ne suis pas un spécialiste de
> la perf mais du traitement d'attributs il doit falloir y aller très fort
> pour sentir quelque chose sur le client.
>
>
> *Olivier a écrit : "Mon propos n'est pas que ce type de modif n'est pas à
> faire, mais que c'est une solution à comparer (coût, impact utilisateur,
> contribution aux emmerdes futures) à celle qui consiste à corriger le bug à
> la source; et à celle consistant à ne rien faire. Pas sûr que la JS
> gagne.Ah j'oubliais: évidemment, si la page est consultée via une
> extraction du contenu, par un agrégateur ou autre, ben ça va être coton
> pour avoir le bon alt."*
>
> L'avantage de la solution JS est d'être indépendante de la base même de
> l'outil. Bon après faut peut être aussi faire confiance aux techniciens
> pour savoir juger de ça... Concernant, l'extraction ou l'agrégateur ça peut
> se baser sur une source générée aussi.
>
> *Olivier a écrit : "J'ai lu un article où un développeur de Yammer
> expliquait qu'il avait codé une feature en une heure; et qu'il avait passé
> environ 20h à la documenter et l'expliquer à ses collègues pour qu'ils
> l'utilisent dans leur code. Avec en conclusion: la simplicité n'est jamais
> qu'apparente, dès que l'on ajoute quelque chose il faut être conscient que
> l'on ajoute des couches et des couches de complexité."*
>
> Faut remettre dans le contexte : comparé une feature à un patch
> temporaire...
>
> *Olivier a écrit : "Je me rappelle aussi cet audit où lorsque j'ai fait
> une préco toute simple sur les alt, le client m'a dit qu'avec 6000 images
> dans la médiathèque, j'allais le rendre fou. Qu'adviendra-t-il sur ce
> projet lorsque, ben, finalement l'accessibilité devient une exigence, et
> qu'il faudra se recogner l'ensemble des images déjà contribuées pour mettre
> le bon alt? On a le droit de s'en foutre... ou pas."*
>
> Oui, même sur une minuscule implémentation, ça peut arriver (je ne connais
> personne se disant heureux d'avoir à corriger des choses chiantes) donc je
> ne comprends pas la démonstration par rapport à ce cas : c'est chiant c'est
> tout. Tu transformes le problème, il s'agit d'images de décoration avec
> alt=" ", la question de la pertinence ne pourra se poser que si un
> changement fonctionnel de ces images intervient.
>
> Romain
>
>
>
> Le 23 avril 2015 15:31, Olivier Nourry <olv.nou...@gmail.com> a écrit :
>
>> Bonjour Romain,
>>
>>
>>
>> *Romain a écrit:"Ce qui est recherché c'est du mesurable, mettre des
>> tâches dans des cases ("acte technique" ou autre peu importe) et
>> pouvoir les estimer pour les facturer et gérer des budgets ; ça ne va pas
>> plus loin que ça. Aller plus loin c'est avoir des convictions."*
>>
>> Justement, mon propos est que l'accessibilité dans un développement n'est
>> *pas* mesurable. Si ça l'était, on serait capable de sortir des métriques
>> fiables, depuis le temps qu'on essaye... Mon parallèle avec l'orthographe
>> sert à illustrer cela: l'orthographe a un coût (celui investi - et c'est
>> colossal - pour apprendre la langue; le temps passé à relire et corriger;
>> mais aussi l'argent investi pour développer des outils genre correcteurs
>> orthographiques, que nous payons via les logiciels). Pourtant on est bien
>> en peine de budgéter cet aspect d'un projet.
>> Ta conclusion "aller plus loin c'est avoir des convictions", c'est joli,
>> ça claque; mais pour être honnête je n'ai pas compris où tu veux en venir.
>>
>>
>> *Romain a écrit: "**La coder c'est deux lignes. La documenter ? La
>> tester ? Bon soyons fous, on le fait c'est pas bien long sur un tel truc."*
>>
>> Deux lignes? Peut-être, si tu as déjà une librairie chargée qui permet de
>> condenser le code nécessaire pour parcourir le DOM, lister les éléments
>> IMG, comparer @src et @alt (en n'oubliant pas de traiter les chaines pour
>> éviter les blagues liées aux caractères spéciaux et autres scories de
>> nommage de fichiers dans différents OS), remplacer l'un par l'autre. En ne
>> se plantant pas sur le moment où on le fait, pour être sûr que l'image
>> modifiée soit bien celle consultée par la TA via l'API d'access du client.
>> Mais sinon, oui...
>> Ah, attends, si des images sont insérées dynamiquement dans le DOM, genre
>> sur un flux d'actus? Ou si on a plusieurs versions de l'image dans un
>> contexte de RWD? Faut détecter l'événement et relancer la routine, non?
>> Si tu sais faire ça en deux lignes, sans tester, je veux bien le code.
>>
>> Et, oui, bien sûr, ne documentons pas cela. Cela n'arrive jamais qu'un
>> bout de code, au rôle mystérieux pour quiconque sauf celui qui l'a écrit,
>> traine des années dans le code sans que personne n'ose jamais le supprimer,
>> y compris lorsqu'il est rendu obsolète par une autre évol. Et d'ailleurs,
>> ne documentons rien, jouons-la hard core, c'est nettement plus fun.
>>
>>
>>
>> *Romain a écrit: "**Concernant le déploiement sur toutes les pages, les
>> systèmes de templates facilitent grandement le travail."*
>> Pure conjecture, on ne sait pas comment est monté ce projet. Si chaque
>> page (ou groupe de pages) charge la même quantité de JS quelque soit le
>> contenu, et les fonctionnalités, il y a sans doute aussi un problème...
>>
>> *Romain a écrit: "**En ce qui concerne le téléchargement, on parle d'un
>> script de deux lignes mis en cache au premier appel. Quand on commencera à
>> s'intéresser aux perfs sur des scripts aussi ridicules c'est qu'on aura
>> fait un bon de géant dans nos productions."*
>> C'est pas ça qui va faire tomber le serveur, sûr... mais on n'a pas non
>> plus d'indication sur le volume traité, ni sur la politique de cache. Mais
>> je parlais surtout du fait que l'on va boucler sur le DOM à chaque page
>> (pour *RIEN*, dans 100-epsilon% des cas). On n'a pas d'indication sur la
>> taille des pages, ni sur la profondeur du DOM, ni sur le nombre d'images
>> par page. Si on refait une passe à chaque màj du DOM, en plus... Surfant
>> sur une machine trop courte en mémoire, je peux te dire que je sens la
>> différence entre une page codée avec les pieds et une autre.
>>
>>
>> Mon propos n'est pas que ce type de modif n'est pas à faire, mais que
>> c'est une solution à comparer (coût, impact utilisateur, contribution aux
>> emmerdes futures) à celle qui consiste à corriger le bug à la source; et à
>> celle consistant à ne rien faire. Pas sûr que la JS gagne.
>> Ah j'oubliais: évidemment, si la page est consultée via une extraction du
>> contenu, par un agrégateur ou autre, ben ça va être coton pour avoir le bon
>> alt.
>>
>>
>> *Romain a écrit: "**Enfin, j'ai beau retourné la chose dans tous les
>> sens, je ne vois pas comment un truc non fonctionnel (remplacer un " " par
>> "") peut impacter quoi que ce soit dans le fonctionnement d'un module (sauf
>> si il fait des choses en se basant sur un attribut alt " ").*
>> Non, utiliser un espace pour signaler un champ vide puis compter sur le
>> script pour rattraper le coup, ça c'est totalement à éviter (la solution
>> d'Aurélien me parait préférable, à tout prendre). Parce que ça veut dire
>> qu'on impose une règle (absurde) aux contributeurs, donc qu'on la...
>> documente (ha ha), l'explique et qu'on fait le pari que tous les
>> utilisateurs vont l'appliquer. Et revenir en arrière, et oublier tout ça
>> quand on finit par faire évoluer le module. 100% de chances que ça génère
>> moult problèmes.
>>
>> J'ai lu un article où un développeur de Yammer expliquait qu'il avait
>> codé une feature en une heure; et qu'il avait passé environ 20h à la
>> documenter et l'expliquer à ses collègues pour qu'ils l'utilisent dans leur
>> code. Avec en conclusion: la simplicité n'est jamais qu'apparente, dès que
>> l'on ajoute quelque chose il faut être conscient que l'on ajoute des
>> couches et des couches de complexité.
>>
>> Je me rappelle aussi cet audit où lorsque j'ai fait une préco toute
>> simple sur les alt, le client m'a dit qu'avec 6000 images dans la
>> médiathèque, j'allais le rendre fou. Qu'adviendra-t-il sur ce projet
>> lorsque, ben, finalement l'accessibilité devient une exigence, et qu'il
>> faudra se recogner l'ensemble des images déjà contribuées pour mettre le
>> bon alt? On a le droit de s'en foutre... ou pas.
>>
>>
>>
>> Cordialement,
>>
>> [image: --]
>> Olivier Nourry
>> [image: http://]about.me/oliviernourry
>> <http://about.me/oliviernourry>
>>
>>
>> Le 23 avril 2015 12:00, Romain Gervois <cont...@romaingervois.fr> a
>> écrit :
>>
>>> Bonjour,
>>>
>>> "Pardon, mais j'ai un peu de mal avec cet argument ... Isoler
>>> l'accessibilité en tant qu'acte technique revient à en faire un élément
>>> optionnable, ce qui est le meilleur moyen d'en faire un élément optionné.
>>> Ce qui distingue l'accessibilité du reste, c'est qu'il y a des situations
>>> où elle n'est pas négociable..."
>>>
>>> Ce qui est recherché c'est du mesurable, mettre des tâches dans des
>>> cases ("acte technique" ou autre peu importe) et pouvoir
>>> les estimer pour les facturer et gérer des budgets ; ça ne va pas plus
>>> loin que ça. Aller plus loin c'est avoir des convictions.
>>>
>>> "Je ne suis pas fan de la solution JS. Déjà, il faudrait la coder, la
>>> documenter, la tester (on prend sur le "budget rustines" pour cela?),
>>> l'implémenter sur toutes les pages... Plus l'imposer à chaque
>>> téléchargement de page, et la faire tourner sur chaque page, pour tous les
>>> utilisateurs. Tout ça pour? De plus, que se passera-t-il lorsque le module
>>> évoluera? Qu'il aura un autre comportement qui mettra en échec le bout de
>>> JS bricolé? AMHA, il faut soit faire la correction dans les règles (donc à
>>> la racine), soit ne rien faire."
>>>
>>> La coder c'est deux lignes. La documenter ? La tester ? Bon soyons fous,
>>> on le fait c'est pas bien long sur un tel truc.
>>>
>>> Concernant le déploiement sur toutes les pages, les systèmes de
>>> templates facilitent grandement le travail.
>>>
>>> En ce qui concerne le téléchargement, on parle d'un script de deux
>>> lignes mis en cache au premier appel. Quand on commencera à s'intéresser
>>> aux perfs sur des scripts aussi ridicules c'est qu'on aura fait un bon de
>>> géant dans nos productions.
>>>
>>> Enfin, j'ai beau retourné la chose dans tous les sens, je ne vois pas
>>> comment un truc non fonctionnel (remplacer un " " par "") peut impacter
>>> quoi que ce soit dans le fonctionnement d'un module (sauf si il fait des
>>> choses en se basant sur un attribut alt " ").
>>>
>>> Bref, la solution JS me semble tout à fait pertinente dans ce cas (tout
>>> en remontant et en attendant des retours côté éditeur).
>>> Le tout ou rien, bof bof (on ne parle quand même pas d'un patch
>>> monstrueux d'une webapp là).
>>>
>>> Romain
>>>
>>> Le 23 avril 2015 11:00, Olivier Nourry <olv.nou...@gmail.com> a écrit :
>>>
>>>> Bonjour Nathalie,
>>>>
>>>> *"Il n'y a pas de ligne budgétaire pour l'accessibilité."*
>>>> Pardon, mais j'ai un peu de mal avec cet argument. Le module est buggé;
>>>> il faut donc traiter le bug, c'est-à-dire évaluer son impact (=le coût de
>>>> l'inaction), son coût de correction, et prendre une décision en fonction de
>>>> ces éléments. Point. Si l'impact est plus important que le coût, c'est à
>>>> corriger, sinon, on laisse en l'état. Personnellement je n'ai pas de
>>>> scrupule à laisser un bug qui ne dérange personne (*se couvre la tête avec
>>>> les bras pour se protéger des projectiles lancés par les
>>>> jusqu'au-boutistes*). Car l'argent dépensé ici pour rien aurait pu être
>>>> investi de manière plus utile sur un problème plus impactant. Le fait
>>>> d'avoir budgété ou non l'accessibilité (on va en reparler plus bas) n'a pas
>>>> grand chose à voir là-dedans. Note: dans les impacts, ne pas oublier tout
>>>> ce qui n'est pas accessibilité, genre SEO, dette technique et connexions
>>>> bas débit.
>>>>
>>>> Je n'ignore pas les contraintes du terrain et la difficulté qu'il y a à
>>>> faire le job de CP (je l'ai été), où l'on est redevable des remises
>>>> accordées par un commercial qui empoche sa prime tandis que l'équipe se
>>>> fait engueuler pour avoir dépassé la charge qu'elle avait évaluée comme
>>>> insuffisante. Mais cette excuse du "budget accessibilité" est fumeuse, pour
>>>> rester poli. Y a-t-il un budget "orthographe"? Un budget "commentaires
>>>> du code"? Un budget "réduction de la dette technique"? J'en doute. Pourtant
>>>> tout designer/CP/contributeur/développeur conscient de sa responsabilité va
>>>> agir dans le bon sens. Pas de raison qu'il en soit autrement pour
>>>> l'accessibilité. Nous sommes tous bien placés sur cette liste pour savoir
>>>> que l'accessibilité requiert une compétence spécifique, acquise via de la
>>>> formation et l'expérience... Mais il en va de même de toute composante de
>>>> ce que l'on appelle, pour faire simple, un travail de qualité. Isoler
>>>> l'accessibilité en tant qu'acte technique revient à en faire un élément
>>>> optionnable, ce qui est le meilleur moyen d'en faire un élément optionné.
>>>> Ce qui distingue l'accessibilité du reste, c'est qu'il y a des situations
>>>> où elle n'est pas négociable...
>>>>
>>>> Et comment budgète-t-on l'accessibilité dans un développement? Je fais
>>>> ce métier depuis 8 ou 9 ans. J'ai accompagné 15 ou 20 projets, je forme des
>>>> chefs de projets à l'accompagnement, j'ai obtenu ou contribué à obtenir 6
>>>> labels AccessiWeb. Mais je suis toujours bien incapable de dire ce que
>>>> coûte l'accessibilité, réellement... Tout comme je ne sais pas ce que coûte
>>>> une bonne orthographe. Je peux isoler des interventions dont le coût est
>>>> directement et uniquement imputable à l'accessibilité... mais c'est tout.
>>>> Pour moi cette notion de "ligne budgétaire pour l'accessibilité" est
>>>> artificielle, et dangereuse.
>>>>
>>>>
>>>>
>>>> Je ne suis pas fan de la solution JS. Déjà, il faudrait la coder, la
>>>> documenter, la tester (on prend sur le "budget rustines" pour cela?),
>>>> l'implémenter sur toutes les pages... Plus l'imposer à chaque
>>>> téléchargement de page, et la faire tourner sur chaque page, pour tous les
>>>> utilisateurs. Tout ça pour? De plus, que se passera-t-il lorsque le module
>>>> évoluera? Qu'il aura un autre comportement qui mettra en échec le bout de
>>>> JS bricolé? AMHA, il faut soit faire la correction dans les règles (donc à
>>>> la racine), soit ne rien faire.
>>>>
>>>>
>>>> Cordialement,
>>>>
>>>> [image: --]
>>>> Olivier Nourry
>>>> [image: http://]about.me/oliviernourry
>>>> <http://about.me/oliviernourry>
>>>>
>>>>
>>>> Le 22 avril 2015 13:31, Nathalie Le Pontois - AE <
>>>> nathalielepont...@gmail.com> a écrit :
>>>>
>>>>> Je suis le prestataire. Nous installons un module communautaire. Le
>>>>> modifier implique que les mises a jour ne sont plus possibles sauf si la
>>>>> modification est impactée sur le module dans sa version communautaire.
>>>>> Il n'y a pas de ligne budgétaire pour l'accessibilité.
>>>>>
>>>>> Nathalie Le Pontois
>>>>>
>>>>> Le 22 avr. 2015 à 13:28, Ariane Pro <ariane.andur...@gmail.com> a
>>>>> écrit :
>>>>>
>>>>> Surtout que le prestataire gagnerait à l'implémenter sur son
>>>>> composant pour améliorer son produit...
>>>>>
>>>>> --
>>>>> Ariane Pro
>>>>> Envoyé avec Sparrow <http://www.sparrowmailapp.com/?sig>
>>>>>
>>>>> Le mercredi 22 avril 2015 à 12:19, Antoine Bouet a écrit :
>>>>>
>>>>> A ce que je vois, tous les prestataires ne sont pas généreux avec
>>>>> leurs clients, c'est dommage car ca ne me parait pas être de grosses
>>>>> modifications ...
>>>>>
>>>>> Cordialement,
>>>>>
>>>>> Antoine Bouet
>>>>> Ingénieur Développement
>>>>> Expert AccessiWeb en Evaluation
>>>>>
>>>>> CIMEOS
>>>>> Montbéliard - Besançon - Paris
>>>>>
>>>>> e-mail : antoine.bo...@cimeos.com
>>>>> tel. : +33(0)9 72 30 72 42
>>>>>
>>>>> www.cimeos.com
>>>>>
>>>>> COORDONNEES DU SUPPORT :
>>>>> Hébergement et Nom de Domaine : supp...@cimeos.com / 0899 49 42 00
>>>>> (1.34€/appel puis 0.34/min)
>>>>> Maintenance des sites : maintena...@cimeos.com
>>>>> Le 22/04/2015 12:16, Nathalie Le Pontois - AE a écrit :
>>>>>
>>>>> Je ne serai pas contre si mon budget me le permettait.. Ce n'est
>>>>> malheureusement pas le cas.
>>>>>
>>>>> Nathalie Le Pontois
>>>>>
>>>>> Le 22 avr. 2015 à 11:49, Antoine Bouet <antoine.bo...@cimeos.com> a
>>>>> écrit :
>>>>>
>>>>> Bonjour à tous,
>>>>>
>>>>> En même temps, quitte à intervenir autant modifier l'extension
>>>>> générant cette "absurdité" plutôt que de rajouter une couche
>>>>> supplémentaire
>>>>> en JS qui peut avoir des dommages collatéraux non prévus.
>>>>>
>>>>> Après ce n'est que mon point de vue :)
>>>>>
>>>>>
>>>>> Cordialement,
>>>>>
>>>>> Antoine Bouet
>>>>> Ingénieur Développement
>>>>> Expert AccessiWeb en Evaluation
>>>>>
>>>>> CIMEOS
>>>>> Montbéliard - Besançon - Paris
>>>>>
>>>>> e-mail : antoine.bo...@cimeos.com
>>>>> tel. : +33(0)9 72 30 72 42
>>>>>
>>>>> www.cimeos.com
>>>>>
>>>>> COORDONNEES DU SUPPORT :
>>>>> Hébergement et Nom de Domaine : supp...@cimeos.com / 0899 49 42 00
>>>>> (1.34€/appel puis 0.34/min)
>>>>> Maintenance des sites : maintena...@cimeos.com
>>>>> Le 22/04/2015 11:35, Philippe Vayssière a écrit :
>>>>>
>>>>> Bonjour,
>>>>>
>>>>> étant donné les contraintes côté serveur, peut-être un correctif
>>>>> JavaScript destiné à cacher l'image aux lecteurs d'écran ferait-il tout de
>>>>> même l'affaire ?
>>>>> Pour toutes les images ayant un alt=" " (ou espace insécable ou
>>>>> apparenté ou mieux un test "*n'est composé que d'espace(s)*" via un
>>>>> trim()
>>>>> <http://stackoverflow.com/questions/498970/trim-string-in-javascript>
>>>>> ), attribuer un alt="" et/ou peut-être aria-hidden="true"
>>>>>
>>>>>
>>>>> Bonne journée,
>>>>> Ph. Vayssière
>>>>> --
>>>>> alsacreations.fr - alsacreations.com
>>>>>
>>>>> Le 22/04/2015 11:25, Nathalie Le Pontois - AE a écrit :
>>>>>
>>>>> Bonjour et merci beaucoup de cette réponse.
>>>>> Le module utilisé nous bloque. Il faudrait le recoder mais bien
>>>>> évidemment, nous n'avons pas le budget pour.
>>>>> Il n'y a pas de demande d'accessibilité sur ce site. Mais tant que
>>>>> faire se peut, j'essaye toujours de faire en sorte que les critères
>>>>> simples
>>>>> soient implémentés de base.
>>>>> Dans ce cas, j'imagine cependant qu'entendre "graphique" est plus
>>>>> acceptable que d'entendre la lecture du nom du fichier ...
>>>>>
>>>>> Nathalie Le Pontois
>>>>> 0637731973
>>>>> nlepont...@gmail.com
>>>>>
>>>>> Le 22 avr. 2015 à 08:34, Frédéric Halna <hal...@gmail.com> a écrit :
>>>>>
>>>>> Bonjour Nathalie,
>>>>>
>>>>> Malheureusement un alt avec un espace n'est pas équivalent à un alt
>>>>> vide.
>>>>>
>>>>> Nvda par exemple ne vocalisera pas du tout une image dont
>>>>> l'alternative est vide. L'image est décorative et donc l'utilisateur de
>>>>> lecteur d'écran ne sera pas averti de sa présence.
>>>>>
>>>>> Dans le cas d'une image avec une alternative composée d'un espace,
>>>>> NVDA vocalisera "graphique" sans plus d'information.
>>>>>
>>>>>
>>>>> quel est le frein à pouvoir implémenter des alternatives vides ?
>>>>>
>>>>>
>>>>> Bonne journée.
>>>>>
>>>>> Frédéric.
>>>>>
>>>>> Le 21 avril 2015 16:56, Nathalie Le Pontois - AE <
>>>>> nathalielepont...@gmail.com> a écrit :
>>>>>
>>>>> Bonjour,
>>>>>
>>>>> Sur un projet, nous utilisons une médiathèque qui, lorsqu'elle affiche
>>>>> les images, met par défaut le nom du fichier image dans le alt et le title
>>>>> si les champs sont laissés vides.
>>>>> Je m'interroge sur le rendu sonore des lecteurs d'écran si le alt
>>>>> prend la valeur d'un espace (renseigné dans le bo).
>>>>> Est ce que le lecteur d'écran le lit ou l'évite ?
>>>>> Est ce acceptable ?
>>>>>
>>>>> Merci
>>>>>
>>>>> Nathalie Le Pontois
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> liste_gta mailing
>>>>> listliste_gta@list.accessiweb.orghttp://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> liste_gta mailing list
>>>>> liste_gta@list.accessiweb.org
>>>>>
>>>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> liste_gta mailing
>>>>> listliste_gta@list.accessiweb.orghttp://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> liste_gta mailing list
>>>>> liste_gta@list.accessiweb.org
>>>>>
>>>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> liste_gta mailing list
>>>>> liste_gta@list.accessiweb.org
>>>>>
>>>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> liste_gta mailing list
>>>>> liste_gta@list.accessiweb.org
>>>>>
>>>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> liste_gta mailing list
>>>> liste_gta@list.accessiweb.org
>>>>
>>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> liste_gta mailing list
>>> liste_gta@list.accessiweb.org
>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>>
>>>
>>
>> _______________________________________________
>> liste_gta mailing list
>> liste_gta@list.accessiweb.org
>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>
>>
>
_______________________________________________
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
