Accessibilité web : WCAG demystifié

Quand on veut mettre en œuvre une démarche d’accessibilité web, il y a pas mal de choses à faire et à savoir. On peut être tenté de partir bille en tête sur des questions d’outillage et de processus, mais on va souvent retrouver des mentions à un document qui revient encore et encore, une norme qui semble représenter l’alpha et l’oméga de la question : WCAG (Web Content Accessibility Guidelines – Principes d’Accessibilité des Contenus Web).
Cette norme est tellement centrale qu’il vaut la peine de se pencher un peu dessus, histoire de s’armer correctement avant de passer à la mise en œuvre. Aujourd’hui on va donc voir ce qu’est concrètement WCAG : qu’est-ce qu’il y a dedans ? Quels en sont les avantages ? Et finalement, quelles en sont les limites ?

Pour qui, pour quoi ?

Créée dans le cadre de la Web Accessibility Initiative (Initiative pour l’Accessibilité Web) du W3C, WCAG est clairement une des normes d’accessibilité web les plus fondamentales. D’une part, elle s’applique à tout contenu créé avec les technologies web (HTML, CSS, JavaScript, SVG, etc.) que ce soit pour un site web, une application en une page (SPA: Single Page Application) ou une application native web (créée avec Electron par exemple). D’autre part, elle est le fondement d’à peu près toutes les réglementations officielles, de la section 508 américaine au RGAA (Référentiel Général d’Accessibilité des Administrations) français.
Contrairement à beaucoup de normes du W3C, WCAG n’est pas une norme technique. Elle est une norme fonctionnelle qui fournit un ensemble de principes (guidelines) pour rendre les contenus web plus accessibles sans pour autant être une solution ultime. Le préambule de la norme est totalement transparent à cet égard:

Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general.
(Web Content Accessibility Guidelines (WCAG) 2.1 couvre un large spectre de recommandations pour rendre les contenus web plus accessibles. Suivre ces principes rendra les contenus plus accessibles à un ensemble plus important de personnes en situation de handicap, ce qui inclut des aménagements pour la cécité ou la déficience visuelle, la surdité et la perte d’audition, les contraintes motrices, les difficultés d’élocution, la photosensibilité et la combinaison de tous ces états ; elle inclut également des dispositions pour les problèmes d’apprentissage ou de cognition. Cependant, elle ne répond pas à l’exhaustivité des besoins des personnes en situation de handicap. Ces principes couvrent l’accessibilité des contenus web sur les ordinateurs de bureau, les ordinateurs portables, les tablettes et les appareils mobiles. Suivre ces principes rendra généralement les contenus web plus faciles à utiliser pour tous les utilisateurs.)

Un des grands enjeux de l’accessibilité c’est la capacité à pouvoir anticiper les situations de handicap pour en réduire l’impact. Le truc c’est que quand on n’est pas soi-même confronté à ces questions, il est difficile d’anticiper ces situations. C’est en partie pour résoudre ce problème que WCAG existe. Les principes qui y sont répertoriés sont là pour répondre à nombre de situations qu’on aurait du mal à imaginer. Cependant, comme toute norme fonctionnelle, sa mise en œuvre est affaire de contexte et d’appréciation. Et justement WCAG est bien conçue pour nous aider à évaluer la pertinence des principes à suivre pour nos projets.

Un temple pour l’accessibilité

WCAG repose sur trois grands piliers :

1. Les principes à suivre (souvent la partie émergée de l’iceberg dont on a plus ou moins entendu parler) ;
2. Les critères de succès des principes et le niveau de conformité associé ;
3. Les conseils de mise en œuvre.

Voyons de quoi il s’agit exactement.

Les principes : la nourriture de l’âme

Les fondements de WCAG sont ses principes de mise en œuvre qui vont être regroupés au sein de quatre grandes lignes directrices. Comme on le disait, il est difficile d’imaginer toutes les situations de handicap possibles. Pour cette raison, WCAG adopte un modèle générique pour ses principes plutôt que d’essayer de répondre à des questions spécifiques. Voici une version vulgarisée de ces lignes directrices et de leurs principes :

1. La perception
   Tout contenu web doit être perceptible (Perceivable). En clair, quelles que soient les conditions, un utilisateur doit pouvoir percevoir le contenu – le voir, l’entendre ou le toucher. Prenez le temps d’y réfléchir, c’est beaucoup moins évident que ça en a l’air… Indice : tout le monde n’a pas les mêmes capacités de perception.Les principes associés étant :
   • Principe 1.1 : Tout contenu non textuel doit avoir une alternative textuelle.
   • Principe 1.2 : Tout média temporel (audio, vidéo, animation, etc.) doit avoir une alternative (en général textuelle, mais il y a d’autres cas).
   • Principe 1.3 : Tout contenu doit pouvoir être représenté de différentes manières (mise en page alternative par exemple) sans perte d’informations.
   • Principe 1.4 : Tout type de contenu doit être facile à distinguer d’un autre (couleurs, formes, etc.).
