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
