AccessiBlogue

Ce billet vise à identifier les sept qui sont les plus fréquemment identifiés dans notre pratique.

1. Ignorer le caractère transversal de la pratique
2. Considérer l’accessibilité comme une étape de fin de parcours
3. Attribuer l’accessibilité à la seule responsabilité des intégrateurs
4. Limiter la validation aux seuls critères techniques
5. Confondre les notions de mise en accessibilité et de conformité à l’accessibilité
6. Présumer que les outils feront tout le travail
7. Sous-estimer l’impact des plateformes technologiques

1. Ignorer le caractère transversal de la pratique

Contrairement aux spécialisations dites « traditionnelles » du Web, telles que designer, analyste, ergonome, intégrateur ou programeur, la pratique d’accessibilité ne se limite pas à une intervention ciblée à un moment précis de la chaîne de production. En effet, pour qu’elle soit réussie, l’intervention d’accessibilité se doit d’être intégrée à toutes les phases d’une chaîne de production Web.

La plupart des gestionnaires qui évaluent l’angle par lequel aborder cette nouvelle pratique échouent à en identifier le caractère transversal et se contentent de la prévoir à une étape précise, généralement en fin de parcours au moment de la phase du contrôle qualité. Il faut cependant savoir que l’accessibilité implique des interventions ponctuelles tout au long du projet. Quiconque ignore cet état de fait est condamné à oublier certains aspects très importants en cours de route, avec pour résultante de prendre des décisions techniques qui pourront avoir d’importants impacts sur le niveau d’accessibilité obtenu au final ou pire encore, qui pourront nuire aux objectifs de conformité de l’organisation.

Ignorer le caractère transversal de la pratique résultera inmanquablement par des oublis importants qui pourront s’avérer lourds de conséquence par la suite. Nous en verrons plusieurs au cours des prochains paragraphes.

2. Considérer l’accessibilité comme une étape de fin de parcours

Puisque la pratique d’accessibilité repose en grande partie sur des grilles techniques, la plupart des gestionnaires qui décident d’aller de l’avant avec une démarche de mise en accessibilité présument que cette intervention en est une de validation de dernière minute, au même titre que le contrôle qualité avant la mise en ligne. Dans les faits, il n’en est rien.

Trop souvent, nos interventions auprès de clients consistent à observer lors d’évaluations que de nombreuses décisions mal avisées ont miné le potentiel d’accessibilité d’un projet, au point tel où il est souvent trop tard pour sauver les meubles. Dans beaucoup trop de cas, nous ne pouvons qu’observer les conséquences désastreuses de ces mauvaises décisions (contrastes de couleurs insuffisants alors que la marque est placardée partout dans la ville, systèmes de navigation entièrement dépendants de périphériques particuliers comme la souris, choix de technologies incompatibles avec les outils d’adaptation informatiques, etc.) et qui résultent en autant de contenus qui ne sont pas accessibles ou qui n’ont pas été prévus pour l’être au moment où ces choix auraient dû être faits.

Dans un domaine où la guérison coûte bien plus cher que la prévention, il importe de bien comprendre quelles interventions d’accessibilité relèvent de chaque phases de la chaîne de production pour éviter les décisions malheureuses qui entraîneront d’importants dépassements de coûts et qui demanderont de déconstruire certains éléments du projet pour les reconstruire de manière accessible.

3. Attribuer l’accessibilité à la seule responsabilité des intégrateurs

Dans le même ordre d’idées, la responsabilité d’appliquer les règles d’accessibilité revient souvent à l’intégrateur qui, par la nature de son intervention, hérite de la responsabilité de veiller à l’accessibilité des pages Web qu’il intègre.

S’il est vrai que la très grande majorité des exigences d’accessibilité supposent une intervention des intégrateurs Web, beaucoup de matériel, de décisions et d’orientations se doivent d’être prises plus tôt dans le projet à défaut de quoi, l’efficacité de la chaîne de production en sera largement affectée. Pour qu’une démarche d’accessibiilité s’avère une réussite, il importe que chaque intervenant dans une équipe de production comprenne les éléments d’accessibilité qui relèvent de sa responsabilité. On évitera ainsi de retourner aux rédacteurs pour demander les équivalents textuels aux images, aux designers qu’ils revoient leur charte graphique afin d’adopter des couleurs dont les contrastes sont suffisants, ou encore, aux programmeurs d’assurer une association explicite entre les libellés et leurs champs correspondants dans un formulaire.

