Elie Sloïm vient de publier un article sur OpenWeb à propos de L’accessibilité agile:
L’audit approfondi est une étape fréquente dans la démarche d’amélioration de l’accessibilité d’un site. Une telle démarche débute fréquemment par la recherche d’un état des lieux. Hélas, la production d’un rapport d’audit approfondi de l’accessibilité prend du temps et coûte de l’argent. Dans certains cas, cette approche se justifie parfaitement, mais dans d’autres que nous aborderons dans cet article, ce n’est pas toujours la meilleure solution. Il est peut-être temps d’inventer de nouvelles méthodes pour améliorer l’accessibilité des sites Internet.
L’accessibilité peut éventuellement se traiter en bout de chaîne du processus sur un site simple, mais malheureusement bien trop souvent c’est trop tard. Développer un site Web accessible peut demander des modifications du choix du CMS, définir des choix de design particulier et des expériences UX particulières. L’article de Elie s’inscrit dans le domaine plus large de la compréhension du Web. Il y a, au moins, deux enjeux principaux pour les agences Web à résoudre :
- L’éducation du client sur les enjeux du Web
- L’éducation de l’équipe de conception/UX (création) du site.
L’équipe de développement a rarement le contrôle sur cette partie du site, si ce n’est d’implémenter les choix des concepteurs du site. Si les concepts sont corrects du point de vue de l’architecture Web, de la stratégie de contenu, de l’accessibilité, de la diversité des plateformes, le développeur aura moins d’enjeux pour trouver les solutions adéquates. C’est trop rarement le cas.
Une de mes grandes réalisations cette année est que toute évangélisation à propos du Web est vaine si elle ne prend pas en considération les décideurs d’affaires ainsi que les départements créatifs.
disclaimers
Note 1 : je participe comme rédacteur à l’équipe de OpenWeb et j’ai publié un article sur RDFa.
Note 2 : Pheromone a commandé un rapport d’accessibilité pour un client à la société Temesis de Elie Sloïm.
Je pense que l’accessibilité doit être intégrée dans le cycle de la mise en place du projet web. La reléguer en « bout de chaîne » est tout simplement inconcevable ! Je dirais même plus que c’est l’un des process qui devrait être présent en permanence tout au long de la mise en place du site. Effectivement ça soulève plusieurs problématiques (internes et externes), suivant le cas il faut trouver le meilleur compromis.
Coté client, c’est très difficile d’expliquer le concept dans sa globalité. Le client (dans un cadre de business) commande une « place de marché » et non pas une philosophie, ce qui l’intéresse c’est le ROI.
L’une des façons de faire passer le message consiste à revêtir ce volet d’une couche « bénéfice business » en évoquant les l’impact direct du respect des standards. Je prends un exemple simple : Remplir l’attribut « alt » des balises images par un texte alternatif ; mettez d’abord en avant que cette pratique permet d’améliorer son référencement sur les moteurs de recherche et ajouter en plus que c’est une bonne pratique d’accessibilité, n’insistez pas sur le fait que ce soit « une règle » ! Là aussi c’est une question de finesse dans le langage : Parlez de normes, de bonnes pratiques … ne parlez pas de règles.
Coté internes (équipes), c’est une autre histoire :
Je vais prendre un cas classique d’une équipe : Création / Développement / Intégration
Création : L’équipe création est à la fois la plus facile et la plus difficile à gérer. Facile, car de par leur formation et leur métier, ils ont des réflexes on matière d’accessibilité et d’ergonomies. Difficile, car l’équipe création n’est pas toujours convaincue de certaines règles. Il est bon dans ce cas d’insister sur les points qui sont fondamentaux en brandissant la bannière « Normes ». N’insistez pas sur les choses facultatives, c’est à la fois une frustration pour l’équipe et un moindre bénéfice pour le client.
Développement : la priorité du développeur est d’implémenter la logique « métier » dans un socle applicatif cohérent. Néanmoins, si des spécifications supplémentaires sont requises (concernant l’accessibilité), et documentées dans le cahier des charges, généralement elles sont implémentées par les développeur : « ça ne mange pas de pain ».
Intégration : si des fonctionnalités sont présentes dans le cœur applicatif, qu’elles sont intégrables suivant un modèle technique simple d’utilisation, l’intégrateur ne s’y oppose pas.
Ce qui est important, c’est d’inclure l’accessibilité en amont du projet. Une bonne pratique est d’avoir un cahier de recette interne qui regroupe des batteries de tests d’accessibilité. Libre à chacun de voir quelles sont les règles qui lui semblent les plus pertinentes et des les inclure dans sa batterie des tests. Segmenter les tests par pôle de compétence est essentiel, car ça permet d’avoir des résultats objectifs et de réduire les erreurs.
S’il y a une ou plusieurs personnes en charge de l’AQ, cela permet de facilité leur travail et de leur permettre d’être plus efficace dans leur analyse et leurs recommandations. Dans le cas d’un audit, l’auditeur pourra se concentrer sur un niveau élevé d’accessibilité et généralement un seul passage suffit …
Au final, c’est au chef de projet de s’assurer que le processus est mis en place, c’est à lui de coordonner les équipes pour l’accessibilité soit intégrée au sein de la méthode de travail de l’entreprise.
Abdel un excellent document pour les bénéfices de l’accessibilité a été créé par le WAI.
Merci pour le lien Karl, mais il ne fonctionne pas.
Peut être que tu voulais parlais de ça : http://www.w3.org/WAI/presentations/WCAG20_benefits/WCAG20_benefits.html
Il y a aussi des documents très intéressants sur l’accessibilité à l’adresse : http://www.references.modernisation.gouv.fr/rgaa-accessibilite
Bien que l’initiative soit gouvernementale (En France) le contenu est très complet et la démarche progressive. Ce guide composé de 5 manuel évoque à la fois les enjeux les bénéfices et la méthodologie (techniques) concernant l’accessibilité.
Voilà, au plaisir de te lire (ou de lire l’un des membres de votre équipe)