Accessibilité Web et conformité aux WCAG : guide pratique pour les entreprises de Toronto

L’accessibilité Web signifie que les personnes handicapées — visiteurs aveugles ou ayant une basse vision, visiteurs sourds ou malentendants, personnes qui ne peuvent pas utiliser une souris, personnes ayant une incapacité cognitive ou un trouble d’apprentissage — peuvent utiliser votre site aussi pleinement que quiconque. En Ontario, c’est aussi une obligation légale pour de nombreuses organisations en vertu de la Loi sur l’accessibilité pour les personnes handicapées de l’Ontario (LAPHO). Ce guide explique qui doit respecter quelle norme, ce qui distingue les versions des WCAG, et propose un parcours pratique en six étapes vers une conformité aux WCAG qui tient la route après le lancement.

La question touche plus de gens que la plupart des entreprises ne le pensent. Selon l’Enquête canadienne sur l’incapacité de 2022 de Statistique Canada, 27 % des Canadiens de 15 ans et plus — environ 8 millions de personnes — ont au moins une incapacité. Ajoutez les visiteurs âgés, les personnes ayant une blessure temporaire et quiconque consulte son téléphone en plein soleil, et l’accessibilité cesse d’être un cas marginal : c’est tout simplement ainsi que fonctionne un bon site Web.

Qui doit respecter les règles d’accessibilité Web en Ontario

La Loi sur l’accessibilité pour les personnes handicapées de l’Ontario (LAPHO) établit ses règles pour le Web dans le Règlement sur les normes d’accessibilité intégrées. Ce qui s’applique à vous dépend de votre type d’organisation :

• Les organisations du secteur public et les organisations comptant 50 employés ou plus en Ontario doivent rendre leurs sites Web publics et leur contenu Web conformes aux WCAG 2.0 de niveau AA, à l’exception du sous-titrage en direct et de l’audiodescription préenregistrée. L’échéance pour la conformité complète était le 1er janvier 2021.
• Les organisations comptant 20 employés ou plus doivent aussi déposer un rapport de conformité en matière d’accessibilité auprès de la province tous les trois ans.
• Les plus petites organisations ne sont pas assujetties à la section sur les sites Web — mais le Code des droits de la personne de l’Ontario exige tout de même que les services soient accessibles, et de nombreux acheteurs du secteur public et d’entreprises demandent maintenant à leurs fournisseurs des preuves d’accessibilité avant de signer.
• Les organisations sous réglementation fédérale — banques, entreprises de télécommunications, transporteurs aériens et autres — relèvent de la Loi canadienne sur l’accessibilité, qui exige des plans sur l’accessibilité, un processus de rétroaction et des rapports d’étape.

L’application de la loi relève de la Direction générale de l’accessibilité pour l’Ontario. Sur déclaration de culpabilité, une personne morale peut se voir imposer une amende allant jusqu’à 100 000 $ pour chaque jour où l’infraction se poursuit. Le plus souvent, toutefois, les problèmes apparaissent d’abord sous la forme d’une plainte d’un client qui n’a pas pu réserver, acheter ou postuler — c’est pourquoi il vaut mieux traiter l’accessibilité comme une composante de la qualité plutôt que comme une considération juridique de dernière minute.

La conformité aux WCAG expliquée : versions et niveaux

Les Règles pour l’accessibilité des contenus Web (WCAG) sont la norme internationale publiée par le W3C. Elles contiennent des critères de succès vérifiables regroupés sous quatre principes — le contenu doit être perceptible, utilisable, compréhensible et robuste — et chaque critère a un niveau :

• Niveau A — l’essentiel. Sans ces critères, certaines personnes ne peuvent pas utiliser la page du tout (aucun accès au clavier, images sans équivalent textuel).
• Niveau AA — la norme à laquelle renvoient presque toutes les lois et politiques, y compris la LAPHO. Il ajoute le contraste, le redimensionnement, une navigation cohérente, un focus clair, l’aide en cas d’erreur et plus encore.
• Niveau AAA — le niveau le plus élevé. Il n’est pas attendu pour des sites entiers, car certains critères ne peuvent pas être respectés pour tous les contenus; les équipes adoptent des critères AAA individuels là où ils sont utiles.

Trois versions sont en usage. Les WCAG 2.0 (2008) sont celles que désigne la LAPHO. Les WCAG 2.1 (2018) ont ajouté des critères pour l’utilisation mobile, la basse vision et les incapacités cognitives — redistribution du contenu sur les petites largeurs, orientation, espacement du texte, contraste des icônes et des commandes. Les WCAG 2.2 (2023) en ont ajouté neuf autres, dont des tailles de cible minimales et des solutions de rechange au glisser-déposer, et ont retiré un critère désuet. Chaque version contient la précédente : un site qui respecte les WCAG 2.2 de niveau AA respecte donc aussi les WCAG 2.1 AA et 2.0 AA. C’est la cible que nous recommandons : elle couvre le seuil légal et reflète la façon dont les gens utilisent réellement le Web aujourd’hui. Notre guide des WCAG 2.2 explique chacun des nouveaux critères.

