Votre site respecte WCAG 2.0 — voici ce que WCAG 2.2 détecte en plus (Ontario, 2026)

Le minimum légal en matière d'accessibilité des sites Web en Ontario selon le RNAI (Règlement sur les normes d'accessibilité intégrées) est WCAG 2.0 niveau AA — une norme que le W3C (World Wide Web Consortium) a publiée pour la première fois en 2008. La norme W3C en vigueur est WCAG 2.2 niveau AA, avec une recommandation W3C datée du 12 décembre 2024 (www.w3.org/TR/WCAG22/). L'écart entre ces deux versions est réel et mesurable : WCAG 2.2 ajoute six nouveaux critères de succès de niveaux A et AA qui n'existaient pas dans WCAG 2.0. À six mois de l'échéance du 31 décembre 2026 pour le dépôt du Rapport de conformité à la LAPHO (Loi sur l'accessibilité pour les personnes handicapées de l'Ontario) RCL (Rapport de conformité en matière d'accessibilité), les entreprises ontariennes qui se croient « pleinement conformes » parce qu'elles ont réussi un audit WCAG 2.0 risquent fort de ne pas satisfaire une part importante des tests d'accessibilité actuels.

Faits essentiels

• Le RNAI (O.Reg 191/11, art. 14) exige que les organisations de 50 employés ou plus rendent leurs sites Web publics et leurs contenus Web conformes à WCAG 2.0 niveau AA — c'est le plancher légal (ontario.ca / e-Laws).
• WCAG 2.2 a d'abord été publiée à titre de recommandation W3C le 5 octobre 2023 ; l'édition courante est datée du 12 décembre 2024 (W3C, www.w3.org/TR/WCAG22/). Il s'agit de la norme en vigueur.
• WCAG 2.2 ajoute neuf nouveaux critères de succès par rapport à WCAG 2.1 — dont six sont de niveau A ou AA (applicables à des fins de conformité légale) et trois sont de niveau AAA (W3C, WCAG 2.2).
• WCAG 2.2 supprime également un critère de la version 2.1 — 4.1.1 Analyse syntaxique — jugé obsolète pour les navigateurs modernes (W3C).
• Les tribunaux américains traitant des réclamations liées à l'ADA (Americans with Disabilities Act) font couramment référence à WCAG 2.1 ou 2.2 AA comme critère d'évaluation, et non à WCAG 2.0 — ce qui est pertinent pour toute entreprise ontarienne vendant à des clients américains (ADA Title III Blog, Seyfarth Shaw, 2025).
• La nouvelle norme fédérale canadienne d'accessibilité numérique CAN/ASC – EN 301 549:2024, intégrée dans le DORS/2025-255, incorpore des exigences de niveau WCAG 2.2 par le biais de son article 9 (Web) — applicable aux employeurs sous réglementation fédérale de 100 employés ou plus (Gazette du Canada, Partie II, vol. 159, n° 26).
• L'échéance du 31 décembre 2026 pour le dépôt du RCL s'applique aux organisations du secteur privé et aux organismes sans but lucratif ontariens de 20 employés ou plus (ontario.ca).

Quelle est la norme légale minimale d'accessibilité Web en Ontario ?

