• Politique d'accessibilité
• Aller au texte
• Aller au menu

Choisir un habillage : Normal Fond noir Fond noir/gros caractères Minimal Sans habillage

Recherche sur ce site :

L’accessibilité agile

Un scénario fréquent

Pour commencer, nous allons nous mettre dans le bain avec une conversation pas tout à fait imaginaire :

• Le client : « nous souhaiterions obtenir un avis sur l’accessibilité d’une application en ligne que nous avons développée ».
• Le consultant : « bien sûr, nous proposons des audits approfondis, nous analysons vos pages, nous vous livrons un rapport contenant une liste des problèmes, avec toutes les solutions, des captures, des explications ».

L’audit est alors effectué par le consultant sur un échantillon de pages du site, et donne lieu à la livraison d’un rapport d’audit qui fournira un état des lieux complet de l’accessibilité d’un site à une date donnée.

Ce type d’approche est très intéressant dans de nombreux cas :

• Lorsque le site a déjà un niveau d’accessibilité assez élevé, et que l’audit vient constater la mise en œuvre d’un certain nombre d’améliorations. C’est le cas des audits finaux de labellisation ou d’attestation de conformité ;
• Lorsqu’il s’agit à l’inverse d’établir un état des lieux des pratiques, lors d’une toute première découverte de la problématique d’accessibilité, pour préparer l’investissement dans celle-ci ;
• Lorsque le client a un besoin formel de montrer l’incompétence d’un intervenant (agence Web, SSII, DSI, Directeur communication, développeur, décideur), ou quand un rapport formel est la seule façon de mettre toutes les alarmes au rouge sur le sujet.

Mais il existe également des cas où ce type d’audit, qui consiste à analyser un échantillon de pages sur un ensemble complet de critères puis à produire un livrable plus ou moins lourd peut s’avérer contre-productif. C’est alors une arme à double tranchant.

Quand le scénario dérape

Imaginons un scénario sensiblement différent : le début est identique. Un audit approfondi est décidé. A la livraison des rapports d’audit, il s’avère que la quantité de travail est considérable. Le niveau d’accessibilité du site est catastrophique, certaines bases en la matière ne sont pas respectées.

L’ensemble des remarques et préconisations signalées dans le rapport d’audit devront alors être prises en compte par les équipes qui produisent le site. Mais comment en être absolument certain ? La réponse est simple : il est nécessaire de faire un deuxième audit, qui va cette fois-ci véritablement servir à attester de la conformité du site.

Cet audit de vérification n’a guère de raisons d’être moins lourd : certes, l’expert connait déjà le site, et peut se concentrer sur les défauts repérés lors du premier audit, mais la charge reste sensiblement la même. Il est rare que le premier audit ait suffi à régler tous les défauts d’accessibilité. Il arrive même que le second audit en détecte de nouveaux, créés lors de corrections maladroites ou simplement entre-temps avec l’évolution des contenus ou de l’interface.

Cette solution en plusieurs audits approfondis peut décourager les développeurs et décideurs les plus motivés. Le plus souvent, à la fin de ces deux ou trois audits, l’accessibilité est considérée comme un sujet qui coûte cher, et qui nécessite un expert de très haut niveau, pour un retour sur investissement difficile à mettre en évidence.

Dans le même ordre d’idée, les cycles d’audits de labellisation sont censés conduire à l’obtention d’une récompense durement méritée, mais le nombre d’échecs est tout de même élevé. Et en cas d’échec, c’est autant d’équipes qui risquent de rejeter l’accessibilité en bloc, comme un sujet contreproductif et excessivement formel.

Le scénario que je viens de décrire est encore trop fréquent : il se répète même si souvent qu’il est temps d’en tirer quelques enseignements.

Une obligation de résultats

La démarche accessibilité numérique est fondamentale : elle favorise l’insertion des personnes handicapées mais aussi de nombreux autres publics ; elle contribue à l’industrialisation de la production de sites ; elle représente enfin un enjeu social et managérial important. Mais plusieurs écueils nous menacent aujourd’hui :

