Ce que les exigences d’accessibilité du secteur public canadien demandent vraiment

Les exigences d’accessibilité web du secteur public canadien se règlent au début d’un projet, dans l’appel d’offres lui-même. Si l’appel d’offres demande un site « accessible », chaque soumissionnaire en promettra un et vous n’aurez rien à comparer. Une liste de vérification passée la semaine avant la mise en ligne arrive beaucoup trop tard.

Une partie de la difficulté vient du fait que le Canada n’a pas de règle unique. Il y a un standard du gouvernement du Québec, une norme fédérale et une loi ontarienne, et les documents d’appel d’offres citent parfois les trois de façon approximative. Voyons-les un à un, puis ce qu’il faut exiger quand vous rédigez l’appel d’offres.

Trois cadres, une seule cible technique

Québec : le SGQRI 008 3.0

Le Standard sur l’accessibilité des sites Web du gouvernement du Québec, le SGQRI 008, en est à sa version 3.0. Il s’applique aux nouveaux contenus et aux refontes depuis le 29 avril 2024 et repose sur les WCAG 2.1 de niveau AA.

Le contenu publié avant cette date reste évalué selon la version précédente, le SGQRI 008 2.0. Un site plus ancien qu’on a continué d’alimenter porte donc deux obligations à la fois. Ce partage pèse au moment de cadrer une refonte. Les nouveaux gabarits font passer les nouvelles pages à la version 3.0, mais l’archive que vous migrez garde son statut tant que personne ne s’en occupe. Il faut décider quelles pages et quels documents anciens seront corrigés, retirés ou republiés. Prenez cette décision dans le plan de projet, pendant qu’il reste du temps et du budget pour la mettre en œuvre.

Fédéral : la CAN/ASC-EN 301 549:2024

Normes d’accessibilité Canada a adopté la norme européenne EN 301 549:2021 comme Norme nationale du Canada le 31 mai 2024, sous le nom CAN/ASC-EN 301 549:2024. L’adoption est intégrale, si bien que ses clauses web mènent au même endroit que la version européenne : les WCAG 2.1 de niveau AA.

La norme a pris du poids quand le Règlement canadien sur l’accessibilité a été modifié pour l’imposer. Les organisations du secteur public fédéral doivent rendre conformes leurs pages web nouvelles ou mises à jour à partir du 5 décembre 2027, puis leurs applications mobiles et leurs documents numériques à partir du 5 décembre 2028. Les grandes entreprises sous réglementation fédérale (500 employés ou plus) assument les mêmes obligations à partir du 5 décembre 2028. Les entreprises de taille moyenne (100 à 499 employés) doivent rendre conformes leurs pages web nouvelles ou mises à jour à partir de la même date. Les trois groupes doivent former leur personnel à l’accessibilité numérique d’ici le 5 décembre 2027. Un site que vous commandez d’ici un an ou deux sera fort probablement encore en ligne à ces dates.

Ontario : la LAPHO et le RNAI

Le Règlement sur les normes d’accessibilité intégrées de l’Ontario nomme toujours les WCAG 2.0 de niveau AA comme exigence légale pour les sites web publics et leur contenu. Il vise les organisations désignées du secteur public, ainsi que les entreprises et les OBNL de 50 employés ou plus. Les nouveaux sites devaient respecter le niveau A dès le 1er janvier 2014. Depuis le 1er janvier 2021, tous les sites et leur contenu doivent atteindre le niveau AA, sauf pour les sous-titres en direct et l’audiodescription préenregistrée.

C’est le plancher qui sert en cas d’inspection. Bien des auditeurs et des évaluateurs travaillent plutôt avec les WCAG 2.2 AA, la version publiée par le W3C en octobre 2023. Viser le 2.0 seulement, c’est construire avec deux versions de retard un site qui doit durer des années.

La LAPHO impose aussi des obligations de déclaration, en plus de la norme technique. Les organisations désignées du secteur public déposent un rapport de conformité aux normes d’accessibilité tous les deux ans, les entreprises et les OBNL de 20 employés ou plus, tous les trois ans. Un rapport oublié compte comme un manquement distinct, même si le site respecte la norme, et c’est souvent lui qui vaut un suivi de la province.

La cible technique bouge moins que la paperasse

