Dans les projets d’accessibilité, les étapes qui demandent le plus d’investissement sont :
- la mise en place d’une structure de gestion de projet avec un plan de déploiement des améliorations du système,
- l’audit d’accessibilité du dispositif numérique,
- suite à l’audit, la consultation des designers pour la conformité avec la charte graphique et des développeurs pour la faisabilité,
- la mise en conformité par le ou les développeurs,
- la réévaluation,
- les tests utilisateurs.
Nous allons vous guider dans les différentes phases d’un projet d’accessibilité en nous appuyant sur notre expérience.
Quelles ressources?
Les acteurs et actrices du projet
Responsable / Chef.fe de projet
Le facilitateur du projet. Celui ou celle qui coordonnera les acteurs. C’est une personne qui est à l’aise avec les projets numériques et veut porter ce type de projet.
Il apporte la vision “métier” au projet et communique en interne sur les étapes et son déroulement. Il rassemble les parties prenantes en interne avec les consultants.
Consultant.e Accessibilité
Comme pour le porteur ou la porteuse de projet, il vaut mieux choisir une personne qui a des exigences et une motivation dans ce domaine.
Les préalables pour ce profil :
- une motivation pour ce type de projet et un intérêt pour l’inclusivité,
- une connaissance des publics,
- une connaissance fine des standards et de la législation,
- un niveau de connaissance technique suffisant pour interpréter des règles de mise en oeuvre,
- une expérience en suivi de projet numérique et plus particulièrement dans leur partie fonctionnelle et interface,
- si possible une connaissance des standards de design,
- savoir mener des tests utilisateurs à travers une méthodologie éprouvée.
Product owner
La place des “product owner” peut être celle d’un porteur.se de projet ou d’une personne à convaincre de la nécessité du projet d’accessibilité.
Dans le premier cas, cela revient à la description du “Responsable de projet” et les qualités requises sont déjà atteintes soit par expérience, soit par formation.
Dans le deuxième cas, nous vous renvoyons à notre argumentaire que vous pouvez adapter:
- obligations légales,
- volonté d’inclusion,
- volonté de toucher le plus large public,
- obtenir de meilleures performances et résultats.
IT Manager
Le rôle de l’IT Manager ou du CTO est souvent d’être un facilitateur pour le déploiement technique des solutions. Il ou elle aura son mot à dire sur les étapes de tests.
C’est le gardien de la qualité du code et des procédures. Nous reviendrons sur l’importance des itérations suite aux premiers déploiements. Dans la volonté de partage à travers toute l’organisation de l’exigence d’accessibilité, l’IT bénéficiera de se former sur ce sujet et sur les solutions de tests et d’intégration qui existent déjà.
Développeur.se front end
C’est un poste clé puisqu’en dernier rideau il ou elle lui reviendra de mettre en œuvre les recommandations d’accessibilité.
Il est intéressant de l’associer en amont au projet à plusieurs titres :
Il aidera à poser le cadre technique et certaines contraintes. Par exemple, implémenter les techniques ARIA pour les éléments interactifs.
Sa sensibilisation au sujet permettra d’intégrer les bonnes pratiques d’accessibilité lors des itérations ultérieures sur le code.
En aval, ce sera l’allié précieux pour la mise en œuvre des solutions techniques.
Designer
Selon qu’il s’agit d’un projet de mise en conformité, de refonte ou de conception depuis zéro, l’implication du designer est diverse.
Dans tous les cas, il vaut mieux s’adjoindre les services d’un designer qui applique une méthode de conception globale du type UX Design plutôt qu’un simple designer visuel. Ce n’est pas le titre qui fait ici la différence mais plutôt l’expérience et les savoir-faire : comprendre les utilisateurs, conceptualiser et comprendre des parcours utilisateurs, comprendre les technologies employées, savoir communiquer avec les développeurs, etc.
Le designer est sollicité pour adapter la charte graphique quand les contraintes de l’accessibilité le requiert (en particulier, dans le cas du respect des contrastes et des critères visuels: sous critères 1.4 du WCAG 2.2 (Perceivable).
Conception de zéro et refonte
Les apports d’un designer en début de projet sont nombreux quand il est lui-même spécialiste ou qu’il est guidé par un consultant.
La conception globale comprend le même objectif de cohérence et de clarté de l’interface qu’un projet lambda. Le design d’interface devra s’attacher à respecter les standards à mesure que l’on conçoit une expérience utilisateur innovante et efficace. Les premiers sujets qui viennent à l’esprit sont celui des tailles de polices et des choix de couleurs.
Mise en conformité
La mise en conformité intervient après une série de changements mineurs. Dans une démarche d’amélioration continue.
Dans le cas de la mise en conformité, nous revenons au propos précédent ces paragraphes : il s’agit souvent d’une adaptation, notamment pour la conformité des contrastes et de la lisibilité des typographies, mais chaque ajout d’éléments d’interface et d’éléments fonctionnels doit faire l’objet d’une scrutation particulière et ponctuelle.
Les outils
Les lecteurs
Les navigateurs : les plus grands navigateurs du marché possèdent des paramètres à l’usage des personnes en situation de handicap. Il sont également capables de diagnostiquer quelques problèmes d’accessibilité.
Sur Firefox, l’utilisation du plugin “Developer tool” permet de s’attaquer à la structure du code HTML pour en voir toutes les faiblesses et mieux analyser son balisage sémantique (par exemple, les textes alternatifs).
Dans Chrome, il existe un onglet “accessibilité” après avoir lancé les tests de Lighthouse (Plus d’outils > Outils de développement > Onglet “Lightshouse” > Case “Accessibilité”).
Les assistants
Ils sont particulièrement utiles lors des tests utilisateurs mais également pour des itérations intermédiaires qui permettent à l’équipe projet de faire ses tests elles-mêmes.
On pense au plus connu : JAWS qui propose des licences de tests ponctuels, mais il est également possible de commencer un premier “dégrossissage” avec le mode “narrateur” de Microsoft, TalkBack sur Android ou Voiceover de Apple.
Cette partie est véritablement importante car elle vous révélera rapidement les incohérences sémantiques dans l’organisation de votre code et de votre information.
Les vérificateurs d’accessibilité
WAVE
Mis à disposition par le groupe de travail WAI du W3C. Une bonne base pour commencer à condition de savoir interpréter les résultats.
Browserstack
Spécialiste de la compatibilité des interfaces web et applicatives, Browserstack propose son propre outil d’audit d’accessibilité. Il permet de tester un échantillon de pages selon les critères WCAG.
TGPi
Il fait partie d’un ensemble d’outils collaboratifs publiés par la société ARC et qui permet de travailler sur les questions d’accessibilité de manière globale et régulière avec des tests qui sont régulièrement répétés.
Les vérificateurs de contraste
Il en existe de nombreux en ligne qu’il est facile de retrouver avec une simple recherche.
Citons tout de même le plus connu : Color contrast checker de WAIM.
TPGi propose un outil pour vérifier les contrastes des applications “stand alone”, une bonne alternative pour les concepteurs et les spécialistes dans le cas où il n’est pas possible de faire des analyses “en ligne”.
Calculer la charge
Vous savez donc ce que vous voulez tester, quel est votre objectif et sur qui vous comptez pour avancer sur ce projet.
Nous allons vous donner quelques points de repères pour évaluer la charge de travail qu’une mise en conformité vous coûterait. Mais comme il est difficile de le faire sans connaître l’ampleur de votre projet, ni la pérennité de votre démarche, nous vous proposons plusieurs méthodes.
Évaluation proportionnel
La limite de ce type d’évaluation est la loi de Conway qui stipule qu’un projet devient inutilement complexe si on le découpe en fonction des acteurs qui le portent. A chaque acteur supplémentaire, vous aurez tendance à ajouter un “module” dans votre projet et donc des communications entre les parties du projet alors que celui-ci pourrait être intégré de façon plus simple. Cette complexité paraît nécessaire dans le cas de l’accessibilité, dans la mesure où il est rare que les porteurs de projet possèdent toutes les expertises nécessaires à sa réalisation.
Heureusement, en décrivant bien les méthodes et grâce à la discipline de groupe on parvient à rendre cette complexité plus gérable.
Soit un projet divisé en plusieurs phases:
- Conception
- Développement
- Test
- Déploiement
A la conception, l’accessibilité impactera peu le cahier des charges (choix du standard et de la méthode d’implémentation). Comptez 10-20% de charges supplémentaires selon le niveau de spécialisation de vos intervenants.
Le consultant devra probablement corriger les spécifications fonctionnelles, si elles ne prennent pas en compte la partie “front end” du système. Il travaillera de concert avec le designer visuel et reprécisera les attendus sur chaque élément d’interaction.
- Avec spécifications front end: une revue des éléments visuels et des spécifications pour les amender.
- Sans spécifications front end: une rédaction des spécifications front end en s’appuyant sur les intentions de la maquette.
L’audit ajoute plusieurs jours de travail à intercaler entre la phase de conception et la phase de développement. Le temps de travail dépendra du nombre de templates (modèle de page) et d’éléments interactifs à tester. Le responsable de l’audit reverra l’organisation de l’information, les maquettes graphiques, les spécifications fonctionnelles.
Le développement est peu impacté en première phase. A condition que le développeur prenne en compte les spécifications front end.
Les tests d’accessibilité seront mieux menés après une recette et une phase de corrections approfondies. Le risque est de devoir revenir sur des corrections fonctionnelles suite à cette recette. Mais si les spécifications ont bien été suivies, la structure du code est normalement prévue pour une adaptation rapide.
Après les corrections du développeur, l’application ou le site web pourra être audité une dernière fois.
Nous reviendrons sur les tests d’Utilisabilité en détail mais ces derniers dépendent du nombre de participants. Une règle partagée est qu’il y a besoin d’une base de 6 utilisateurs pour commencer. Dans le domaine de l’UX cela correspond à la détection d’une centaine de corrections. Dans le cas de l’accessibilité, et si les standards ont bien été atteints, les ajustements concerneront surtout les contenus. Ce qui requiert moins de corrections de code.
En résumé
- Temps de rédaction du cahier des charges x0,2.
- Temps de spécifications x0,2 dans le cas d’une spécification front end bien suivie.
- Temps de spécifications jusqu’à 2x plus long en l’absence de spécifications front end.
- Temps de développement est égal si les spécifications et les bonnes pratiques ont été partagées en amont.
- Tests utilisabilité : comptez 1 journée pour rédiger les guides, une demie journée par entretien et quelques jours pour un reporting et une notice d’accessibilité à afficher sur votre site.
Selon le niveau de spécialisation de vos développeurs, l’implémentation pourra demander une deuxième phase de quelques jours pour les corrections.