• Le retour sur investissement des démarches accessibilité est encore insuffisamment démontré ;
• Ces démarches sont perçues le plus souvent uniquement comme des contraintes ;
• Les lois et standards du secteur sont parfois perçus comme des freins à l’innovation, à la créativité, et à l’agilité ;
• L’application des standards accessibilité est souvent perçue comme une mesure destinée à une cible spécifique, à la limite du nuisible pour toutes les autres catégories d’usagers ;
• Les standards accessibilité sont considérés comme des buts ultimes, alors que la démarche devrait permettre d’aller beaucoup plus loin.

Les acteurs risquent de tomber dans divers pièges :

• Rejeter la démarche en bloc ;
• Repousser la démarche à plus tard ;
• Créer des contenus ghettos (les versions spéciales handicapés) ;
• Renoncer à mettre en ligne certains contenus jugés trop difficiles à rendre accessibles ;
• Pousser la démarche jusqu’au bout (surqualité) pour des résultats ou une reconnaissance jugés insuffisants et, finalement, retomber dans un des pièges précédents.

Ce risque est inacceptable, tout simplement parce que les enjeux sont essentiels : nous n’avons pas le droit de nous laisser piéger et en tant qu’experts du secteur, nous devons à tout prix éviter d’envoyer nos clients dans ces pièges. C’est pourquoi nous devons faire tout ce qui est en notre pouvoir pour que la production de services en ligne accessibles devienne une démarche légère, ouverte et tolérante.

L’essentiel du travail d’amélioration de l’accessibilité doit se faire en amont de l’audit approfondi. Puis, pendant la phase d’amélioration de l’accessibilité, le coût de la démarche doit être optimisé. Enfin, la démarche doit également être progressive et souple. Tout cela est possible, mais il va falloir que nous changions sérieusement nos habitudes : il est temps de parler d’accessibilité agile.

Ce serait quoi, l’accessibilité agile ?

1. Un processus et des critères identifiés : rien ne sert d’effectuer une évaluation complète d’un design ou de gabarits XHTML/CSS sur tous les critères d’un référentiel. À chaque étape du processus, et dès le début du processus, seuls les critères pertinents doivent être pris en compte.
2. Des recettes rapides sous forme de micro-séances d’expertise : l’examen rapide d’un site par un expert accessibilité lui permet d’obtenir des indications clés, qui permettent à leur tour d’agir très vite. Le travail direct avec un expert en conférence (partage d’écran, si possible), au téléphone ou en contact direct permet de comprendre facilement les manipulations fondamentales que fait l’expert et surtout de pouvoir les reproduire au moins partiellement en cours de développement. Il n’est pas non plus utile de définir des échantillons de 50 pages à recetter lorsque l’examen de 5 pages permettrait de détecter 80 ou 90% des problèmes fondamentaux ;
3. Des priorisations : tous les critères d’accessibilité n’ont pas la même importance, la même gravité, la même facilité de vérification ou de résolution. Un expert peut très facilement vous indiquer les points faciles à résoudre et ceux qui seront plus complexes à traiter. Les échanges peuvent également permettre d’identifier plus facilement les difficultés liées au contexte (le système de gestion de contenus, les budgets, les attentes) ;
4. Des améliorations programmées : l’accessibilité d’un site peut être assimilée à une construction nécessitant la mise en place de fondations, de murs, d’équipements et de décorations. L’expert peut vous aider à évaluer le temps et les moyens nécessaires à chacun de ces chantiers ;
5. Des itérations rapides : la répétition de cycles de recette rapide, de planification et d’amélioration permet de vérifier ce qui a été amélioré et ce qui doit l’être en vue de la prochaine amélioration ;
6. Moins de formalisme, plus d’efficacité : les livrables formels sont importants dans certaines conditions, ils viennent garantir que certains points sont traités ou non traités. Mais le plus souvent, seule la partie recette est vraiment fondamentale, et celle-ci doit être rapide ;
7. Un audit complet en fin de chaîne, constat de succès : l’audit accessibilité devrait idéalement être un constat de succès et non un constat d’échec. Il peut conduire à la production d’une attestation de conformité ou à l’obtention d’un label.