Mis côte à côte, les trois cadres visent presque la même chose. Le Québec et le fédéral renvoient aux WCAG 2.1 AA. L’Ontario exige le 2.0 AA dans la loi, alors que bien des auditeurs attendent le 2.2. Un site construit selon les WCAG 2.2 AA couvre la portion WCAG des trois cadres, puisque la version 2.2 conserve tous les critères du 2.1 sauf le 4.1.1 (analyse syntaxique), que le W3C a retiré comme désuet. Elle ajoute des critères sur la visibilité du focus, les solutions de rechange au glissement, la taille des cibles, l’aide cohérente, la saisie redondante et l’authentification accessible.

N’importe quel soumissionnaire peut expliquer comment il atteindra la norme. Prouver qu’il l’a atteinte, et que le site restera conforme après le lancement, est plus difficile, alors exigez cette preuve.

Ce qu’il faut demander aux soumissionnaires

• La norme, nommée avec sa version. Vous ne pouvez pas noter « entièrement accessible » ni « conforme aux WCAG ». « WCAG 2.2 niveau AA, testé selon le SGQRI 008 3.0 » se vérifie. Nommez-la dans l’appel d’offres et demandez aux soumissionnaires de la confirmer.
• Un relevé de tests manuels. Les outils automatisés ne repèrent qu’une partie des défauts, alors un macaron d’extension prouve peu de chose. Demandez la navigation au clavier seul, des passages au lecteur d’écran sur les vrais gabarits et des résultats consignés critère par critère.
• Une liste écrite des exceptions connues. Les grands sites en ont généralement quelques-unes, souvent une intégration externe ou un vieux lot de documents. Un soumissionnaire qui les déclare avec une date de correction a fait ses tests. Une soumission qui n’en déclare aucune laisse croire le contraire.
• L’expérience d’édition. Un site est accessible le jour du lancement parce qu’on l’a construit ainsi. Trois ans plus tard, il ne le reste que si les personnes qui y publient ne peuvent pas le briser facilement. Demandez comment le CMS encadrera vos rédacteurs.
• Les documents. Les sites publics diffusent énormément de PDF. Une bibliothèque jamais balisée fait souvent échouer à l’audit un site par ailleurs conforme. Demandez ce que chaque soumission prévoit pour eux.

Où la conformité se perd

Les gabarits qu’un développeur a écrits et testés tiennent généralement bien à l’audit. Les défauts apparaissent tout autour :

• Les extensions qui injectent leur propre balisage, surtout les formulaires, les carrousels, les calendriers et les bandeaux de témoins, que personne n’a inclus dans l’audit.
• Les composants interactifs faits sur mesure qui recréent mal un contrôle natif, alors que l’élément HTML de base était accessible d’emblée.
• Les couleurs de marque qui n’atteignent pas un contraste de 4,5:1 sur le texte courant, une découverte faite après l’approbation de l’identité visuelle.
• Les modules de paiement, de cartographie ou de réservation d’autres fournisseurs. Ils s’affichent dans votre page, mais vous ne pouvez pas toucher à leur code.
• Le contenu ajouté après le lancement : intertitres faits en gras, liens « cliquez ici », images au texte de remplacement vide, tableaux utilisés pour la mise en page.

Quatre de ces cinq points découlent de décisions prises avant la première ligne de code de gabarit. C’est la meilleure raison de traiter l’accessibilité dès l’étape des exigences. Quand elle devient un problème de tests, les choix coûteux sont déjà faits.

Que faire avant de lancer l’appel d’offres

1. Fixez la cible aux WCAG 2.2 niveau AA dans les exigences et nommez la norme qui s’applique à votre ordre de gouvernement.
2. Testez votre site actuel à la main, au clavier et au lecteur d’écran. Vous verrez vite l’ampleur du travail que la refonte devra absorber.
3. Faites l’inventaire de vos documents. Comptez-les, établissez combien sont balisés et décidez du sort des autres. Notre guide pour migrer des milliers de documents explique comment les trier.
4. Vérifiez dès maintenant le contraste de vos couleurs de marque, pendant que les changer relève encore d’une discussion de design et non d’une reconstruction.
5. Prévoyez une liste d’exceptions dans le formulaire de soumission. Un soumissionnaire qui la remplit honnêtement convainc davantage que celui qui prétend à la perfection.

Les normes sont assez stables pour qu’on construise en fonction d’elles en toute confiance. Comparez les soumissions sur les preuves qu’elles promettent de remettre, comme un relevé de tests, une liste d’exceptions et un plan pour les documents.

Nous construisons selon les WCAG 2.2 AA et remettons ces preuves avec le site. Notre page sur le développement WordPress accessible explique comment.