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