Les pré-requis

L’attitude

Du côté des clients comme des experts, il s’agit tout d’abord d’accepter que l’accessibilité n’est pas un état stable, statique, mais une démarche dynamique, un chemin sur lequel il faut avancer.

• Souplesse : il faut accepter le livrable rapide, informel, pas forcément très mis en forme. Il a une valeur ajoutée importante, qui se situe dans son rapport contenu/temps de production ;
• Accepter la coproduction : l’expert et le développeur doivent être en position de coproduire des recettes. Personne ne connaît mieux l’accessibilité que l’expert, mais personne ne connait mieux le site que le client ;
• Accepter l’imperfection : rien ne sert de s’étouffer avec des exigences délirantes. Commencez petit, progressez, améliorez-vous et rappelez-vous que ce ne sera jamais fini ;
• Viser l’efficacité : si une solution d’amélioration est rapide et facile à mettre en œuvre et que vous avez la main dessus, déployez-la.
• Accepter la priorisation : vous ne pourrez pas tout faire en même temps, et même si l’on vous dit que tout est important, vous ne pouvez pas tout faire. L’expert doit vous aider à prioriser vos améliorations, oubliez ce qu’on peut penser de vous ;
• Admettre la notion d’arbitrage : sachez qu’en matière d’accessibilité, il n’existe pas une vérité. L’auteur de cet article fréquente de nombreux experts accessibilité et peut vous affirmer avec certitude que sur certains sujets, il existe presque autant d’avis que d’experts. Corollaire : lorsque deux experts sont d’accord sur un sujet, ce qui est tout de même fréquent, car le consensus n’est pas rare, écoutez-les et apprenez.

Les idées

Connaître la philosophie : vous pouvez maîtriser des technologies sur le bout des doigts et être démuni lorsqu’il s’agit de les déployer. Rappelez-vous en toutes occasions qu’une technologie est un outil au service d’une idée, d’un usage, d’un message. Derrière les règles ergonomiques, il y a une philosophie de l’accès aux contenus numériques. Les avis diffèrent souvent, mais vous ne pouvez pas vous permettre de ne pas en avoir. Si vous ne prenez pas position sur le fond, vous ne serez jamais en mesure de faire les bons arbitrages.

L’expertise

C’est de très loin la denrée la plus précieuse sur le marché de l’accessibilité. Un expert accessibilité possède des qualités rares :

• Il doit être tolérant, accepter l’erreur, la comprendre, être empathique ;
• Il doit avoir assimilé la démarche d’amélioration continue (dynamique) ;
• Il doit savoir communiquer auprès de publics variés (décideurs, opérationnels), et pour ceci, il doit savoir s’adapter au niveau de ses interlocuteurs ;
• Il doit avoir un niveau technique très élevé (eh oui) ;
• Il doit savoir proposer des arbitrages et non imposer des solutions ;
• Il doit comprendre les problématiques des petites et des grandes organisations ;
• Il doit savoir placer l’accessibilité dans le contexte du Web en général, et de la qualité Web en particulier.

Qu’attendre de cette approche ?

Précisons que l’ensemble de cet article s’applique parfaitement si vous souhaitez déployer un référentiel qualité, référencement, ou performance.

Bien souvent, le rapport d’audit approfondi est un parapluie qu’on ouvrira en cas de besoin pour montrer que des choses ont été faites de façon très formelle. Mais dans les démarches qualité, à chaque fois que la formalisation prend le pas sur l’efficacité, l’échec n’est pas loin. Pire, la formalisation excessive est une surqualité. En quelque sorte, c’est privilégier l’assurance qualité au détriment de la qualité. Or, un excès d’assurance qualité est une non-qualité et représente à ce titre un coût de non-qualité.

