L’accessibilité ne se rattrape pas à la fin d’un projet.

Deux familles d’exigences, deux coûts

Les règles pour l’accessibilité des contenus web, dans leur version 2.2 publiée par le W3C, couvrent une soixantaine de critères. Du point de vue d’un calendrier de projet, ils se répartissent en deux familles dont les économies n’ont rien à voir.

La première regroupe ce qui se corrige à peu près à tout moment : un contraste insuffisant, un texte alternatif manquant, un intitulé de bouton ambigu. Ces corrections sont locales, elles ne remettent rien en cause, et un audit tardif les traite correctement.

La seconde dépend de décisions structurelles : la hiérarchie des titres, l’ordre de tabulation, la gestion du focus dans les fenêtres modales, le nom et le rôle exposés par un composant interactif, la relation entre une étiquette et son champ. Corriger ces éléments en fin de projet ne signifie pas ajuster une valeur : cela signifie rouvrir des composants utilisés partout, et parfois revoir la manière dont une page est construite.

Un audit en fin de parcours ne découvre pas des défauts. Il découvre des décisions, prises plusieurs mois plus tôt par des personnes qui ne savaient pas qu’elles les prenaient.

Les trois moments où l’accessibilité se décide

Dans la plupart des projets, trois décisions déterminent l’essentiel du résultat, et aucune ne porte le mot accessibilité dans son intitulé.

Le premier moment est de loin le plus rentable. Un champ de formulaire correctement construit une fois — étiquette associée, message d’erreur annoncé, focus visible — règle le problème pour les cent écrans qui l’utiliseront. À l’inverse, un composant défaillant reproduit son défaut à l’identique dans tout le produit, et l’audit final le comptera cent fois.

Le deuxième est le plus négligé. Si le gestionnaire de contenu permet de composer un titre avec du texte en gras plutôt qu’avec une balise de titre, la structure se dégradera malgré une conception irréprochable. L’accessibilité d’un site vivant dépend autant de ce que l’outil d’édition rend facile que de ce que le code rend possible.

Un cadre légal qui s’est resserré

Longtemps traité comme une bonne pratique, le sujet est devenu une obligation dans plusieurs juridictions. Au Canada, la Loi canadienne sur l’accessibilité encadre les organisations de compétence fédérale et s’appuie sur une norme technique alignée sur la norme européenne EN 301 549, elle-même construite sur les règles du W3C. En Europe, l’acte législatif sur l’accessibilité étend des obligations à des produits et services numériques du secteur privé.

Pour une organisation québécoise, la conséquence pratique ne dépend pas seulement de son propre statut. Elle dépend aussi de ses clients : un appel d’offres public, un partenaire international ou un grand donneur d’ordre imposera régulièrement un niveau de conformité et une preuve. À ce moment-là, l’accessibilité n’est plus une question d’intention, c’est une pièce contractuelle.

Intégrer sans alourdir le projet

La crainte habituelle est celle d’un surcoût généralisé. Elle est justifiée lorsque l’accessibilité est traitée comme une couche supplémentaire, et infondée lorsqu’elle est intégrée aux décisions qui se prennent de toute façon.

• Traiter les composants partagés comme le point de conformité principal, et les vérifier une fois pour toutes.
• Inclure deux ou trois vérifications simples dans la définition du fini : navigation au clavier, focus visible, structure des titres.
• Confier au modèle de contenu la responsabilité de la structure, plutôt qu’à la discipline des rédacteurs.
• Faire intervenir une vérification humaine tôt sur un parcours critique, plutôt qu’un audit complet à la fin.

Aucune de ces mesures n’exige une expertise rare. Elles exigent surtout de déplacer la question de quelques mois en amont, là où une décision coûte encore une conversation plutôt qu’une reprise. C’est le seul moment où l’accessibilité est économiquement banale.