WCAG 2.1 AA : ce que les petites entreprises doivent vraiment savoir

Traduction assistée par IA. Le contenu original a été rédigé en anglais.

Si tu gères une petite entreprise en Ontario et que quelqu'un mentionne WCAG 2.1 AA, ta première réaction est probablement « c'est quoi ça? » Normal. Ça sonne comme un truc sorti d'un manuel de conformité gouvernemental. Et dans un sens, c'en est un. Mais les exigences concrètes sont plus pratiques que tu penserais, et la plupart sont des choses que ton site devrait déjà faire.

Le problème, c'est que la majorité des sites les font pas. Pas parce que le proprio s'en fout, mais parce que personne lui a expliqué ce que « accessible » veut dire concrètement. Alors réglons ça.

C'est quoi, WCAG, pour vrai.

WCAG, ça veut dire Web Content Accessibility Guidelines. C'est un ensemble de normes publiées par le W3C (l'organisme qui maintient les standards du web) qui définit ce que ça veut dire pour un site d'être accessible aux personnes handicapées. La version 2.1, niveau AA, c'est le standard de référence que la plupart des lois et bonnes pratiques citent.

Ça, c'est la réponse de manuel. Voici la version pratique : WCAG 2.1 AA, c'est une liste de choses que ton site devrait faire pour que les personnes aveugles, sourdes, à mobilité réduite, ou avec des handicaps cognitifs puissent l'utiliser. Ça inclut les gens qui utilisent des lecteurs d'écran, ceux qui peuvent pas utiliser une souris, ceux qui ont besoin de texte plus gros, et les daltoniens.

En Ontario, environ 2,6 millions de personnes ont un handicap. C'est à peu près une sur cinq. Si ton site web peut pas être utilisé par un client potentiel sur cinq, c'est pas un cas marginal. C'est un segment de marché.

Le contexte ontarien : la LAPHO.

L'Ontario a la LAPHO (en anglais, AODA), qui oblige les organisations de 50 employés et plus à rendre leurs sites conformes au WCAG 2.0 niveau AA. Si t'as moins de 50 employés, t'es pas légalement obligé de te conformer. Mais y a trois raisons de t'en soucier quand même.

Premièrement, le seuil pourrait changer. La législation sur l'accessibilité va dans une seule direction : plus stricte. La Loi canadienne sur l'accessibilité s'applique déjà aux entreprises sous réglementation fédérale, peu importe leur taille. L'Ontario pourrait suivre.

Deuxièmement, les plaintes LAPHO exigent pas un nombre minimum d'employés pour être déposées. Si un client handicapé peut pas utiliser ton site et décide d'escalader, la conversation devient inconfortable vite, que tu sois techniquement obligé de te conformer ou non.

Troisièmement, et c'est le plus important : les sites accessibles performent mieux. C'est pas une déclaration de bonne volonté. C'est mesurable.

Les quatre principes (sans le jargon).

WCAG organise tout sous quatre principes appelés POUR. L'acronyme est oubliable. Les concepts, non.

1. Perceptible : les gens peuvent voir ou entendre ton contenu.

Si quelqu'un peut pas voir une image, il a besoin d'une description texte. C'est le texte alternatif. Chaque photo de produit, chaque photo d'équipe, chaque bannière sur ton site devrait avoir une courte description utile. Pas « IMG_4392.jpg ». Pas « image ». Quelque chose comme « Vue de la terrasse du Café Riverside avec des guirlandes lumineuses et des tables extérieures ».

Les vidéos ont besoin de sous-titres. Le contenu audio a besoin de transcriptions. Le texte a besoin d'assez de contraste avec son arrière-plan pour être lisible. Ce dernier point attrape plus de sites qu'on penserait. Du texte gris pâle sur un fond blanc, ça paraît élégant dans une maquette. C'est illisible pour quiconque a plus de 40 ans avec une vision moins que parfaite.

Le standard : un ratio de contraste d'au moins 4,5 pour 1 pour le texte normal. Y a des outils gratuits qui vérifient ça en quelques secondes. Si ton bouton « Réservez maintenant » est du texte pâle sur un fond de couleur moyenne, il échoue peut-être en ce moment.

2. Utilisable : les gens peuvent naviguer et interagir.

Tout le monde utilise pas une souris. Certaines personnes naviguent entièrement au clavier (Tab pour se déplacer entre les éléments, Enter pour activer). Si ton menu déroulant, ton formulaire de contact, ou ton widget de réservation peut pas être utilisé sans souris, c'est brisé pour ces utilisateurs.

Ça veut dire aussi : pas de limites de temps qui peuvent pas être prolongées. Pas de contenu qui clignote plus de trois fois par seconde (risque de crise épileptique). Et chaque élément interactif a besoin d'un indicateur de focus visible pour que les utilisateurs au clavier puissent voir où ils sont sur la page. Si t'as déjà pesé sur Tab sur un site web sans savoir quel élément était sélectionné, ce site a échoué ce critère.

3. Compréhensible : les gens peuvent comprendre quoi faire.