Que l’on songe aux analystes, aux ergonomes, aux designers, aux rédacteurs ou aux architectes d’information, chacun d’entre eux est appelé à prendre des décisions ou porter des actions qui peuvent avoir un impact sur le potentiel d’accessibilité du projet. Pour éviter que ces interventions aient des conséquences importantes quant au résultat final, il importe que l’accessibilité devienne une responsabilité partagée à travers tous les intervenants.

4. Limiter la validation aux seuls critères techniques

De plus, la mise en accessibilité d’un site Web est très souvent perçue comme la vérification, voire la validation d’une simple liste d’épicerie. Les gestionnaires croient à tort qu’il suffit de cocher chaque exigence présente dans ces listes pour produire un site accessible. Dans les faits, ce n’est pas aussi simple.

Si l’application de toutes les exigences permet éventuellement d’atteindre une conformité à un standard (plus à ce sujet au prochain point), l’application systématique des exigences seules n’est pas un gage suffisant d’accessibilité. Pour assurer qu’un site Web est accessible, au delà des critères techniques, il faut aussi prévoir des tests fonctionnels avec des outils d’adaptation informatiques qui permettront de valider que l’expérience utilisateur est concluante. En effet, il est tout à fait possible de produire un site répondant à toutes les règles d’accessibilité, mais qui est tout de même inaccessible... il suffit d’avoir manqué quelques petites subtilités en cours de route qui pourraient apporter un degré de confusion important à l’utilisateur n’étant pas en mesure de percevoir visuellement l’interface.

Par tests fonctionnels, nous entendons le recours à des outils tels que synthèses vocales, lecteurs d’écran et logiciels de grossissement pour vérifier que le résultat interprété par ces outils correspond bien au résultat observé lors d’une validation visuelle des pages. À titre d’exemples, une absence de ponctuation dans les textes de remplacement des images ou l’ordre de lecture de contenus présentés en tableau HTML peut s’avérer très différent de ce que l’on imagine, simplement en intégrant les pages.

En ajoutant les tests fonctionnels aux tests techniques, les producteurs de contenus Web s’assurent de ne rien échapper lors des tests de contrôle qualité liés à l’accessibilité.

5. Confondre les notions de mise en accessibilité et de conformité à l’accessibilité

Pour la plupart des gestionnaires et des développeurs Web, les notions de conformité à l’accessibilité et mise en accessibilité des contenus Web sont interchangeables. Or, il s’avère que les deux notions ont des significations très différentes et aucune ne peut se substituer à l’autre ou se porter comme un gage d’assurance de l’autre.

La notion d’accessibilité suppose un effort à faire tomber un maximum de barrières à l’utilisation des contenus Web pour les personnes handicapées ou potentiellement à risque d’exclusion. Notion subjective, elle suppose la mise en place de plusieurs efforts d’adaptation des contenus pour répondre aux besoins d’adaptation particuliers des utilisateurs. Elle suppose des tests fonctionnels pour assurer qu’au-delà de l’application des règles, les efforts mis en place ont de réels effets bénéfiques sur l’expérience utilisateur des personnes handicapées qui consultent ces contenus. Les résultats de la mise en accessibilité ne se mesurent cependant pas objectivement, car il est impossible de juger à partir de quel moment un site Web est « suffisamment accessible ».

La notion de conformité quant à elle, est beaucoup plus tranchée. Parfaitement objective, elle suppose l’application efficace, satisfaisante et systématique de toutes les règles mises en place dans un standard. Lorsque l’on parle de mise en accessibilité d’un site Web, il revient au développeur Web (en fonction des intentions ou des budgets) de juger à partir de combien d’efforts le résultat est satisfaisant : 50 %, 70 %, etc. Dans un contexte de conformité, 99,9 % d’efforts ne suffiront pas. Lorsque l’on parle de conformité, on ne peut se satisfaire de moins de 100 % d’efforts et de réussites. La notion de conformité ne suppose cependant pas de tests fonctionnels, se limitant à l’application dogmatique des exigences prescrites et mesurables.