2. L’usage
   Tout contenu web doit être utilisable (Operable). Ça veut dire que, encore une fois quelles que soient les conditions, l’interface utilisateur doit proposer un moyen d’interaction à l’utilisateur – là aussi c’est délicat, car tout le monde n’a pas les mêmes capacités d’interaction. Par exemple, quiconque a déjà utilisé une interface tactile pour manipuler un contenu optimisé pour l’usage d’une souris devrait vite comprendre de quoi on parle.Les principes associés étant :
   • Principe 2.1 : Toutes les fonctionnalités doivent être utilisables avec un clavier.
   • Principe 2.2 : L’utilisateur doit avoir assez de temps pour lire et utiliser le contenu.
   • Principe 2.3 : Ne concevez pas un contenu dont on sait qu’il peut induire des convulsions ou toute autre réaction physique.
   • Principe 2.4 : Aidez les utilisateurs à naviguer, à trouver les contenus et à déterminer où ils sont.
   • Principe 2.5 : Facilitez l’usage des fonctionnalités via diverses méthodes en plus du clavier.
3. La compréhension
   Tout contenu web doit être compréhensible (Understandable). Que ce soit les contenus eux-mêmes ou la capacité à y accéder, l’utilisateur doit pouvoir tout comprendre. Cette fois, le piège se situe dans une remarque anodine : « Mais enfin ! C’est évident. »… Mmh, vraiment ?Les principes associés étant :
   • Principe 3.1 : Assurez-vous que les contenus textes sont lisibles et compréhensibles.
   • Principe 3.2 : Assurez-vous que les contenus apparaissent et agissent de manière prédictible.
   • Principe 3.3 : Aidez les utilisateurs à éviter et corriger les erreurs de saisie.
4. La robustesse
   Tout contenu web doit être robuste (Robust). Là, il s’agit de s’assurer que le contenu puisse être affiché de manière fiable sur tout appareil, ce qui inclut les appareils d’assistance, actuels aussi bien que futurs.Le principe associé étant :
   • Principe 4.1 : Maximisez la compatibilité avec les agents-utilisateurs, y compris les technologies d’assistance.

Les critères de succès : l’épreuve du feu

La difficulté est moins dans la compréhension de ces principes somme toute assez génériques et de bon sens (même s’il est vrai que ça demande quand même pas mal de jus de cerveau pour être sûr qu’on en mesure bien toute la portée) que dans l’évaluation de leurs différents critères de succès. En d’autres termes : comment sait-on que ces principes sont correctement suivis dans notre contexte ?
Ces critères de succès commencent à être assez précis et il serait fastidieux de les passer en revue ici. D’autant plus qu’il existe moult ressources qui en font une véritable transcription opérationnelle, à commencer par le référentiel technique du RGAA pour le lectorat français. On ne va donc pas les détailler ici, mais on va quand même voir comment ces critères sont utilisés pour tester l’accessibilité d’une page web.
Il y a au total 78 critères de succès dans WCAG 2.1 pour évaluer l’accessibilité d’un contenu web. Alors évidemment, tous ne s’appliquent pas en fonction du contexte. Par exemple, s’il n’y a pas de champ de formulaire, aucun des critères liés au principe 3.3 (prévention et correction des erreurs de saisie) ne s’appliquera. C’est d’ailleurs souvent la première chose à faire dans une évaluation d’accessibilité : évaluer quels sont les critères de succès pertinents à tester.
En plus de la pertinence individuelle de chaque critère d’évaluation, ceux-ci sont classifiés en trois niveaux de conformité: A, AA (double A), et AAA (triple A). Il n’y a pas de définition formelle de ce que représente chacun des niveaux de conformité. Cependant on peut considérer les choses comme suit :

• Niveau de conformité A
  Ce niveau de conformité regroupe tous les critères de succès qui sont généralement assez simples à mettre en œuvre ou avec un impact significatif pour tous les utilisateurs. Par exemple, le critère de succès 3.1.1 : La langue d’une page web peut être déterminée programmatiquement.
• Niveau de conformité AA
  Il s’agit des critères qui sont plus exigeants en termes de mise en oeuvre ou qui ont un impact plus spécifique pour les utilisateurs. Par exemple, le critère de succès 1.4.4 : Le texte peut être redimensionné jusqu’à 200% de sa taille sans perte de contenu ni de fonctionnalité.
• Niveau de conformité AAA
  Ici on regroupe les critères de conformité qui sont soit très spécifiques pour une population donnée, soit qui ont un impact de mise en œuvre majeur (une expertise spécifique sera requise), soit avec des conséquences potentiellement contre-productives pour certains utilisateurs. Par exemple, le critère de succès 1.2.6 : Tous les contenus audio/vidéo sont accompagnés d’une transcription en langue des signes.

Ce qu’il faut bien noter c’est que ces niveaux de conformités sont cumulatifs. C’est-à-dire que même si tous les critères AAA sont conformes vous ne pouvez pas déclarer un contenu conforme AAA si un seul critère A applicable n’est pas conforme. On notera également que la plupart des législations existantes demandent un niveau d’accessibilité des contenus qui soit conforme AA.
À ce stade nous allons atteindre le point où les choses se compliquent vraiment. Une fois que l’on a identifié quels sont les critères de succès applicables à notre cas et le niveau de conformité que l’on veut atteindre, il reste à faire l’évaluation et il faut donc se poser la question de comment tester la conformité à proprement parler.