Pour ceux qui sont prêts à accepter la souplesse d’une démarche moins formelle, et lorsque le contexte le permet, nous avons là une voie très prometteuse. Elle permet de produire des sites accessibles plus rapidement. Elle améliore l’appropriation du sujet par les équipes projets. Finalement elle permet d’intégrer l’accessibilité comme un élément normal et moins contraignant du projet Web.

Idéalement, l’accessibilité agile pourrait même contribuer au transfert de compétences des experts vers les équipes projets, au point de limiter progressivement l’appel aux experts à la résolution des questions vraiment épineuses, l’aide aux arbitrages complexes, ou la réalisation d’audits approfondis et exhaustifs de conformité ou de labellisation : la boucle est bouclée.

L’article que vous venez de lire a pour objectif de poser les fondements de l’accessibilité agile. La réalité du monde de l’accessibilité est souvent plus nuancée, et plusieurs experts du secteur qui l’ont lu et commenté souhaitent d’ores et déjà apporter des éclairages et des approfondissements opérationnels. Cet article est donc la première brique d’un dossier complet. Stéphane Deschamps, qui avait déjà abordé la question il y a environ deux ans dans un article non publié, proposera très bientôt un article sur la façon de déployer la démarche.

---

Une question, une remarque ? Écrivez à l'auteur.

6 Messages de forum

• L’accessibilité agile : enfin ! 28 juin 2010 17:05, par Olivier

  Bonjour Elie,
  Je découvre à l’instant cet article, et j’ai été obligé de lâcher la souris pour applaudir des deux mains.

  Un bon nombre des réflexions introductives me sont déjà familières, les ayant éprouvées en nombre d’occasions. C’est d’autant plus appréciable de les voir retranscrites ici, qu’elles sont assorties de conseils et recommandations fort pertinents.

  Tout ça pour dire que je partage tout-à-fait le point de vue exprimé (minuscule réserve : le topo sur la philosophie est trop peu factuel, et du coup détonne dans l’ensemble), et j’attends avec impatience l’article de Stéphane Deschamps, qui je l’espère sera opérationnel à souhait.

  Félicitations donc, et à ta disposition pour en discuter, partager, contribuer, etc etc.

  Olivier Nourry, Micropole-Univers

  Répondre à ce message

  • L’accessibilité agile : enfin ! 28 juin 2010 18:14, par Denis Boudreau

    J’abonde tout à fait dans le même sens qu’Olivier : j’aurais pu écrire l’article tellement nous vivons les mêmes situations chez AccessibilitéWeb en contexte d’audit d’accessibilité.

    Certes, lorsque l’approche fonctionne, elle fonctionne très bien, mais lorsqu’elle dérape (par exemple, lorsque le fournisseur Web de notre client n’y pige rien et ne corrige pas - ou mal - ce que nous recommandons), nos clients se retrouvent dans un tourbillon infernal d’audits qui se succèdent et qui n’amènent pas de résultats. S’ensuivent frustrations et débordements de coûts et ultimement, le risque que l’on retienne que le grand coupable, c’est l’accessibilité avec ses exigences toutes plus irréalistes les unes que les autres. On a beau parler à nos clients, on ne peut les sauver tous.

    Voilà longtemps que je me questionne sur une nouvelle approche d’évaluation et cet article me stimule à y réfléchir plus sérieusement. Comme cette question semble suffisamment pertinente pour impacter des experts dans des pays différents, avec des approches différentes, j’en conclue qu’il y a effectivement lieu d’y réfléchir. Elle est d’ailleurs très bien amorcée dans cet article de l’ami Élie.

    Alors, qui est avec moi pour une réflexion de groupe sur le sujet ? J’ai déjà un scrummaster de mon côté, il ne manque que quelques cerveaux supplémentaires en ébullition ! ;p

    Répondre à ce message

