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/#!/OlivierNourry> Le 23 juillet 2014 20:06, Valerie <[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] > 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
