L’accessibilité arrivait autrefois à la fin d’un projet web du secteur public, sous forme de liste de vérification exécutée la semaine précédant la mise en ligne. Elle arrive maintenant au début, comme exigence évaluée dans l’appel d’offres, et votre réponse est comparée à celle des autres soumissionnaires. Les équipes qui la traitent comme une étape de nettoyage technique perdent des points avant qu’une seule page soit construite.
La confusion se comprend. Le Canada n’a pas une seule règle d’accessibilité web. Il a une norme fédérale, une loi provinciale en Ontario, un standard gouvernemental distinct au Québec, et un vocabulaire d’approvisionnement qui cite parfois les trois de façon imprécise. Voici ce que chacun exige réellement, et ce qu’un évaluateur s’attend à voir dans votre réponse.
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 et s’applique aux nouveaux contenus et aux refontes depuis le 29 avril 2024. Il repose sur les WCAG 2.1 de niveau AA.
Le contenu publié avant cette date demeure évalué selon la version précédente, le SGQRI 008 2.0. Cette coupure crée une obligation double sur tout site antérieur au changement et enrichi depuis. Elle compte au moment de cadrer une refonte : reconstruire les gabarits fait passer les nouvelles pages au 3.0, mais l’archive que vous migrez ne suit pas automatiquement. Décider quel contenu historique est corrigé, lequel est retiré et lequel est republié est une décision de contenu avec une conséquence de conformité. Elle appartient au plan, pas à la dernière semaine d’assurance qualité.
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, publiée sous le code CAN/ASC-EN 301 549:2024. L’adoption est identique, donc les clauses web pointent là où pointent les clauses européennes : les WCAG 2.1 de niveau AA.
Ce qui en fait plus qu’un exercice de papier, c’est l’échéancier réglementaire qui l’accompagne. Des modifications au Règlement canadien sur l’accessibilité prévoient des obligations progressives pour les nouvelles pages web, les applications mobiles et les documents numériques : à partir de décembre 2027 pour les organisations du secteur public fédéral, et de décembre 2028 pour les grandes et moyennes entreprises sous réglementation fédérale. Tout ce que vous construisez aujourd’hui pour un client fédéral sera encore en service à 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. C’est le plancher mesuré en cas de contrôle. Dans les faits, les auditeurs et les évaluateurs travaillent désormais avec les WCAG 2.2 AA, et un passage à cette version est largement anticipé avant la fin de la décennie. Construire au 2.0 seul, c’est construire vers une norme qui sera dépassée durant la vie utile du site.
Distincte de la norme technique, la LAPHO impose aussi des obligations de déclaration. Les organisations désignées du secteur public et les grandes organisations privées et sans but lucratif déposent des rapports de conformité selon un cycle fixe. Manquer le rapport est un défaut différent de manquer la norme, et c’est celui qui génère de la correspondance.
La cible technique bouge moins que la paperasse
Lus ensemble, les trois cadres mènent à une conclusion utile : la cible sous-jacente bouge à peine. Le fédéral et le Québec aboutissent aujourd’hui aux WCAG 2.1 AA. L’Ontario est légalement au 2.0 AA et concrètement au 2.2. Construisez au niveau WCAG 2.2 AA et vous satisfaites les trois, parce que le 2.2 est additif : il conserve tous les critères du 2.1 sauf un, devenu obsolète, et ajoute un petit nombre de nouveaux critères portant sur la visibilité du focus, les solutions de rechange au glissement, la taille des cibles, l’aide cohérente et la saisie redondante.
La norme n’est donc pas la partie difficile. La partie difficile, c’est de prouver que vous l’avez atteinte, et de la maintenir.
Ce que les évaluateurs demandent et que les soumissionnaires préparent rarement
- La norme, nommée et versionnée. « Entièrement accessible » et « conforme aux WCAG » ne sont pas des réponses. « WCAG 2.2 niveau AA, testé selon le SGQRI 008 3.0 » est une réponse, et elle est vérifiable.
- Un relevé de tests, pas un macaron d’extension. L’outillage automatisé détecte environ le tiers des défauts. Un évaluateur qui connaît le domaine cherche la portion manuelle : parcours au clavier seul, passages au lecteur d’écran sur les vrais gabarits, et résultats consignés par critère plutôt qu’en note globale.
- Une liste écrite des exceptions connues. Tout grand site en a, généralement une intégration tierce ou un fonds documentaire hérité. Les déclarer avec une date de correction se lit comme de la compétence. N’en déclarer aucune se lit comme un site non testé.
- L’expérience d’édition. Le site est accessible le jour du lancement parce que vous l’avez construit ainsi. Il l’est encore la troisième année parce que les personnes qui y publient ne peuvent pas facilement le briser. Les évaluateurs demandent de plus en plus comment le CMS encadre les rédacteurs.
- Le traitement des documents. Les sites du secteur public sont des systèmes de diffusion documentaire. Une bibliothèque de PDF jamais balisés est la raison la plus fréquente pour laquelle un site autrement conforme échoue à un audit.
Où la conformité se perd réellement
D’après notre expérience, le défaut ne se trouve presque jamais dans les gabarits qu’une équipe de développement a écrits et testés. Il se trouve dans les coutures :
- Les extensions qui injectent leur propre balisage, en particulier les formulaires, les carrousels, les calendriers et les bandeaux de témoins, dont aucun ne faisait partie de votre audit.
- Les composants interactifs faits maison qui réimplémentent mal un contrôle natif, alors que l’élément natif aurait été accessible gratuitement.
- Les palettes de marque incapables d’atteindre 4,5:1 sur le texte courant, découvertes après l’approbation de l’identité visuelle.
- Les intégrations tierces de paiement, de cartographie ou de réservation, qui siègent dans votre page et hors de votre contrôle.
- Le contenu ajouté après le lancement : titres non structurés, liens intitulés « cliquez ici », images à l’attribut alt vide, tableaux utilisés pour la mise en page.
Quatre de ces cinq points relèvent de décisions prises avant la première ligne de code de gabarit. C’est le véritable argument pour placer l’accessibilité dans la phase des exigences : quand elle devient un problème de test, les choix coûteux sont déjà faits.
Quoi faire avant votre prochaine soumission
- Nommez votre cible : WCAG 2.2 niveau AA, en précisant selon quelle norme vous testez pour la juridiction visée.
- Faites un passage manuel au clavier et au lecteur d’écran sur votre propre site actuel. C’est le moyen le plus rapide de savoir si votre affirmation survit au contact d’un testeur.
- Inventoriez vos documents. Comptez-les, établissez combien sont balisés, et décidez du sort des autres.
- Vérifiez vos couleurs de marque contre l’exigence de contraste maintenant, pendant que les changer relève encore d’une conversation de design plutôt que d’une reconstruction.
- Rédigez la liste des exceptions. Elle sera plus courte que vous ne le craignez et plus convaincante qu’une prétention à la perfection.
Le travail d’accessibilité récompense les équipes qui commencent tôt et documentent au fur et à mesure, et il pénalise celles qui le traitent comme une inspection finale. Les normes sont assez stables pour qu’on construise vers elles avec confiance. La question que pose réellement un évaluateur est de savoir si vous pouvez montrer votre travail.
Nous construisons selon cette norme et remettons les preuves avec le site. Vous pouvez lire notre approche sur notre page développement WordPress accessible.