Le RNAI (Règlement sur les normes d'accessibilité intégrées, O.Reg 191/11) est le règlement pris en vertu de la LAPHO qui établit la norme d'accessibilité Web concrète. L'article 14 exige que les organisations de 50 employés ou plus s'assurent que leurs sites Web publics et leurs contenus Web respectent WCAG 2.0 niveau AA, à deux exceptions près : les sous-titres en direct et les audiodescriptions préenregistrées demeurent au niveau A pour les organisations du secteur privé.

Les organisations de 1 à 49 employés doivent respecter WCAG 2.0 niveau A pour les nouveaux sites et les nouveaux contenus Web publiés après le 1er janvier 2012.

Le RCL soumis au gouvernement de l'Ontario demande aux organisations de rendre compte de la façon dont elles respectent les normes LAPHO, y compris les exigences Web du RNAI. La prochaine échéance pour le dépôt du RCL par les organisations du secteur privé et les OSBL de 20 employés ou plus est le 31 décembre 2026.

WCAG 2.0 demeure le texte légal. Cette distinction est importante : une organisation qui teste et corrige son site selon WCAG 2.2 AA satisfait automatiquement WCAG 2.0 AA et 2.1 AA, chaque version étant rétrocompatible. Mais une organisation qui s'arrête au plancher 2.0 est en retard sur les pratiques actuelles d'une façon qui se manifeste lors des audits, des tests utilisateurs et des litiges.

En quoi WCAG 2.2 diffère-t-elle de WCAG 2.0 ?

WCAG 2.0 a été publiée en décembre 2008. Elle a établi les quatre principes fondamentaux — perceptible, utilisable, compréhensible, robuste — et le cadre des niveaux A, AA et AAA qu'héritent toutes les versions ultérieures. Elle était exhaustive pour son époque. Mais les téléphones intelligents, les applications Web dynamiques, les flux d'authentification complexes et la navigation tactile n'étaient pas encore dominants.

WCAG 2.1, publiée en juin 2018, a ajouté 17 nouveaux critères de succès ciblant les utilisateurs mobiles, les personnes ayant une basse vision et les personnes avec des handicaps cognitifs ou d'apprentissage. Si votre site a été conçu selon « WCAG 2.0 AA » sans audit depuis, il peut déjà échouer à plusieurs critères 2.1 — notamment les exigences liées à la navigation tactile mobile et à la gestion du focus.

WCAG 2.2, la norme actuelle, ajoute neuf critères supplémentaires par rapport à 2.1. Elle supprime un critère (4.1.1 Analyse syntaxique) rendu redondant par les navigateurs modernes. Le résultat net est une norme plus protectrice pour les utilisateurs de clavier, les utilisateurs mobiles et les utilisateurs avec des handicaps cognitifs — les trois groupes les plus fréquemment exclus par les sites Web d'entreprises ontariennes typiques.

Lorsqu'un auditeur, un tribunal ou la norme fédérale canadienne EN 301 549 fait référence aux « meilleures pratiques actuelles », c'est WCAG 2.2 AA qui est visée.

Quels sont les 6 nouveaux critères de niveaux A et AA que les entreprises ontariennes ne respectent probablement pas encore ?

Les trois ajouts de niveau AAA (2.4.12, 2.4.13, 3.3.9) sont aspirationnels — ils ne sont pas requis pour la conformité légale. Les six critères ci-dessous sont ceux qui s'appliquent au niveau A ou AA et qu'un site conçu uniquement pour WCAG 2.0 ne teste pas (W3C, WCAG 2.2) :

1. 2.4.11 Focus non masqué (minimum) — Niveau AA Lorsqu'un utilisateur navigue vers un composant au clavier, l'indicateur de focus de ce composant ne doit pas être entièrement caché par des en-têtes persistants, des bannières de consentement aux témoins, des pieds de page fixes ou d'autres éléments contrôlés par l'auteur. De nombreux sites ontariens utilisent des barres de navigation permanentes ou des bannières RGPD qui masquent entièrement l'élément sur lequel porte le focus. Ce critère exige qu'au moins une partie de l'indicateur de focus demeure visible.

2. 2.5.7 Mouvements de glissement — Niveau AA Toute fonctionnalité reposant sur un geste de glisser-déposer — curseurs, listes triables, défilement de carte, carrousels commandés par toucher-glisser — doit également proposer une alternative à pointeur unique (un bouton, un clic-déplacer ou une commande clavier) ne nécessitant pas de glissement. Les utilisateurs souffrant de troubles moteurs ou naviguant par commutateur d'accès ne peuvent pas effectuer des gestes de glissement soutenus de manière fiable.

3. 2.5.8 Taille de la cible (minimum) — Niveau AA Les éléments interactifs — boutons, liens, contrôles de formulaire — doivent avoir une taille de cible d'au moins 24 × 24 pixels CSS, sauf si l'élément est en ligne dans une phrase, est contrôlé par le navigateur ou bénéficie d'un espacement suffisant par rapport aux cibles adjacentes. Un site rempli de liens icônes de 16 pixels ou d'éléments de menu serrés sans rembourrage échoue généralement à ce critère.

4. 3.3.8 Authentification accessible (minimum) — Niveau AA Si une étape de connexion ou d'authentification demande aux utilisateurs de réaliser un test de fonction cognitive — résoudre un casse-tête, identifier des images dans une grille ou retranscrire un code — il doit exister un mécanisme alternatif ne nécessitant pas de rappel cognitif ni de transcription : un gestionnaire de mots de passe, un lien magique par courriel, une authentification biométrique ou un code par SMS. Les implémentations CAPTCHA standard échouent souvent à ce critère.

5. 3.2.6 Aide cohérente — Niveau A Si un site Web propose un mécanisme d'aide — un lien de contact, un clavardage, un numéro de téléphone ou une FAQ — sur un ensemble de pages (par exemple dans l'en-tête ou le pied de page), ce mécanisme doit apparaître au même emplacement relatif sur chaque page. Cela évite aux utilisateurs avec des handicaps cognitifs d'avoir à relocaliser les options d'assistance à chaque étape de navigation.

6. 3.3.7 Saisie redondante — Niveau A Dans le cadre d'une transaction ou d'un processus unique (paiement, formulaire à étapes multiples, réservation), les utilisateurs ne doivent pas être invités à saisir les mêmes informations deux fois, sauf si c'est indispensable — par exemple, pour confirmer un mot de passe. Demander à un utilisateur de retaper son adresse courriel sur une page de confirmation, ou de ressaisir une adresse déjà fournie à l'étape précédente, constitue un échec à ce critère.

