Ce que signifie concrètement WCAG 2.1 AA
WCAG 2.1 AA est un ensemble d’exigences d’accessibilité pour les sites web, les applications et les documents numériques. WCAG signifie Web Content Accessibility Guidelines. Ces règles sont conçues pour rendre les services numériques utilisables par les personnes en situation de handicap, y compris les personnes aveugles ou malvoyantes, sourdes ou malentendantes, ayant une mobilité réduite, des troubles cognitifs, des difficultés d’apprentissage, ou des limitations temporaires comme un bras cassé ou une fatigue visuelle.
Pour les lecteurs non techniques, la manière la plus simple de comprendre WCAG 2.1 AA est la suivante : il s’agit d’une norme reconnue visant à rendre le contenu numérique accessible à un plus grand nombre de personnes. Elle couvre des aspects tels que la lisibilité du texte, la possibilité d’utiliser un site au clavier, la compréhension de la structure d’une page par les lecteurs d’écran, ainsi que la clarté et l’ergonomie des formulaires.
Le 2.1 renvoie à la version de la norme. Le AA renvoie au niveau de conformité. WCAG comporte trois niveaux : A, AA et AAA. Le niveau A correspond au minimum de base. Le niveau AA est celui que la plupart des organisations visent et celui qui est le plus souvent exigé par la loi ou par des politiques internes. Le niveau AAA est plus exigeant et n’est généralement pas requis pour l’ensemble d’un site web.
Lorsque l’on dit qu’un site est « conforme WCAG 2.1 AA », cela signifie généralement que le site a été conçu et testé de manière à satisfaire les critères de réussite des niveaux A et AA de WCAG 2.1. En réalité, l’accessibilité n’est pas un simple label obtenu une fois pour toutes. C’est un processus continu de conception, de gestion de contenu, de tests et d’amélioration.
Pourquoi WCAG est important
L’accessibilité est souvent abordée comme une obligation légale, mais elle relève tout autant de l’ergonomie de base et du service public. Si une personne ne peut pas remplir un formulaire, lire un document de politique publique, prendre rendez-vous ou comprendre une information importante en raison d’obstacles évitables, le service ne fonctionne pas correctement.
WCAG aide les organisations à identifier et à réduire ces obstacles. Il fournit un cadre commun que les designers, développeurs, équipes éditoriales, équipes achats et décideurs peuvent utiliser. Cela est particulièrement important dans le secteur public, où les services numériques doivent fonctionner pour le public le plus large possible.
Les améliorations en matière d’accessibilité profitent souvent à tout le monde, et pas seulement aux utilisateurs en situation de handicap. Des titres clairs facilitent le survol des pages. Un bon contraste des couleurs aide sur les écrans mobiles en plein soleil. Les sous-titres aident dans les environnements bruyants. Les formulaires utilisables au clavier facilitent le travail des utilisateurs avancés. Le langage պարզ et clair aide chacun à savoir quoi faire ensuite.
Les quatre principes qui sous-tendent WCAG
WCAG repose sur quatre principes fondamentaux. Le contenu doit être perceptible, utilisable, compréhensible et robuste. On les résume souvent par l’acronyme POUR.
Perceptible
Les utilisateurs doivent pouvoir percevoir les informations présentées. Cela signifie que le contenu ne doit pas reposer sur un seul sens, comme la vue ou l’audition. Par exemple, il faut fournir des alternatives textuelles pour les images, des sous-titres pour les vidéos et un contraste suffisant entre le texte et l’arrière-plan.
Utilisable
Les utilisateurs doivent pouvoir utiliser l’interface. Un site ne doit pas exiger des mouvements de souris précis ni des gestes que certaines personnes ne peuvent pas réaliser. De nombreux utilisateurs s’appuient sur un clavier, un dispositif de commutation ou la commande vocale. La navigation et les formulaires doivent donc fonctionner sans souris.
Compréhensible
Les utilisateurs doivent pouvoir comprendre à la fois l’information et le fonctionnement de l’interface. Les pages doivent être prévisibles, les instructions claires et les formulaires doivent expliquer les erreurs de manière utile. Un langage trop complexe peut, à lui seul, constituer un problème d’accessibilité.
Robuste
Le contenu doit fonctionner de manière fiable avec différents navigateurs, appareils et technologies d’assistance, comme les lecteurs d’écran. Cela dépend de l’utilisation d’une structure et d’un code appropriés, afin que la technologie puisse interpréter correctement le contenu.
Ce que couvre généralement WCAG 2.1 AA
Bien que la norme soit détaillée, nombre de ses exigences peuvent être comprises en termes simples. Au niveau WCAG 2.1 AA, les organisations sont généralement tenues de traiter des points tels que :
- Alternatives textuelles : les images porteuses de sens doivent comporter un texte alternatif afin que les utilisateurs de lecteurs d’écran puissent en comprendre la fonction.
- Sous-titres et transcriptions : les vidéos préenregistrées doivent inclure des sous-titres, et le contenu audio doit, le cas échéant, être accompagné de transcriptions.
- Contraste des couleurs : le texte et les éléments clés de l’interface doivent se détacher clairement de l’arrière-plan.
- Accès au clavier : les utilisateurs doivent pouvoir naviguer dans les menus, liens, boutons et formulaires à l’aide du seul clavier.
- Focus visible : un indicateur visuel clair doit montrer quel élément est actuellement sélectionné lors de la navigation au clavier.
- Titres et structure clairs : les pages doivent utiliser correctement les titres, listes et libellés afin que le contenu soit facile à suivre.
- Accessibilité des formulaires : les champs doivent avoir des libellés, les instructions doivent être claires et les erreurs doivent être expliquées de manière compréhensible et corrigible.
- Texte redimensionnable et mise en page responsive : le contenu doit rester utilisable lorsque les utilisateurs zooment ou consultent le site sur des écrans plus petits.
- Fonction des liens : les liens doivent avoir un sens, surtout hors contexte. « En savoir plus » seul est souvent insuffisant.
- Navigation cohérente : les éléments répétés doivent fonctionner de manière prévisible sur l’ensemble du site.
- Compatibilité avec les lecteurs d’écran : le code et la structure sous-jacents doivent permettre aux technologies d’assistance d’interpréter correctement le contenu.
- Absence d’obstacles inutiles : le contenu ne doit pas clignoter d’une manière susceptible de déclencher des crises, et les interactions ne doivent pas dépendre uniquement de gestes complexes.
WCAG 2.1 a ajouté des exigences supplémentaires particulièrement pertinentes pour l’usage mobile et pour les utilisateurs ayant une basse vision ou des troubles cognitifs. Elles concernent notamment l’orientation, le réagencement du contenu, les méthodes de saisie et l’identification de l’objet de la saisie.
Qui doit se conformer à WCAG 2.1 AA
La réponse dépend du pays, du secteur et du cadre juridique, mais, de manière générale, les organismes du secteur public sont très souvent tenus de respecter WCAG 2.1 AA pour les sites web et les applications mobiles. Dans l’ensemble de l’UE, les organismes publics sont soumis à des exigences d’accessibilité au titre de la directive sur l’accessibilité du web, ce qui a conduit de nombreuses organisations à adopter WCAG 2.1 AA comme référence pratique.
Cela inclut généralement l’administration centrale, les collectivités locales, le NHS et les organismes de santé, les universités, les écoles, les autorités de régulation et d’autres institutions publiques, même si le périmètre exact et les exceptions varient selon les pays.
Les organisations du secteur privé peuvent également devoir s’y conformer, notamment lorsqu’elles fournissent des services essentiels aux consommateurs ou opèrent dans des secteurs réglementés. Même en l’absence d’obligation légale directe, WCAG 2.1 AA est largement utilisé dans les marchés publics, les contrats, les politiques internes et la gestion des risques.
Il est également courant que les organisations exigent de leurs fournisseurs qu’ils respectent WCAG 2.1 AA lors de l’achat de sites web, d’intranets, de portails, de systèmes de réservation ou de plateformes documentaires. En pratique, cela signifie que l’accessibilité n’est pas seulement un enjeu juridique pour l’organisation qui publie le contenu, mais aussi pour les agences et les éditeurs de logiciels qui l’accompagnent.
Le lien avec l’Acte européen sur l’accessibilité
L’Acte européen sur l’accessibilité, ou EAA, est distinct de la directive sur l’accessibilité du web, mais les deux poursuivent des objectifs proches. Tous deux visent à améliorer l’accessibilité, mais ils s’appliquent à des domaines différents.
La directive sur l’accessibilité du web concerne principalement les sites web et les applications mobiles des organismes du secteur public. L’EAA étend les exigences d’accessibilité à certains pans du secteur privé en couvrant certains produits et services mis sur le marché de l’UE, tels que les services de commerce électronique, les services bancaires, les livres électroniques, les bornes de billetterie, les terminaux bancaires destinés aux consommateurs et certains services numériques liés aux transports.
Pour les lecteurs non techniques, l’idée essentielle est la suivante : l’EAA renforce la pression exercée sur les organisations pour qu’elles prennent l’accessibilité numérique au sérieux. Même si une équipe ne connaît que les règles applicables au secteur public, l’évolution européenne plus large est claire. L’accessibilité devient une attente standard pour un nombre croissant de services numériques, et non plus une exigence de niche.
WCAG est souvent utilisé comme point de référence pratique pour le contenu web et les interfaces numériques lorsqu’il s’agit de démontrer l’accessibilité, même si les textes juridiques peuvent renvoyer à des normes plus larges ou à des normes européennes harmonisées. Autrement dit, si une organisation se prépare à des obligations liées à l’EAA, comprendre WCAG 2.1 AA constitue un point de départ pertinent.
La conformité signifie-t-elle que chaque page est parfaite ?
Pas nécessairement. Les grandes organisations disposent souvent de systèmes hérités, d’anciens PDF, d’outils tiers et de contenus archivés qui posent des difficultés. La conformité est généralement évaluée au regard des exigences réellement applicables, et de nombreux organismes publics publient une déclaration d’accessibilité expliquant ce qui est conforme, ce qui ne l’est pas et ce qu’ils font pour améliorer la situation.
Cela dit, les déclarations d’accessibilité ne remplacent pas l’action. Elles sont destinées à assurer la transparence, et non à masquer des problèmes évitables. Un programme d’accessibilité réaliste comprend la gouvernance, les tests, la priorisation et des revues régulières.
Comment tester WCAG 2.1 AA
Tester correctement l’accessibilité ne se limite pas à exécuter un outil automatique. Les outils automatisés sont utiles, mais ils ne peuvent identifier qu’une partie des problèmes. De nombreux problèmes importants d’accessibilité nécessitent une vérification humaine.
1. Commencez par des vérifications automatisées
Les outils automatisés peuvent signaler rapidement des problèmes courants tels que l’absence de texte alternatif, un contraste insuffisant, des boutons vides, des libellés de formulaire manquants ou des problèmes de structure des titres. Ils sont utiles pour repérer des erreurs évidentes à grande échelle, en particulier pendant le développement et la publication de contenu.
En revanche, les outils automatisés ne peuvent pas déterminer de manière fiable si un texte alternatif est pertinent, si les instructions sont claires, si l’ordre de tabulation a du sens ou si un utilisateur peut accomplir une tâche sans confusion.
2. Testez au clavier
Un test simple mais très efficace consiste à mettre la souris de côté et à essayer d’utiliser le site uniquement au clavier. Pouvez-vous parcourir les menus, liens, boutons et formulaires ? Pouvez-vous voir où se trouve le focus ? Pouvez-vous ouvrir et fermer les éléments interactifs ? Pouvez-vous envoyer un formulaire et corriger une erreur ?
Si l’utilisation au clavier est difficile, le site présente probablement des obstacles importants pour de nombreux utilisateurs.
3. Examinez manuellement le contenu et la conception
La vérification manuelle doit porter sur les titres, le texte des liens, les instructions, les messages d’erreur, les titres de page, l’utilisation des couleurs, la structure des documents et la clarté générale. Une page peut passer une analyse automatisée tout en restant difficile à comprendre ou impossible à utiliser en pratique.
4. Testez avec des technologies d’assistance
Dans la mesure du possible, testez avec des lecteurs d’écran et d’autres technologies d’assistance. Cela permet de vérifier si la structure de la page est annoncée correctement, si les contrôles portent les bons noms et si les mises à jour de contenu dynamique sont bien communiquées.
Cela ne signifie pas que chaque équipe projet doit devenir experte de toutes les technologies d’assistance, mais des tests pratiques sont importants, surtout sur les parcours utilisateurs essentiels.
5. Associez des personnes en situation de handicap aux tests
Les enseignements les plus utiles proviennent souvent de tests réalisés avec des personnes qui utilisent réellement des technologies d’assistance ou rencontrent des obstacles d’accessibilité au quotidien. Les tests utilisateurs peuvent montrer qu’un service satisfait techniquement certains critères tout en générant des frictions, de la confusion ou une exclusion.
6. Testez aussi les documents et les systèmes intégrés
Les tests d’accessibilité ne doivent pas s’arrêter au site principal. Les PDF, documents Word, formulaires en ligne, cartes, systèmes de réservation, outils de paiement et widgets tiers peuvent tous créer des obstacles. S’ils font partie du parcours utilisateur, ils doivent être pris en compte.
Idées reçues courantes sur WCAG
- « L’accessibilité ne concerne que les personnes aveugles. » En réalité, l’accessibilité couvre un large éventail de besoins, notamment en matière d’audition, de mobilité, ainsi que les différences cognitives et neurologiques.
- « Un overlay ou un widget résout l’accessibilité. » Ce n’est pas le cas. L’accessibilité doit être intégrée à la conception, au code et au contenu.
- « Si un outil automatisé indique que tout est conforme, nous sommes conformes. » Les tests automatisés sont utiles, mais ils ne constituent qu’une partie du processus.
- « L’accessibilité rend les sites web ternes. » Une bonne accessibilité favorise une conception claire et utilisable. Elle n’empêche pas une identité visuelle forte.
- « Cela ne concerne que les grandes organisations. » Les petites organisations servent elles aussi des usagers en situation de handicap et peuvent malgré tout être exposées à des risques juridiques, contractuels ou réputationnels.
Ce que les organisations devraient faire ensuite
Pour les équipes peu techniques, l’approche la plus pratique consiste à considérer WCAG 2.1 AA comme une norme opérationnelle plutôt que comme un sujet spécialisé. Cela signifie l’intégrer aux achats, aux cahiers des charges de conception, aux flux de production éditoriale, à l’assurance qualité et à la gouvernance.
Un point de départ raisonnable serait de :
- auditer les sites web, applications et documents existants
- identifier les parcours utilisateurs prioritaires, tels que les formulaires, paiements, réservations et démarches de contact
- corriger d’abord les obstacles les plus graves
- former les rédacteurs et les équipes projet
- fixer des exigences d’accessibilité pour les fournisseurs
- mettre en place des tests réguliers plutôt que des contrôles ponctuels
- maintenir une déclaration d’accessibilité exacte lorsque celle-ci est requise
L’accessibilité est plus simple et moins coûteuse lorsqu’elle est prise en compte dès le départ. La mise en conformité a posteriori est généralement plus lente, plus coûteuse et moins efficace.
En résumé
WCAG 2.1 AA est la norme largement reconnue utilisée pour rendre les sites web et les services numériques plus accessibles. Pour les lecteurs non techniques, il est préférable de la comprendre comme une liste de contrôle pratique et un cadre permettant de supprimer les obstacles qui empêchent les personnes d’utiliser le contenu numérique.
Elle est importante parce que les services numériques doivent fonctionner pour tout le monde, y compris pour les personnes en situation de handicap. Les organismes du secteur public sont souvent tenus de la respecter, et l’évolution du cadre juridique européen, notamment avec l’Acte européen sur l’accessibilité, montre que les attentes en matière d’accessibilité s’étendent au-delà du secteur public.
La conformité ne consiste pas seulement à réussir une analyse ou à publier une déclaration. Elle exige des tests appropriés, une responsabilité clairement définie, des pratiques de contenu accessibles et une amélioration continue. Les organisations qui comprennent cela sont beaucoup mieux placées pour proposer des services numériques légaux, utilisables et équitables.