Développement WordPress accessible

L’approvisionnement public et institutionnel au Canada nomme couramment une norme d’accessibilité dans les exigences : les WCAG 2.1 ou 2.2 au niveau AA, la Loi canadienne sur l’accessibilité pour les organisations sous réglementation fédérale, la LAPHO en Ontario, les standards SGQRI 008 du gouvernement du Québec pour les organismes publics provinciaux, ou EN 301 549 quand une référence européenne est utilisée. Laquelle s’applique dépend de qui achète et de ce qui est acheté.

Ce qu’elles ont en commun, c’est que la question reçoit rarement une réponse par oui ou par non. Elle est notée. Un évaluateur compare ce que deux fournisseurs ont dit qu’ils construiraient, comment ils le prouveraient, et ce qu’il advient du site dix-huit mois plus tard quand un agent des communications a ajouté deux cents pages. Ce sont trois réponses différentes, et la plupart des soumissions ne donnent que la première.

L’accessibilité dans un projet WordPress n’est pas une tâche. C’est un ensemble de décisions réparties dans le design, le thème, la bibliothèque de blocs et l’expérience d’édition, dont la plupart sont bon marché quand elles sont prises tôt et coûteuses quand elles sont découvertes en tests.

En pratique, les sites échouent rarement sur le thème qu’un développeur a écrit. Ils échouent sur ce qui y est rattaché. Voici les six que nous rencontrons le plus souvent, et les six sont des décisions plutôt que des accidents.

Un site est accessible le jour de son lancement parce que des développeurs l’ont construit ainsi. Il est accessible deux ans plus tard parce que les personnes qui ajoutent du contenu ne pouvaient pas facilement le casser. Ce sont deux problèmes différents, et un seul se règle par une revue de code.

Nous construisons les interfaces éditoriales comme des systèmes de blocs contraints plutôt que comme des toiles ouvertes : des composants qui portent déjà la bonne structure, des titres qui suivent le plan du document au lieu d’être choisis pour leur taille, des champs d’image qui demandent un texte de remplacement là où il en faut un, et des mises en page qu’un rédacteur ne peut pas réorganiser accidentellement dans un ordre illisible. Quand un motif a des exigences d’accessibilité qu’un rédacteur ne peut pas voir (un contraste minimal, une étiquette obligatoire, une légende), le bloc les impose plutôt que de les documenter.

Le résultat est plus étroit qu’un constructeur de pages, délibérément. Un rédacteur renonce à placer n’importe quoi n’importe où, et obtient un système où l’option accessible est celle par défaut et où l’option inaccessible n’est le plus souvent pas offerte.

Nous sommes un studio de développement, pas un organisme de certification. Nous construisons selon une norme nommée, nous testons ce que nous construisons, et nous documentons les deux. Mais nos propres tests ne sont pas un audit tiers, et nous ne les présentons pas comme tels. Quand un projet exige une certification indépendante ou un audit formel, c’est un mandat distinct avec un auditeur en accessibilité, et nous le dirons plutôt que de l’absorber dans un devis.

Nous pouvons préparer l’information technique qu’exige un rapport de conformité en accessibilité ou une réponse de type VPAT, à partir de ce qui a été construit et de ce qui a été testé. Nous n’en remplirons pas un avec des affirmations que la construction ne soutient pas.

Nous n’installons pas non plus de widgets de surcouche d’accessibilité. Ils ne rendent pas conforme un site qui ne l’est pas, ils sont fréquemment détectés et rejetés en évaluation, et ils ajoutent une couche de JavaScript entre les utilisateurs et le contenu que les personnes utilisant des technologies d’assistance rapportent largement comme aggravant les choses. Si l’accessibilité est une exigence, le correctif appartient au site.