Pourquoi WCAG 2.2 est-elle importante pour les entreprises ontariennes si WCAG 2.0 est toujours le plancher légal ?

Trois raisons.

Les tribunaux font référence aux pratiques actuelles, pas aux textes légaux figés. Le RNAI a été rédigé en 2011 et fait référence à WCAG 2.0, mais cela ne signifie pas qu'un tribunal évaluera votre site selon les normes de 2008 indéfiniment. Les tribunaux américains traitant des réclamations d'accessibilité Web fondées sur l'ADA citent couramment WCAG 2.1 ou 2.2 AA comme critère technique lors de l'évaluation de l'accessibilité d'un site au moment de la barrière alléguée (ADA Title III Blog, Seyfarth Shaw, 2025). Toute entreprise ontarienne vendant à des clients américains porte cette exposition. Une plainte au TDPO (Tribunal des droits de la personne de l'Ontario) en vertu du Code des droits de la personne de l'Ontario évalue de même l'accessibilité réelle — ce qu'une personne handicapée pouvait ou ne pouvait pas faire sur votre site — et non si vous avez coché des cases selon une norme vieille de 15 ans.

La nouvelle norme fédérale canadienne pointe déjà vers la version 2.2. La norme CAN/ASC – EN 301 549:2024 intégrée dans le DORS/2025-255 incorpore les exigences WCAG au niveau 2.2 pour le contenu Web. Bien que cette règle fédérale s'applique directement aux employeurs sous réglementation fédérale de 100 employés ou plus, elle indique la direction des attentes réglementaires canadiennes. Les auditeurs travaillant sur le programme d'accessibilité de toute organisation canadienne effectuent déjà des évaluations WCAG 2.2.

Passer un audit RCL 2026 sans connaître vos lacunes WCAG 2.2 est un risque. Le processus de rapport de conformité est toujours lié au libellé WCAG 2.0 du RNAI, mais un auditeur tiers vérifiant votre attestation — ou un plaignant au TDPO dont le témoin expert teste votre site — utilisera les outils actuels. Les scanners automatisés actuels et les cadres de test manuel sont paramétrés par défaut sur WCAG 2.2. Si votre site comporte des en-têtes persistants qui masquent les indicateurs de focus, des carrousels accessibles uniquement par glissement ou des connexions par CAPTCHA sans alternative, ces défaillances apparaîtront dans toute évaluation d'accessibilité moderne, quelle que soit la version des directives citée dans le règlement.

Que doit faire une entreprise ontarienne avant l'échéance de décembre 2026 ?

La liste de vérification pratique, par ordre de priorité :

1. Effectuez un balayage selon la norme actuelle. La plupart des outils gratuits et payants testent désormais selon WCAG 2.1 ou 2.2 — confirmez quelle version votre outil utilise avant de vous fier à ses résultats.
2. Auditez directement les six nouveaux critères AA et A. Naviguez dans votre site au clavier avec la visibilité du focus activée et confirmez qu'aucun élément n'est masqué. Vérifiez chaque élément interactif pour une taille de cible minimale de 24 × 24 px. Parcourez chaque formulaire et flux de paiement pour détecter les saisies redondantes. Testez votre connexion pour les alternatives sans CAPTCHA.
3. Corrigez à la source, pas avec un widget. Une superposition d'accessibilité ne corrige pas les problèmes de focus clavier, les tailles de cible ou les flux d'authentification — elle se superpose à la page et ne peut pas réécrire le comportement des éléments sous-jacents que WCAG 2.2 teste. Les correctifs dans le code réel sont ce qui produit un dossier défendable.
4. Documentez le travail. Un journal de correction daté aligné sur les critères de succès WCAG 2.2 — et pas seulement WCAG 2.0 — est la preuve qui vous protège lors d'une plainte au TDPO ou d'une réclamation ADA. Voici ce qui s'est passé lorsqu'une entreprise disposait de cette preuve et qu'un tribunal l'a examinée.
5. Préparez votre RCL. Votre RCL dû le 31 décembre 2026 doit refléter le travail accompli — pas des aspirations. Un audit selon WCAG 2.2 AA vous donne une base plus complète et plus défendable pour ce rapport qu'un audit arrêté au plancher 2.0.

Voyez où se situe votre site en environ 30 secondes — rapport PassProof gratuit : getpassproof.com. Il détecte les superpositions, révèle les vraies lacunes WCAG et vous indique exactement ce qui s'applique légalement à votre organisation en Ontario. Sans engagement.

PassProof est un studio d'ingénierie en accessibilité à première vocation virtuelle, au service de l'Ontario. Renseignements généraux, non des conseils juridiques.