Il est donc possible de développer un site conforme qui ne réponde pas tout à fait au besoin des utilisateurs car certains détails auraient échappés aux concepteurs, ou dans le même esprit, un site « suffisamment accessible » aux yeux des mêmes développeurs, mais qui ne répondraient pas en totalité aux besoins d’une clientèle particulière qui auraient été laissée de côté lors de la démarche. D’où l’importance de cumuler les deux objectifs pour atteindre le résultat le plus inclusif possible.

6. Présumer que les outils feront tout le travail

Dans un monde idéal (un monde où la notion même de contrôle qualité pourrait relever de machines), il serait inutile de se pencher sur les besoins d’adaptation des personnes handicapées sur le Web car les outils seraient en mesure de prendre tout ça en charge naturellement. En fonction des législations en place dans les pays respectifs de leurs fabricants, les outils viennent souvent avec des déclarations toutes aussi positives que fracassantes quant à leur potentiel d’accessibilité. Plusieurs gestionnaires ont tendance à croire un peu trop facilement que ces outils peuvent faire tout le travail à leur place, mais dans les faits, il n’en est rien. Quiconque remet la responsabilité de l’objectif d’accessibilité entre les mains des outils ou des plateformes qu’il utilise est voué à de très grandes déceptions le jour où il entreprendra de réels tests d’évaluation pour mesurer le niveau d’accessiiblité obtenu dans son projet.

Il faut savoir que de l’ensemble des exigences d’accessibilité contenues dans les standards, une minorité seulement peut être automatisable au point où l’intervention humaine, à un niveau ou un autre, deviendrait inutile. On estime subjectivement autour de 30 à 35 % le nombre d’exigences des standards pouvant être complètement automatisées. Pour le reste, une intervention humaine s’avère absolument nécessaire. À titre d’exemple, s’il est aisé de vérifier automatiquement la présence d’attributs alt pour des images, il l’est beaucoup moins de vérifier la pertinence de ces mêmes textes de remplacement par une simple validation automatique. Il importe donc qu’au-delà des outils retenus pour le développement, l’équipe de production prenne connaissance du détails technique des exigences d’accessibilité afin d’être en mesure de les mettre en place avec succès. Autrement, une bonne part des efforts investis dans la démarche le seront inévitablement en vain.

7. Sous-estimer l’impact des plateformes technologiques

Dans le même ordre d’idées, plusieurs gestionnaires sont aussi victimes de pensée magique en ce sens qu’ils présument que puisqu’ils font appels à des plateformes technologiques de haut niveau acquises à fort prix, les enjeux d’accessiiblité seront forcément pris en charge de manière satisfaisante. Or, la réalité est bien différente.

Chez AccessibilitéWeb, nous ne comptons plus le nombre de clients aux prises avec des plateformes technologiques de tout ordre où les recommandations d’améliorations les plus élémentaires se heurtent aux limites des outils en place. Souvent, les changements en apparence très simples comme remplacer un <p id="titre"> par un simple <h1> sont bien simples en théorie, mais impossibles dans la pratique car les développeurs Web n’ont pas accès aux sources de leurs outils pour aller modifier les bouts de code fautifs. Comment peut-on espérer, dans un tel contexte, atteindre nos objectifs de conformité ?

S’il est vrai que les plateformes technologiques en logiciels libres présentent généralement un meilleur potentiel d’accessibilité en raison de la possibilité d’aller modifier le code généré à même les outils, il ne faudrait pas conclure pour autant que les outils propriétaires ne peuvent répondre présents lorsque les exigences d’accessibilité doivent être appliquées. Certains outils sont plus souples que d’autres. L’important étant d’être conscient de cette réalité et de se poser les bonnes questions lorsque vient le temps de choisir une plateforme plutôt qu’une autre.