Bonjour Olivier,
je rejoins ton avis sur le fait qu'on ne puisse appliquer cette
tolérance aux modules d'un CMS ou un plugin jquery, etc.
Cela dit concernant les vidéos / cartes, il s'agit également d'un choix
d'utiliser tel ou tel service et certains sont plus accessibles que
d'autre (par exemple le player viméo s'en sort plutôt pas mal). Par
ailleurs, tu peux tout à fait héberger tes vidéos sur youtube,
dailymotion ou autre et ne pas utiliser le player par défaut. Là encore
il s'agit d'un choix. Idem pour un service avec des conditions
d'utilisations qui t'interdirait cela c'est encore une fois toi qui
prend la décisions ou pas de l'utiliser quand même.
A ce compte là, le mec qui a choisi d'acheter un CMS totalement
inaccessible et propriétaire pourrait également dire "ah bah non désolé
c'est pas accessible mais c'est pas ma faute je peux rien faire c'est le
CMS qui est mauvais et j'ai pas le droit de le modifier".
Il faut donc à minima distinguer le cas de l'amélioration d'un existant
et le cas d'une refonte/création de zéro pour lequel il doit y avoir une
politique d'achat privilégiant les solutions accessibles (le
gouvernement a produit une note indiquant qu'il fallait donner la
préférence au logiciel libre, il pourrait tout à faire faire de même
pour ce qui est accessible)
Pour les cartes, je t'accorde que le cas est un peu plus problématique
car il y a assez peu d'interface de service de carto accessible. Cela
dit il faut également tenir compte de l'intérêt de la carte et de sa
fonction.
Par exemple :
Est ce que les fonctions de zoom et de déplacement dans la carte doivent
être rendu utilisable au clavier si le but de la carte est juste de
montrer un point X sur une carte et qu'il y a par ailleurs l'adresse en
clair dans la page ?
Est ce que les fonctions de zoom et de déplacement dans la carte doivent
être rendu utilisable au clavier si le but est de voir un ensemble
d'infos sur une carte quand il y a une fonction de recherche via un
formulaire donnant accès à une vue liste présentant les mêmes infos ?
Aurélien
Bonjour Valérie,
On utilise la dérogation pour les services tiers car le propriétaire
du site utilisateur ne peut pas garantir que l'accessibilité sera
respectée, ni aujourd'hui ni demain, sur ces composants. On peut
(parfois) hacker les interfaces pour les rendre plus accessibles, mais
on peut être confronté à des conditions d'utilisation défavorables à
cette pratique. Et à courir derrière les évolutions du service, que
par définition on ne maîtrise pas, et pour lesquels on est contraint
de réagir sans pouvoir prévenir.
On gère ainsi le principe de réalité: si on ne l'acceptait pas, on
contraindrait les propriétaires de sites soit à des investissements
faramineux pour héberger par exemple des vidéos avec le même niveau de
stabilité et performance que Youtube (qui plus est, gratuit); soit à
renoncer à mettre des vidéos; soit à renoncer totalement à faire de
l'access parce que "c'est trop cher" (cas le plus problématique et
malheureusement le plus fréquent).
En revanche pour les modules ajoutés à un CMS, on ne peut pas
appliquer la même tolérance. Le module ajouté fait partie du produit,
il est choisi délibérément et en connaissance de cause, et le
développeur doit s'assurer avant de l'intégrer qu'il répond bien au
cahier des charges, sur tous ses aspects... Si un module compromettait
la sécurité du site, j'imagine qu'il serait écarté, ou modifié. Pareil
pour l'accessibilité.
D'ailleurs si on appliquait cette logique de dérogation aux modules,
on pourrait arguer du fait que le core du CMS a ses propres
limitations, on se laverait alors les mains de l'accessibilité dès
qu'on prend un CMS.
L'open source, en plus de la flexibilité offerte, permet de contribuer
à l'amélioration du produit pour la communauté. Certains le font (voir
par exemple le module d'accessibilité de Joe Dolson pour Wordpress). A
mon sens c'est un élément de motivation intéressant pour un
développeur: l'opportunité de reverser l'amélioration pour
l'accessibilité, et pouvoir s'en vanter sans vergogne. C'est quand
même vachement plus valorisant qu'un énième slider que personne ne
télécharge!
Cordialement,
*Olivier Nourry*
Twitter: @OlivierNourry <http://twitter.com/#%21/OlivierNourry>
Le 23 juillet 2014 20:06, Valerie <[email protected]
<mailto:[email protected]>> a écrit :
Bonsoir à tous,
Nous avons vu que les contenus gérés de façon externe au site
(comme les vidéos youtube) entraînent un "non applicable" sur les
critères idoines.
Je travaille à 99 % avec des CMS opensource (Typo, Drupal,
WordPress...), dont les plugins et modules spécifiques sont
développés par une communauté de développeurs qui pensent avant
tout aux fonctions.
Il arrive souvent que nous en utilisons pour répondre aux besoins
de nos clients, mais ils ne sont pas souvent accessibles. Certes,
qui dit opensource dit totalement adaptable, mais le coût de
développement et d'adaptation apres coup n'est pas négligeable.
Sommes nous tenus de mettre à jour ces extensions ? Souvent, au
chiffrage, nous n'avons pas encore sélectionné l'extension que
l'on utilisera, et donc les fonctionnalités accessibles qu'elle
propose.
Peut-on faire valoir le droit de l'extension externe pour
justifier le non conformité d'une extension ? Souvent, ce sont
les formulaires de contact qui posent le plus de problème, avec
une accessibilité quasi nulle.
Comment faites vous de votre côté? Prévoyez vous une enveloppe
budget dans ce cas là ?
Merci de votre retour d'expérience,
Valérie
_______________________________________________
liste_gta mailing list
[email protected] <mailto:[email protected]>
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
_______________________________________________
liste_gta mailing list
[email protected]
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
--
Aurélien Levy
----
Temesis
_______________________________________________
liste_gta mailing list
[email protected]
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