• L’accessibilité agile 28 juin 2010 22:56, par yann madeleine

  Je ne peut qu’acquiescer cet article, l’accessibilité est à prendre en compte tout au long de la vie du projet. Et un accompagnement constant, pertinent et pratique ne peut qu’aider à améliorer d’une part la compréhension et d’autre part la connaissance des réponses courantes aux problématiques d’accessibilité. L’application de méthodologies « éprouvées » comme l’agilité est une réponse intéressante et à explorer.

  Je pense d’ailleurs que de façon générale le suivi sur le long terme et l’échange continu ne peuvent qu’être plus profitable que des interventions ponctuelles, nous essayons d’ailleurs dans mon entreprise d’apporter l’accessibilité avec de petites formations pratiques et personnalisées afin de toucher concrètement les différents publics.

  Répondre à ce message

• L’accessibilité agile 28 juin 2010 23:44, par Frank Taillandier

  Je plussoie bien entendu et je profite du retour d’Openweb pour partager mon expérience dans la démarche.

  On beau retrouver dans tous les CCTP des demandes concernant l’accessibilité web, force est de constater que peu de clients réalisent à quoi ils s’engagent, pensant qu’ils font simplement appel à des professionnels qui se chargeront de la mise en conformité de leurs sites ou de leurs applications.

  Du côté de la chaine de production web, les commerciaux et les directeurs artistiques habitués à vendre de la maquette à des clients ne se rendent pas forcément compte non plus des responsabilités qui leur incombent.

  Les sites labellisés à faible impact communiquant n’aident pas non plus à démocratiser l’accessibilité web.

  Travailler l’accessibilité n’est possible que si tous les acteurs travaillent en équipe en avançant dans la même direction.

  Le rôle de l’expert/arbitre est primordial car il va pouvoir dans un premier temps sensibiliser à certaines problématiques souvent ignorées auparavant. L’expert doit être aussi moteur dans la montée en compétence des équipes et réaliser les ajustements nécéssaires dans les processus de développement (agile si possible) pour que tous les acteurs du projets aient en permanence une évaluation du niveau d’accessibilité atteint.

  Vivement l’article du ’sieur Deschamps.

  Répondre à ce message

• L’accessibilité agile 14 août 2010 10:05, par Rodan Bury

  Excellent article. :-)

  Dans le paragraphe "Admettre la notion d’arbitrage" : "ce qui est tout même fréquent" à corriger en "ce qui est tout de même fréquent".

  Y’a pas de bouton modifier, wouin ! :D

  Répondre à ce message

• L’accessibilité agile 8 octobre 2010 01:43, par Vincent Francois

  Bonjour,

  Je suis moi aussi content de voir que les interrogations que nous avons à Montréal sont partagées ailleurs et même très élaborés dans ce billet d’Élie.

  Je suis pleinement d’accord avec l’idée de réduire en de « micro-séances d’expertise » les démarches de correction et de transfert d’expertise. Cela va parfaitement avec notre approche de mettre en avant la transversalité de l’accessibilité et le traitement qu’elle doit recevoir à chaque étape de la chaîne de production.

  Que ce soit en formation ou lors de présentation de résultats chez des clients, j’ai coutume d’insister sur le fait que la prise en charge des règles d’accessibilité ne constitue qu’une modification des bonnes pratiques, qui une fois acquises, le sont pour longtemps et qu’elles ne demandent souvent qu’à peine plus de travail. Qu’il s’agit de qualité et que cette qualité acquise bénéfice au producteur du site autant qu’aux bénéficiaires officiels des standards.

  Accoler l’idée d’agilité est effectivement une bonne idée qui permet de mieux illustrer le concept des petites bouchées et celui des compétence acquise dans les bonnes pratiques.

  Répondre à ce message

Répondre à cet article

• Plan de site
• Contacts
• Le collectif et ses membres
• Politique de confidentialité
• Conditions de réutilisation
• Proposer vos contributions

Page valide XHTML 1 Strict, CSS2 et accessible AA.
Ce site s'affiche mieux dans un navigateur conforme aux standards, voici pourquoi.
Site hébergé par yterium (depuis 2010) et par l'APINC (2002-2010) . Propulsé par SPIP.