Deux détails prennent souvent les équipes au dépourvu. La conformité aux WCAG s’applique à des pages complètes — un seul composant inaccessible signifie que la page n’est pas conforme — et à des processus complets : si une étape du passage à la caisse échoue, c’est tout le passage à la caisse qui échoue.

Six étapes vers la conformité aux WCAG

L’accessibilité Web ne se règle pas une fois pour toutes. Les organisations qui demeurent conformes la traitent comme un processus qui a un début — un audit — et pas vraiment de fin :

1. Auditer le site Web

Commencez par mesurer où se situe le site par rapport aux WCAG 2.2 de niveau AA, avec une analyse automatisée et des tests manuels — clavier, lecteurs d’écran, zoom, contenu. Les outils automatisés à eux seuls ratent la plupart de ce qui compte. Notre guide de l’audit d’accessibilité numérique décrit le processus et ce que le rapport devrait contenir.

2. Corriger les obstacles critiques dans les parcours clés

Établissez vos priorités selon l’impact, et non selon le nombre. Un piège au clavier dans le passage à la caisse ou un champ sans étiquette dans le formulaire de contact bloque complètement les gens; corrigez-les en premier, dans les parcours les plus importants pour votre entreprise : vous joindre, acheter, réserver, postuler, se connecter.

3. Corriger les gabarits et le système de design

La plupart des sites Web sont construits à partir de quelques gabarits et d’un ensemble commun de composants — boutons, menus, formulaires, cartes, boîtes de dialogue. Corriger un problème dans le composant le corrige sur chaque page qui l’utilise. C’est aussi là que se gagne l’accessibilité Web à long terme : des jetons de couleur accessibles, des styles de focus visibles, des modèles de formulaires appropriés et un HTML sémantique intégrés une fois, puis réutilisés partout.

4. Corriger le contenu et les documents

C’est généralement dans le contenu que l’accessibilité se dégrade. Rédigez des textes de remplacement pertinents, des intitulés de liens descriptifs et des titres clairs; sous-titrez les vidéos; et remplacez les PDF numérisés ou non balisés par des versions accessibles ou des pages HTML. Donnez aux personnes qui publient du contenu une courte liste de vérification — elle prévient la plupart des nouveaux problèmes.

5. Publier une déclaration d’accessibilité et un processus de rétroaction

Une déclaration d’accessibilité indique quelle norme vous visez, ce qui, à votre connaissance, n’est pas encore accessible et quand ce sera corrigé, et comment les gens peuvent vous joindre s’ils se heurtent à un obstacle. En vertu de la LAPHO, les organisations doivent aussi disposer d’un processus de rétroaction accessible et fournir sur demande l’information dans des formats accessibles; la déclaration est donc l’endroit tout désigné pour expliquer les deux.

6. Faire un suivi à chaque mise en production

Ajoutez des vérifications d’accessibilité automatisées au développement, incluez des tests au clavier et avec lecteur d’écran dans l’assurance qualité des nouvelles fonctionnalités, et refaites un audit après toute refonte majeure. Un examen annuel empêche la conformité aux WCAG de s’éroder sans bruit au fil des changements de contenu et de fonctionnalités.

Que mettre dans une déclaration d’accessibilité

Une bonne déclaration d’accessibilité est courte, honnête et précise. Elle devrait couvrir :

• Votre engagement et la norme visée — par exemple, « nous visons à respecter les WCAG 2.2 de niveau AA ».
• L’état actuel — si le site est entièrement ou partiellement conforme, et la date du dernier test.
• Les limites connues — ce qui n’est pas encore accessible (une ancienne bibliothèque de PDF, un module de réservation tiers), avec des solutions de contournement et une date cible pour les corrections.
• Comment obtenir de l’aide — un numéro de téléphone, une adresse courriel et un formulaire de contact, ainsi que votre délai de réponse.
• Les formats accessibles — comment demander l’information dans un autre format, comme en gros caractères ou sous forme de document accessible.
• La rétroaction — comment les commentaires sont traités, et qui en est responsable.

Mettez un lien vers la déclaration dans le pied de page de chaque page, tenez-la à jour après chaque audit et assurez-vous que les moyens de contact qu’elle indique sont surveillés.

Les manquements les plus fréquents à la conformité aux WCAG

Dans les audits de sites Web d’entreprises, les mêmes problèmes reviennent sans cesse. Chacun contrevient à un critère de succès précis des WCAG :

• Texte à faible contraste — texte gris pâle, texte superposé à des photos, texte indicatif utilisé comme étiquette (1.4.3 Contraste).
• Images sans texte de remplacement utile, et boutons-icônes sans nom accessible (1.1.1 Contenu non textuel, 4.1.2 Nom, rôle et valeur).
• Champs de formulaire sans étiquette, et erreurs signalées uniquement en rouge (1.3.1, 3.3.1, 3.3.2, 1.4.1).
• Menus, fenêtres contextuelles et carrousels qui ne fonctionnent pas au clavier ou qui piègent le focus (2.1.1, 2.1.2).
• Styles de focus absents ou invisibles (2.4.7 Visibilité du focus).
• Titres choisis pour leur taille plutôt que selon la structure de la page (1.3.1 Information et relations).
• Vidéos sans sous-titres et PDF sans balises (1.2.2 Sous-titres, 1.3.1).
• Mises en page qui se brisent à un zoom de 200 % ou sur les petits écrans (1.4.4 Redimensionnement du texte, 1.4.10 Redistribution).