Les champs de formulaire ont besoin d'étiquettes. Pas du texte d'espace réservé qui disparaît quand tu commences à taper. Des vraies étiquettes qui restent visibles. Les messages d'erreur doivent dire ce qui a mal tourné et comment le corriger. « Entrée invalide » aide personne. « Veuillez entrer une adresse courriel valide » aide tout le monde.

La navigation devrait être constante. Si ton menu principal est en haut sur la page d'accueil mais se déplace dans une barre latérale sur la page contact, c'est un problème. La langue de la page devrait être déclarée dans le code pour que les lecteurs d'écran prononcent les mots correctement. C'est pas des changements compliqués. C'est juste facile de les oublier.

4. Robuste : ça marche avec les technologies d'assistance.

Ton site doit fonctionner avec les lecteurs d'écran, les logiciels de contrôle vocal, et les autres outils d'assistance. En pratique, ça veut dire utiliser les bons éléments HTML. Une barre de navigation devrait être un <nav>, pas un <div> stylisé pour en avoir l'air. Un bouton devrait être un <button>, pas un <span> avec un gestionnaire de clic. Les titres devraient utiliser <h1> à <h6> en ordre, pas juste du texte en gras dans une grosse police.

C'est là que les sites à templates bon marché échouent le plus. Le résultat visuel est correct. Le code en dessous, c'est un fouillis de conteneurs génériques que les technologies d'assistance peuvent pas interpréter. Le site a l'air accessible. Il l'est pas.

L'argument d'affaires.

L'accessibilité, c'est pas de la charité. C'est du bon business. Voici pourquoi.

Les moteurs de recherche récompensent ça. Google peut pas voir tes images non plus. Il lit le texte alternatif. Google peut pas cliquer sur ton menu déroulant. Il suit le HTML sémantique. Presque tout ce que tu fais pour rendre un site accessible le rend aussi plus visible pour les moteurs de recherche. Structure de titres appropriée, texte de liens descriptif, temps de chargement rapide, adaptation mobile. Le chevauchement entre les bonnes pratiques SEO et la conformité WCAG tourne autour de 80 %.

Les taux de conversion s'améliorent. Des étiquettes claires, une navigation logique, du texte lisible, et des appels à l'action évidents aident tout le monde, pas juste les utilisateurs handicapés. Un site accessible est, par définition, plus facile à utiliser. Les sites plus faciles à utiliser convertissent mieux. Le W3C Web Accessibility Initiative documente comment les sites accessibles surpassent systématiquement leurs équivalents non accessibles en engagement et en conversion.

Tu rejoins plus de monde. Au-delà des 2,6 millions d'Ontariens handicapés, pense aux limitations situationnelles. Quelqu'un qui tient un bébé et navigue d'une main. Quelqu'un sur un chantier bruyant qui regarde ta vidéo sans son. Quelqu'un avec une blessure temporaire qui utilise le contrôle vocal. L'accessibilité, c'est pas une niche. C'est le spectre complet de comment les gens utilisent le web pour vrai.

Ça te protège légalement. Les poursuites liées à l'accessibilité web en Amérique du Nord augmentent chaque année depuis 2018. La plupart visent des grandes entreprises, mais le paysage juridique bouge. Avoir un site accessible, c'est pas juste de la bonne pratique. C'est de la gestion de risque.

Par où commencer.

T'as pas besoin de tout corriger d'un coup. Commence par les éléments qui ont le plus d'impact pour le moins d'effort.

Y a des outils gratuits qui attrapent les problèmes évidents. WAVE de WebAIM fait un scan sur n'importe quelle page et souligne les problèmes en langage clair. Google Lighthouse (intégré dans Chrome DevTools) inclut un score d'accessibilité. Aucun attrape tout, mais les deux attrapent les gains faciles.

Ça ressemble à quoi, « conforme ».

Un site conforme à WCAG 2.1 AA est pas visuellement différent d'un site non conforme. Tu le verras pas dans le design. Tu le verras dans les détails : chaque image a une description, chaque bouton marche au clavier, chaque champ de formulaire a une étiquette, le texte est lisible, le code est propre, et le tout fonctionne avec un lecteur d'écran.

C'est pas une question d'ajouter un widget ou un overlay. Ces produits d'overlay d'accessibilité qui promettent la conformité avec une ligne de code, ça marche pas. Ils ont été la cible de plus de poursuites que les sites qu'ils prétendent corriger. L'accessibilité réelle, c'est intégré dans le site dès le départ. C'est dans le code, pas boulonné par-dessus.

La version courte.

WCAG 2.1 AA, c'est un ensemble de règles qui rendent ton site utilisable par tout le monde. Les entreprises ontariennes de 50 employés et plus sont légalement tenues de s'y conformer. Les plus petites le sont pas, mais elles en profitent pareil : meilleur SEO, meilleure utilisabilité, plus de clients, et une protection juridique.

La plupart des correctifs sont simples. Texte alternatif, contraste des couleurs, étiquettes de formulaire, navigation au clavier, code propre. T'as pas besoin d'un spécialiste pour tout. T'as juste besoin de quelqu'un qui sait quoi chercher.

Si tu veux savoir où ton site en est, écris-moi. Je vais jeter un coup d'oeil et te dire ce qui marche, ce qui marche pas, et quoi corriger en premier.