Les conseils de mise en œuvre : la voie de l’initié

Sur le chemin qui mène à la sagesse, WCAG nous donne des armes qui prennent la forme de conseils de mise en œuvre. En effet, pour un même critère de succès, il existe plusieurs solutions techniques ou fonctionnelles pour y répondre. Là encore, tout est affaire de contexte.
Ces conseils de mise en œuvre prennent donc deux formes. D’une part un guide de compréhension avec des fiches explicatives qui détaillent les objectifs de chaque critère de succès et donnent des exemples concrets. D’autre part un ensemble de techniques (et d’éventuelles conditions d’échec) applicables à chaque critère de succès.
Tout ça donne un jeu de poupées russes de documents assez touffus, mais finalement plus compréhensibles que ce qu’on pourrait croire. Reprenons l’exemple du critère de succès 3.1.1 : la langue d’une page web peut-être déterminée programmatiquement.
Déjà, la notion de “détermination programmatique” n’est pas ce qu’il y a de plus évident à comprendre. Pour clarifier ça, un petit tour sur la fiche de compréhension du critère va nous éclairer. En gros, l’objectif c’est que les outils qui vont exploiter le contenu soient capables d’en déterminer la langue le plus facilement possible. Par exemple, pour qu’un lecteur d’écran puisse choisir le bon algorithme de prononciation du texte.
OK, et comment fait-on ça ? C’est là que les techniques de mise en œuvre vont nous aider. Pour ce critère c’est assez facile, il y a 4 techniques incontournables (sufficient) pour valider le critère et 2 techniques additionnelles (advisory) qui apportent du plus sans pour autant permettre de valider le critère. Parmi les quatre techniques incontournables, toutes ne sont pas pertinentes selon le contexte (et oui, encore le contexte). En l’occurrence il y a une technique spécifique pour les documents HTML, une pour les documents Flash et deux pour les documents PDF. Ainsi, si on travaille sur un site web, pour valider le critère de succès 3.1.1 il suffit de renseigner l’attribut lang de la balise <html> sur toutes les pages. Et c’est tout.
Alors c’est sûr que dit comme ça, ça fait un peu pétard mouillé ! Tout ça juste pour un attribut HTML ! Certes, la solution technique est finalement assez triviale, mais l’enjeu, c’est moins la solution que la compréhension des besoins et des impacts et de ce point de vue, WCAG est irréprochable. En outre, garantir que cet attribut est présent sur toutes les pages d’un site et avec une valeur pertinente peut être finalement assez complexe à mettre en œuvre s’il s’agit d’un site multilingue. Pour peu que le contexte s’y prête, ce qu’on imagine facile peut devenir difficile à réaliser.

Kamehameha

En soi WCAG n’est pas compliqué à appréhender, c’est plutôt la ramification infinie des possibilités de mise en œuvre qui peut vite faire tourner la tête (pour ne pas dire : rendre complètement dingue).
L’enjeu de la mise en œuvre de cette spécification va finalement tourner autour des trois problématiques suivantes :

1. La compréhension des principes et des critères de succès de la norme.
2. L’appréciation des contraintes à suivre en fonction du contexte de chaque projet.
3. La compétence des créateurs de contenu pour mettre en œuvre les solutions techniques adaptées.

Finalement, pour devenir un super saiyan de l’accessibilité il n’y a pas vraiment de secret : il faut se former en continu, interroger régulièrement ses pratiques de travail et prendre le temps de relire les passages de WCAG qui correspondent à votre tâche du moment, en particulier les fiches de compréhension et les critères de succès.

Conclusion

Cet article a vocation à vous familiariser avec la norme WCAG qui sera toujours la référence ultime dans toute démarche d’accessibilité web. Ceci dit, sa complexité et sa flexibilité n’en font pas une norme véritablement opérationnelle. Pour cette raison il existe des outils plus pratiques à utiliser au quotidien. Pour n’en citer que quelques-uns :

• Le référentiel technique du RGAA (sans doute la meilleure référence pour les Français en particulier et les francophones en général).
• Les checklists accessibilité premier pas et second pas de Opquast.
• Les ressources du site WebAIM (en particulier leur checklist WCAG 2).
• Et bien d’autres, du plus simple au plus complet, listés sur le site du W3C.

Mais ne nous y trompons pas, pour pratiques qu’ils soient, ces outils ne doivent pas être utilisés aveuglément. Si WCAG est si flexible et sujette à interprétation – et de son propre aveu, incomplète – ce n’est pas par hasard ou par erreur. L’accessibilité est un sujet complexe en ce qu’il requiert d’être confronté en permanence à la réalité d’un contexte donné.
Les meilleurs contenus accessibles sont ceux créés par des personnes qui maîtrisent à la fois les enjeux contextuels et les techniques de mise en œuvre. WCAG répond d’abord fondamentalement à la question des enjeux en forçant les créateurs de contenu web à se poser des questions qu’ils n’imagineraient pas par ailleurs.