La plupart de ces problèmes proviennent d’une poignée de composants communs; c’est pourquoi corriger les gabarits et le système de design (étape 3) règle autant de problèmes à la fois.

Concevoir pour l’accessibilité Web dès le départ

Ajouter l’accessibilité après coup coûte toujours plus cher que de l’intégrer dès le départ. Lorsque nous concevons et construisons un site, l’accessibilité fait partie du mandat dès les premières esquisses :

• Les couleurs et la typographie sont choisies en mesurant le contraste, pas au jugé — 4,5:1 pour le texte courant, 3:1 pour le texte de grande taille et les commandes — dans les thèmes clair et sombre.
• Chaque interaction fonctionne au clavier, avec un style de focus que les gens peuvent réellement voir.
• Les mises en page se redistribuent sur une seule colonne aux petites largeurs et restent utilisables avec un texte agrandi à 200 %.
• Les animations respectent le réglage « réduire les animations », et rien ne clignote.
• Les formulaires ont des étiquettes visibles, des instructions claires et des messages d’erreur qui expliquent comment corriger.
• Le HTML sémantique d’abord, avec ARIA uniquement là où les éléments natifs ne suffisent pas.

Ainsi, l’accessibilité ne coûte presque rien de plus — et les mêmes qualités rendent un site plus rapide, plus facile à utiliser sur un téléphone et plus facile à comprendre pour les moteurs de recherche.

Tester l’accessibilité de votre site Web : ce que vous pouvez vérifier vous-même

Vous pouvez repérer les problèmes les plus évidents en quelques minutes :

1. Parcourez votre page d’accueil et votre formulaire de contact uniquement au clavier. Voyez-vous où vous êtes, et pouvez-vous tout atteindre?
2. Envoyez un formulaire contenant des erreurs. Les erreurs sont-elles expliquées en mots, à côté du bon champ?
3. Faites un zoom à 200 %. Des éléments se chevauchent-ils, disparaissent-ils ou exigent-ils un défilement horizontal?
4. Passez WAVE ou Lighthouse sur vos pages clés et examinez d’abord le contraste et les étiquettes manquantes.
5. Activez VoiceOver ou NVDA et essayez de trouver votre numéro de téléphone ou de prendre un rendez-vous.

Si ces vérifications révèlent des problèmes, un audit complet en trouvera d’autres et vous indiquera quoi corriger en premier.

Questions fréquentes

Qu’est-ce que la conformité aux WCAG?

La conformité aux WCAG signifie que chaque page et chaque processus complet d’un site Web respectent tous les critères de succès d’une version et d’un niveau donnés des WCAG, le plus souvent les WCAG 2.1 ou 2.2 de niveau AA. La LAPHO exige les WCAG 2.0 de niveau AA pour les organisations qu’elle vise.

L’accessibilité Web est-elle exigée par la loi au Canada?

Cela dépend de l’organisation. En Ontario, la LAPHO exige que les organisations du secteur public et les organisations comptant 50 employés ou plus respectent les WCAG 2.0 de niveau AA. Les organisations sous réglementation fédérale relèvent de la Loi canadienne sur l’accessibilité. Les lois sur les droits de la personne exigent plus largement des services accessibles, quelle que soit la taille de l’entreprise.

Une extension ou une surcouche d’accessibilité rend-elle un site conforme?

Non. Les surcouches modifient l’apparence d’une page après son chargement, mais elles ne corrigent pas le code, le contenu ni les documents sous-jacents, et elles peuvent nuire aux technologies d’assistance que les gens utilisent déjà. La conformité aux WCAG passe par la correction du site lui-même.

Combien de temps faut-il pour rendre un site Web accessible?

L’audit d’un site de petite ou moyenne taille prend d’une à deux semaines. Les corrections dépendent de ce qu’il révèle : les problèmes dans les gabarits communs peuvent souvent être réglés en quelques jours, alors que les sites riches en contenu et comptant de nombreux documents demandent plus de temps. Pour un nouveau site construit de façon accessible dès le départ, le temps ajouté est minime.

Ressources connexes

• Audit d’accessibilité numérique : le processus en 8 étapes
• Guide de conformité aux WCAG 2.2
• Expérience utilisateur (UX)
• Conception Web à Toronto

Besoin d’aide en matière d’accessibilité Web? PerfectPixels conçoit et construit des sites Web accessibles et audite les sites existants selon les WCAG 2.2 de niveau AA. Contactez-nous pour parler de votre site.

Pour aller plus loin : How to make websites accessible — gouvernement de l’Ontario.