Comment je priorise les correctifs d’accessibilité

Faire un audit d’accessibilité, c’est bien. C’est même bien souvent indispensable. Proposer des correctifs, c’est encore mieux! Car évidemment, le fait de constater un problème n’a d’intérêt que si cela a pour but de résoudre ce problème.

Plus de 10 ans de pratique du conseil en accessibilité, et des dizaines d’audits, m’ont permis d’affiner mon approche. Et je suis de plus en plus souvent sollicité sur des projets où les tâches sont découpées en tickets, en mode plus ou moins agile. L’avantage de ce fonctionnement est que l’on améliore les chances de voir le problème résolu. Car alors, la correction entre dans le flux de travail de l’équipe de développeurs. Au besoin, elle est redirigée vers la bonne personne, lorsqu’il s’agit par exemple d’un problème de contraste ou de choix de mots, qui ne concernent pas, en général, les développeurs.

Par rapport à mon ancienne approche consistant à livrer un relevé et un rapport d’audit, c’est beaucoup plus long. Mais malgré tout l’amour que je pouvais y mettre, mes relevés et rapports couraient toujours le risque de finir comme cales d’un meuble de guingois… Au final, je constate qu’il y a globalement une meilleure prise en compte des tickets et que cela mérite l’effort consenti.

Bien souvent, cependant, il est demandé de prioriser les correctifs. On ne peut en effet pas tout prendre en compte d’un coup; un site moyen soigneusement recetté va engendrer rapidement plusieurs centaines de tickets… Les gestionnaires du projet, et ceux qui traitent les tickets, ont besoin de savoir par quoi commencer.

Je ne suis en général pas en position d’imposer une priorité de prise en compte, par rapport à tous les tickets qui vont peupler le bug tracker de n’importe quel projet en cours de recette.

Dans le meilleur des cas, l’accessibilité est alignée avec les priorités du projet, quand il y a une exigence forte et urgente de conformité: dans un contexte réglementaire coercitif par exemple, ou lorsque le projet vise une labellisation. Les anos d’accessibilité seront alors sur le haut de la pile.

Dans le cas contraire, il ne faut pas se leurrer, les anos d’accessibilité passeront après celles qui touchent tous les utilisateurs et qui contrarient les objectifs du site. Celles que je vais relever vont alors entrer dans le « ventre mou » des anos, tous ces trucs qu’il faudra corriger quand on aura résolu les plus graves. Oui, je sais, je sais, une erreur d’accessibilité, c’est potentiellement bloquant pour certains utilisateurs; il n’empêche que le chef de projet n’a pas d’autre choix que de commencer par ce qui bloque tous les utilisateurs.

Même à l’intérieur de cela, il y des anos d’accessibilité qui vont être plus ou moins impactantes. Toute non-conformité crée un problème pour un groupe d’utilisateurs donné, mais avec des degrés de gravité différents. Par exemple, un lien-image avec une alternative vide (il sera ignoré par les lecteurs d’écran) est forcément plus urgent à corriger qu’un titre de lien redondant (qui va rendre la restitution inutilement verbeuse). Dans le premier cas on a un blocage; dans le second, une gêne.

Pour caractériser un degré de priorité à l’intérieur de mes anomalies d’accessibilité, je vais donc en évaluer la « sévérité ». Dans Redmine, outil de gestion de tickets couramment utilisé par les équipes avec lesquelles je travaille, la sévérité peut prendre trois valeurs: bloquant, majeur, mineur. Remplir correctement ce champ est un des aspects les plus importants de la création du ticket.

Pour choisir la bonne valeur, je vais m’appuyer sur la notion d’accès à l’information ou à une fonctionnalité. C’est un principe qui avait été introduit par le modèle MIPAW, imaginé par Jean-Pierre Villain:

• bloquant si au moins un profil d’utilisateur est empêché de consulter le contenu, ou d’utiliser la fonctionnalité, sans possibilité de contournement;
• majeur s’il est possible de consulter le contenu, ou d’utiliser la fonctionnalité, via un contournement, mais au prix d’une manipulation complexe ou difficile à trouver;
• mineur si le contournement est simple, ou si c’est de l’ordre de la gêne.

Prenons quelques exemples:

• l’absence de sous-titres pour une vidéo sera généralement bloquante: les utilisateurs ne pouvant pas entendre n’auront pas accès à l’information, sans recours possible;
• un contraste de textes insuffisant sera généralement majeur: on pourra accéder à l’information par exemple en copiant le texte dans un éditeur, pour le faire apparaître avec un jeu de couleurs plus lisible. Cela reste possible d’accéder à l’information, au prix d’une manipulation qui rend désagréable l’expérience de navigation;
• une alternative d’image mal rédigée, mais qui reste compréhensible, sera généralement mineure: cela va dégrader l’expérience utilisateur, mais pas au point de nécessiter un contournement.

Pour comprendre ce qui va poser problème, et à quel degré, aux utilisateurs, il faut bien entendu connaître les impacts des erreurs d’accessibilité. A cette fin, ce guide pourra s’avérer particulièrement utile.

Si l’on pouvait ensuite répartir les critères dans l’une ou l’autre catégorie, la vie serait simple… Mais c’est plus nuancé que cela, d’où les « généralement » dans les exemples ci-dessus. Il faut en effet tenir compte de la situation dans laquelle se trouve le contenu.

Reprenons l’exemple du sous-titre manquant. S’il existe par ailleurs une retranscription suffisamment fidèle de la vidéo, et que l’utilisateur est en mesure de comprendre que c’est un substitut acceptable, je vais considérer que l’information est disponible sous une autre forme. Et donc requalifier le problème comme majeur, et non plus bloquant.

Inversement, si un ou deux titres de liens redondants, c’est une gêne mineure, en revanche, tout un méga-menu avec 170 liens, tous doublés d’un titre redondant, c’est un véritable enfer en restitution vocale (et, oui, j’en ai déjà vu des comme ça…). Je vais donc joyeusement le promouvoir au rang de problème majeur.

On remarquera en corollaire que le niveau du critère (A, double A ou triple A) ne nous est pas d’un grand secours pour déterminer la sévérité du bug. En effet, un même critère peut générer des anomalies de tout degré de sévérité, puisque cela dépend du contexte dans lequel il est vérifié. C’était d’ailleurs l’un des résultats intéressants de MIPAW, qui constatait que le découpage par « accès à l’information » transcendait les niveaux de conformité, ceux-ci étant tous représentés dans chacune des 3 catégories de critères révélées par ce modèle.

Comme mon approche est pas mal basée sur l’expérience, et sur ma perception de ce qu’est une manipulation difficile, ou pas, il y a bien entendu une part de subjectivité dans mes évaluations de sévérité. Mais à ce jour, c’est ce que j’ai trouvé à la fois de plus simple et de plus efficace pour placer le curseur, et aider à prioriser les corrections.

Et vous, quelle est votre approche en la matière? Avec quels retours d’expérience?