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)

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.