Introduction

Je vais vous parler d'accessibilité numérique. Vu le temps dont je dispose, j'ai préparé une présentation assez basique et générale. Je vais vous présenter, d'abord les bases et ensuite les outils et les méthodologies que l'on peut employer.

Je m'appelle Jean-Pierre Villain, je fais de l'accessibilité depuis 17 ans maintenant et je travaille dans une société qui s'appelle Access42 et est spécialisée en accessibilité numérique.

Les fondamentaux de l'accessibilité

Commençons par les fondamentaux de l'accessibilité. Je vais vous parler des utilisateurs, des contextes d'utilisation sur le web, des technologies d'assistance, ainsi que, de manière très globale, de ce que peut représenter l'accessibilité numérique pour un site ou des applications web.

Tout d'abord, on va travailler pour des utilisateurs en situation de handicap. On estime qu'il y a entre 8 et 10 millions de personnes handicapées en France, une certaine partie reconnue, d'autres non reconnus.

Je vous ai mis sur ce slide les différents types de handicap :

Pour autant, dans un contexte d'utilisation ou de consultation d'une application web, ces types de handicaps n'ont pas d'impact forcément direct. Par exemple, un handicapé moteur en fauteuil roulant, s'il a la pleine possession de ses membres supérieurs, n'est absolument pas handicapé pour la consultation d'un site web ou d'une application.

C'est la raison pour laquelle l'accessibilité numérique s'intéresse et agit essentiellement sur le contexte d'utilisation, un contexte qu'on appelle " la situation de handicap ", dont vous avez ici une définition.

Pour résumé, il y a une situation de handicap quand il y a un défaut d'adaptation (d'un contenu, d'une fonctionnalité ou d'une application) et que celui-ci génère une impossibilité. Le contenu, l'application devient inaccessible à un utilisateur du fait d'une déficience.

Je redonne un exemple : notre handicapé moteur qui a la pleine possession de ses membres supérieurs n'est pas handicapé. En revanche, un tétraplégique, qui est aussi handicapé moteur, qui ne peut pas bouger, va être particulièrement handicapé si le site web ou l'application ne contient pas les dispositifs nécessaires pour interagir avec le matériel qu'il va devoir utiliser pour naviguer dessus.

On estime qu'il y a entre 15 et 20 millions de personnes en situation de handicap. C'est tout de même un chiffre conséquent donc je vais le détailler un petit peu. De 15 à 20 millions de personnes sont dans une situation de handicap, ou, comme le dit la littérature, peuvent bénéficier, à un titre ou à un autre, de dispositifs que l'on va mettre en place, au titre de l'accessibilité numérique.

Alors que veut dire ce chiffre ? Il prend en compte une catégorie d'utilisateurs très particulière, celle des seniors. Il s'agit donc de personnes âgées, qui n'ont absolument pas de handicap, mais qui ont une petite déficience. Par exemple, ils voient un petit peu moins, ils se fatiguent un peu plus vite, ils ont du mal à mémoriser, ils ont une appréhension vis-à-vis de la technologie, etc. Bien qu'ils ne soient pas handicapés, le cumul de ces petites déficiences crée une situation de handicap qui est quelquefois plus importante que celle d'une personne handicapée.

Ces 15 à 20 millions de personnes représentent en moyenne 15 % de l'audience d'un site ou d'une application. On sait donc que 15% des utilisateurs d'un site ou d'une application sont susceptibles de se retrouver dans un blocage complet, c'est-à-dire de ne pas pouvoir accomplir une tâche du fait de défauts d'accessibilité.

Je vais vous donner quelques exemples de besoins spécifiques :

Ces utilisateurs vont utiliser ce qu'on appelle des « technologies d'assistance ». Il y en existe plusieurs centaines en fait. Je vous en ai mis ici quelques-unes que je vais décrire brièvement. En regardant la slide en partant du coin supérieur gauche, on a un premier device qui est une tablette braille. C'est utilisé par les aveugles braillistes. La tablette est constituée d'un certain nombre de petites matrices de caractères brailles. Chaque caractère braille est constitué d'une matrice de 6 picots qui montent et qui descendent pour donner le code des lettres. Les utilisateurs parcourent l'écran ligne par ligne avec le doigt. Les tablettes braille sont également des interfaces d'interaction ; les utilisateurs peuvent éditer ce qu'ils sont en train de lire.

L'image suivante vous montre des claviers. Il faut savoir qu'il y a plus d'une centaine de claviers différents. Là, vous avez un clavier ergonomique, pour des personnes avec des problèmes de préhension ou d'utilisation des mains. Il existe également des claviers mono-manuels, ce sont des claviers qui sont faits spécifiquement pour être utilisés avec une seule main, et généralement avec un seul mouvement. Il existe aussi des claviers à pied, pour les gens qui n'ont pas de bras. Ce sont des grands claviers sur lesquels ils tapent avec les pieds.

Sur la dernière image de la ligne, vous avez un outil très rudimentaire, mais également très utilisé, c'est ce qu'on appelle le « stick ». En l'occurrence, c'est un headstick, généralement utilisé par les tétraplégiques, quand ils peuvent encore bouger la tête. Ils utilisent une baguette pour taper sur le clavier ; ils ne peuvent utiliser qu'une touche à la fois. En fait, ils ont recours à des logiciels complémentaires, mais globalement, ils ne peuvent utiliser qu'une touche à la fois.

La première image de la deuxième ligne, c'est un dispositif de contrôle visuel qui permet de piloter le curseur avec les yeux grâce à des petites diodes infrarouge.

Vous avez également la catégorie des lecteurs d'écran, dont j'ai déjà parlé toute à l'heure, qui est la technologie d'assistance la plus connue, mais la moins nombreuse en fait. C'est un dispositif logiciel qui retranscrit vocalement tout ce qui se passe à l'écran, y compris les interactions, pas que les contenus.

A terme, ces technologies donnent souvent des outils que tout le monde utilise. Si vous utilisez des claviers tactiles, c'est parce que certaines personnes ne pouvaient pas utiliser les claviers " normaux " donc on a inventé des claviers visuels. Maintenant c'est passé dans le domaine commun.

Ensuite, vous avez, un peu plus spectaculaire, ce qu'on appelle un contacteur à souffle. Il est utilisé par un utilisateur qui ne peut que souffler. C'est très simple à comprendre ; on déplace le focus sur tous les éléments interactifs de la page et on récupère une interaction de l'utilisateur. Là, en l'occurrence, c'est le souffle. L'utilisateur voit se déplacer son focus et quand il souhaite l'arrêter, il souffle une fois. Quand il souhaite actionner un élément interactif, il souffle deux fois (ou il attend quelques secondes, c'est temporisé).

Ensuite, on a une autre grande famille de matériels. Ici, vous voyez un trackball ; ça ressemble à un jouet pour enfant mais en réalité, c'est fait pour les gens qui ont des problèmes moteurs importants. C'est assez gros, environ 15 cm de diamètre, et ça comporte plusieurs boutons qui permettent de manipuler le curseur, etc.

Et enfin, encore plus spectaculaire, il existe des dispositifs qui permettent de piloter le curseur par la pensée. C'est également du curseur supervisé, ça marche exactement comme le contacteur à souffle. On active les éléments interactifs les uns après les autres. Cette technologie fonctionne avec un logiciel de machine learning, qui s'appelle " Braingate ". L'utilisateur apprend à la machine à reconnaître une action ; quand c'est possible, l'utilisateur serre sa main et à ce moment-là les éléments, un lien par exemple, se déclenchent. Ces utilisateurs-là utilisent donc d'autres dispositifs avec le même fonctionnement, comme un clavier visuel où les touches s'activent les unes après les autres et pour écrire, ils font un geste.

Tous ces dispositifs sont une immense famille, ici vous n'en avez que quelques-uns. Un soir où vous n'avez rien à faire sur Google, vous cherchez « technologies d'assistance », vous allez y passer plusieurs heures, il y en a des centaines.

Je ne sais pas si vous connaissez Stephen Hawking ? Il a une maladie dégénérative à évolution très lente. Il a donc changé de méthode d'interaction au fur et à mesure, à l'heure actuelle, il a un petit micro sur la commissure de la lèvre. C'est ce qui lui convient le mieux actuellement. C'est un système de curseur supervisé ; pour écrire il fait [bruit de souffle]. Dès que le micro détecte un son, ça se déclenche.

Sur le site d'Access42, vous avez des ressources et des vidéos. Vous découvrirez comment on parvient à faire piloter un bras robotisé à une personne tétraplégique, afin qu'elle puisse se servir un verre d'eau. Vous verrez comment on rend la vue à quelqu'un qui a perdu la vue en lui mettant un écran miniaturisé sur la langue.

L'idée derrière cette présentation des technologies d'assistance c'est de vous montrer que, du point de vue des technologies, on a tout inventé. Il n'y a plus rien à inventer en réalité, il n'y a qu'à améliorer sans arrêt ces technologies. Et que ça coûte très très cher, c'est un investissement fabuleux et énorme.

C'est très cher et, partiellement, ça ne sert à rien ! C'est-à-dire que tous ces utilisateurs, lorsqu'ils arrivent sur le web, ils ont tout ce qu'il faut pour interagir et nous, je suis un ancien développeur donc je me mets dans le même paquet, nous développons des sites et applications qui ne sont pas du tout accessibles, donc leurs technologies d'assistance ne fonctionnent pas.

L'accessibilité numérique : 5 principes de base

La méthode de résolution de ce problème c'est l'accessibilité numérique, je vais vous présenter rapidement ce que c'est.

Commençons par un exemple : si vous utilisez un div pour faire un bouton, vous prenez un div et vous mettez un event clic via JavaScript dessus, les dispositifs qui déplacent le focus n'iront jamais sur votre bouton. Un div ne peut pas prendre le focus. Donc, même si j'ai dépensé des centaines de milliers d'euros pour faire un micro, si vous m'interdisez de prendre le focus sur votre élément, il ne pourra jamais se déclencher.

C'est tout ce genre de problèmes que l'on rencontre, dans les techniques de développement, dans les technologies de développement, dans les langages que l'on va utiliser, etc.

En fait, l'accessibilité numérique c'est à la fois très trivial, c'est un niveau de technicité proche du zéro parce que ça se résout très souvent avec des bonnes pratiques. Mais, à la condition que si vous faites un clavier virtuel, vous le fassiez avec JavaScript. Si vous faites une calculette en HTML, avec que des div et des clics sur des div, l'utilisateur pourra faire ce qu'il veut, ça ne marchera pas, il ne pourra pas prendre le focus dessus.

Sur cette slide, j'ai mis les cinq principaux domaines que l'on va aborder. Nous allons rentrer dans le détail au fur et à mesure.

  1. Donner des équivalents textuels aux images, au son et à la couleur. Par exemple, quand je donne une indication par la couleur, si un utilisateur ne voit pas la couleur, il n'a pas l'indication.
  2. Structurer les contenus : on est des djihadistes de la structuration des contenus ! On veut des titres, on veut des listes, on veut des paragraphes, on veut des choses comme ça.
  3. Gérer la présentation par CSS : ça, c'est un point capital ! Même si maintenant, ça commence à être généralisé. Il y a beaucoup de dispositifs qui permettent de personnaliser les contenus. Par exemple, je vous ai parlé du reflow qui consiste à prendre directement ou indirectement (via des CSS users) des interfaces complexes et à refaire les CSS pour les afficher sur une seule colonne. C'est utile, par exemple, pour des déficients visuels qui ont des problèmes de perte de vision centrale ou périphérique.
  4. Permettre l'utilisation des dispositifs d'adaptation des contenus. Par exemple, on interdit l'utilisation du pixel pour les tailles de police, tout simplement parce que les navigateurs peuvent agrandir les textes, les polices de caractères, sauf si on les exprime en pixels.
  5. Mettre à disposition des API systèmes toutes les informations d'accessibilité. C'est un domaine très particulier qui a un lourd impact dans les environnements applicatifs. On va inventer et développer des composants dont on a besoin : des systèmes d'onglets, des fenêtres modales, des choses comme ça. Et comme ça ne fait pas partie d'éléments natifs du HTML, on va devoir, nous-mêmes, équiper et transmettre ces informations aux API systèmes, pour que les technologies d'assistance, par exemple les lecteurs d'écran, puissent les récupérer et les vocaliser.

Ce que je viens de vous présenter ce sont vraiment les principes de base, les cinq grands thèmes sur lesquels vous devez travailler. Dans la suite de ma présentation, je vous ferai quelques petits exemples.

L'accessibilité numérique : normes et référentiels

Comment va-t-on travailler et avec quels outils ? Comme je vous l'ai dit il y a quelques minutes, ça se résume souvent à des bonnes pratiques. Personnellement, je n'aime pas tellement le terme « bonnes pratiques », mais bon, peu importe ! Des recommandations, on va dire.

On va travailler, essentiellement, en appliquant des normes et leur traduction opérationnelle, qui sont des référentiels.

La première norme qu'on va appliquer s'appelle WCAG pour « Web Content Accessibility Guidelines ». C'est un document très important, qui contient les recommandations qui vont nous permettre de comprendre comment on fait pour rendre les contenus et les fonctionnalités accessibles.

Côté front, on est sur le code généré c'est très important à comprendre, on va vérifier qu'on a des alternatives aux images, qu'on a des titres, qu'on a des listes, que tout ce qu'on peut faire à la souris, on peut le faire au clavier et inversement, etc.

Les WCAG existent depuis 1998, ça date d'un certain temps. En 2018, la troisième version qui s'appelle WCAG 2.1 va être inaugurée.

C'est un document très technique, très abstrait, puisqu'il doit fonctionner indépendamment des technologies. Ce qui le rend très difficile à utiliser directement. C'est la raison pour laquelle la plupart des pays, à l'exception des pays anglo-saxons, développent leurs propres référentiels. Ce sont des méthodes d'application destinées à rendre les WCAG un peu plus « digérables », plus opérationnelles.

En France, nous avons le RGAA, le Référentiel Général d'Accessibilité pour les Administrations, qui est issu d'un référentiel antérieur qui s'appelait AccessiWeb. Ce référentiel a traduit WCAG en critères beaucoup plus opérationnels, plus concrets.

Par exemple, dans WCAG, vous ne trouvez pas de thématique spécifique aux images. Une image dans WCAG, c'est un « contenu non textuel ». Dans RGAA, on va trouver des images, des liens, des tableaux, de la structure, etc.

Ces référentiels sont donc des documents chargés de rendre les normes opérationnelles. Sur ma présentation, vous avez les liens sur lesquels vous pouvez aller vous renseigner et visiter ce référentiel.

Je vais vous donner un exemple précis. Dans WCAG, la règle 1.1, que je ne vais pas vous détailler, vous l'avez à l'écran, lisez-la attentivement.

Donc, cette règle nous dit que, pour les contenus non textuels, il faut, quand c'est nécessaire, des équivalents textuels. C'est donc la règle, le critère. Des contenus non textuels, on sait ce que c'est : on connaît les images, on va se dire « une vidéo est un contenu non textuel », etc.

C'est beaucoup plus difficile à comprendre quand on va parler d'indications données par la couleur. Par exemple, le fait de dire sur un formulaire, que les champs en rouge sont obligatoires, on donne une information par la couleur, c'est un contenu non textuel, il nous faudra un équivalent textuel.

Un autre exemple, je ne sais pas si vous connaissez la balise iframe qui permet d'embarquer du contenu. L'iframe lui-même est un contenu non textuel. Là encore, il va falloir trouver un équivalent textuel, etc.

Le problème de WCAG, c'est ça : on a une règle mais derrière cette règle, on a plus de 60 techniques et plus d'une vingtaine d'objets HTML qui sont concernés.

Le travail qui a été fait sur le référentiel RGAA est très simple : on a travaillé sur WCAG et on les a rendus très opérationnelles. Donc, pour reprendre l'exemple de cette première règle WCAG, dans RGAA elle se traduit par 19 critères différents qui impactent 19 situations différentes. On va avoir des critères sur les images, sur les formulaires, sur les liens, etc.

Chaque fois qu'on a un contenu non textuel dans un lien, c'est un lien image. J'ai une image, je fais un lien dessus, ça devient un contenu non textuel, il faut un équivalent textuel.

Sur ma présentation, j'ai isolé deux critères : « Chaque image a-t- elle une alternative textuelle ? » et « Chaque cadre en ligne a-t-il un titre de cadre ? ». On passe de quelque chose de très abstrait, très technique, difficile à comprendre et appréhender, à quelque chose qu'on espère beaucoup plus opérationnel.

L'accessibilité des CMS

WCAG, c'est pour les contenus. Ensuite, pour les outils d'édition, c'est un domaine bien particulier, on va avoir ATAG. Les CMS ont un pied dans chaque, si je peux me permettre cette expression.

ATAG, ce sont les recommandations qui vont nous permettre, dans un premier temps, de comprendre comment on fait pour que des outils d'édition (des CPS, des CMS, des logiciels, des routines de transcodage, de transformation de format) produisent du contenu accessible. Et, dans un second temps, ces recommandations permettent aux contributeurs non techniciens, de produire du contenu accessible.

Il faut savoir qu'ATAG est encore en version de travail. C'est quelque chose de très compliqué à produire, parce que c'est extrêmement abstrait. Je vais vous donner un exemple après, vous allez vous en rendre compte.

Sur le RGAA, on a produit un référentiel qui s'appelle RGAA/CMS. En fait, on a pris ATAG et on l'a appliqué à un contexte exclusif de CMS. Je précise que je parle bien de CMS, pas framework, donc des CMS plutôt type Wordpress, etc. Et donc, là encore, on a essayé de rendre ça opérationnel.

Par exemple, dans ATAG, vous avez la guideline 2.3.1 qui explique qu'il faut assister l'auteur lorsqu'on a un outil d'édition qui permet d'insérer du contenu non textuel. Il faut que cet outil d'édition permette à l'auteur de mettre les équivalents textuels.

Là encore, c'est très abstrait, ce n'est pas du tout du tout défini ; c'est valable pour les images et tout un tas d'autres choses. Dans RGAA/CMS, on en a fait un critère composé de deux tests.

Un premier test qui permet de vérifier qu'effectivement, toutes les fonctionnalités avancées d'édition de contenu non textuel donnent la possibilité à l'auteur de mettre un équivalent textuel. J'ai une fonctionnalité d'insertion d'image, j'ai la fonctionnalité qui me permet de mettre une alternative aux images.

Et le deuxième test vérifie qu'il n'y a pas de restrictions, par exemple de restrictions liées à des profils d'utilisateurs. Je peux uploader des vidéos, mais comme je ne suis pas un « contributeur ++ », je ne peux pas mettre de sous-titres.

ATAG nous permet donc de travailler côté back, c'est-à-dire sur les interfaces d'édition, sur les fonctionnalités, sur les systèmes d'aide, etc. C'est quelque chose de très technique qui pose pas mal de problèmes.

Les champions actuels d'ATAG, c'est Wordpress. Les RTE s'intéressent beaucoup à ATAG pour essayer qu'on les utilise. CK Editor commence à faire des implémentations ATAG relativement intéressantes.

L'API ARIA

Enfin, nous avons une API magique, qui s'appelle ARIA. Elle impacte massivement les contextes applicatifs, aussi bien côté back sur l'interface, qu'une application web complète. Elle nous permet de rendre tout ce qu'on va développer avec JavaScript accessible.

Cette API nous permet de définir des rôles, des états, des propriétés.

Elle met à disposition des modèles de conception. Lorsqu'on veut faire une modale, c'est l'exemple que j'ai pris, parce qu'il est plus simple à comprendre, on a un petit modèle qui nous dit ce que doit être une modale, quelles propriétés elle a, comment elle doit réagir et comment elle doit se comporter.

Cette API est une méthode de surcharge donc, avec ARIA, on peut transformer tout et n'importe quoi. Je peux prendre un span et le transformer en lien, je n'ai pas de problème à faire ça.

Généralement, nous l'utilisons en technique de patch ; soit en correction de framework JS, soit carrément en faisant du patch un peu « sauvage », si j'ose dire, quand on n'a pas les moyens de changer le code HTML, par exemple.

Définir des composants d’interface et de structure

ARIA nous permet de définir des composants d'interface et de structure.

Lorsque vous faites quelque chose qui ressemble à un système d'onglets - j'active des onglets qui affichent des contenus sans rechargement de page - vous avez un modèle de conception qui s'appelle « tab panel », qui vous permet d'équiper tout ça.

Ça nous permet également d'informer des états et des propriétés des composants d'interface. Sans rentrer dans le détail, le navigateur va transmettre à l'API système toutes les propriétés d'un objet en cours de consultation.

Ces propriétés sont stockées dans ce qu'on appelle l’« accessible tree » et les technologies d'assistance récupèrent ces informations pour vocaliser et faire interagir. C'est assez spécifique aux lecteurs d'écran.

Intéressons-nous à l'exemple qui est illustré sur la slide : je prends un div, je lui mets un role="checkbox" et une propriété aria-checked, qui passe de true à false en fonction de l'état de la case à cocher. Je lui mets un tabindex="0" pour le rendre accessible au clavier, et avec JavaScript, quand mon utilisateur a interagi dessus, je passe le aria-checked à true ou false. Avec CSS, je change l'image : coché, pas coché.

C'est bon ! Je n'ai pas employé un type checkbox, je n'ai rien employé du tout ! Ça sera retransmis tel quel dans l'accessible tree et pour le lecteur d'écran. Pour un utilisateur aveugle, il n'y aura absolument aucune différence.

Mise à jour de contenu dynamique

Ensuite, on va gérer les mises à jour du contenu dynamique.

Je fais apparaître quelque chose dans un coin, comment je fais en sorte qu'un lecteur d'écran en soit informé ? J'ai une propriété particulière dans ARIA qui s'appelle aria-live.

Nous allons prendre l'exemple d'un chatbot. Vous mettez un aria-live="polite" sur tout le chatbot et, à quelques détails près, c'est accessible. Ça va permettre au navigateur de dire au lecteur d'écran : « j'ai une zone qui a été mise à jour et on veut que tu la revocalises ».

Interactions clavier

La difficulté d'ARIA n'est pas dans les rôles, les états, les propriétés, etc, tout ça c'est très trivial, c'est très simple à faire. Nous sommes des développeurs JS sérieux et nous utilisons des supers frameworks donc il y a aucun souci !

La difficulté, c'est les comportements les interactions au clavier qui sont extrêmement complexes.

Sur un simple tabpanel, vous avez 12 interactions clavier à gérer et vous devez les gérer intégralement. Vous prenez la main sur le clavier et vous baladez l'utilisateur là où il doit aller ; c'est défini dans ce qu'on appelle des « modèles de conception ».

Sur ma présentation, vous avez également deux liens : un vers l'API et un vers un document extrêmement important qui est le guide de conception de ces composants.

Je vais prendre juste un exemple parce qu'on n'a pas le temps, un exemple très simple, c'est la modale. Vous avez ici l'image de ce que doit être une modale.

Une modale, ça peut être un span, ça peut être un div, ça peut être un paragraphe (mais pas un élément interactif, on ne peut pas faire une modale avec un bouton) sur lequel on va mettre un rôle. On va déclarer que cet élément doit être restitué comme une fenêtre modale. C'est-à-dire que l'on met un attribut role="dialog" (ou alertdialog, il n'y a pas de différence réelle entre les deux) et ensuite on doit le nommer. Pour cela, il existe une propriété qui s'appelle aria-label ou une propriété de liaison qui s'appelle aria-labelledby. Ce qui donne, par exemple : role="dialog" aria-label="Connexion". C'est tout, le motif de conception s'arrête là !

Ensuite, on n'a que du comportement ; celui du composant lui-même et de l'interaction clavier. Le comportement du composant, il est très simple à comprendre : lorsque la modale s'ouvre, je prends le focus, je positionne le focus sur la modale elle-même ou sur un de ses éléments interactifs.

Tant que la modale est affichée, je capture le focus, c'est une technique de « trapping focus », de façon à ce que mon utilisateur ne puisse interagir qu'avec le contenu de la modale. Quand la modale est fermée, je redonne le focus sur l'élément qui a permis de l'ouvrir.

En JavaScript, c'est assez simple à faire et j'ai une interaction clavier extrêmement simple : la touche escape, je surveille le clavier et la touche escape doit fermer la modale.

Vous avez donc un exemple de motif de conception. Celui-là est assez peu utilisé mais très simple. Il y en a d'autres qui sont beaucoup plus complexes.

On peut réellement refaire des applications complètes en techno web, ça a été fait pour ça. On peut faire des menus de commandes, des « menu bars », on a du toolbar, on a même un modèle de conception (window splitter) qui sépare l'écran en deux parties indépendantes l'une de l'autre.

Toutes ces possibilités sont définies par des motifs de conception. Logiquement, on s'attend à ce que vous respectiez ces motifs ; le moindre petit tooltip - on va en voir un exemple dans un instant - doit correspondre à un motif de conception, à un modèle de conception, pour que ce soit accessible.

Les navigateurs implémentent ARIA de manière tout à fait correcte, les lecteurs d'écran également. Donc si on fait correctement le job, c'est accessible !

On a parlé des frameworks JS (Angular, React, etc), tous ces frameworks fournissent ou permettent de développer rapidement ou facilement des composants d'interface, des progressbar, des systèmes d'onglets.

Sur ma slide, j'ai pris l'exemple d'un tooltip React, très facile à comprendre. Il lui manque un truc : un tooltip doit se fermer avec la touche escape.

Pourquoi ? Parce que certains utilisateurs déficients visuels ne voient qu'une petite partie de l'écran, et si on leur affiche le tooltip, ils ne voient plus rien, parce qu'ils voient que le tooltip. Ils doivent donc pouvoir le fermer immédiatement par la touche escape.

Un travail a donc été fait sur les bibliothèques JavaScript. On a pris les quatre plus grosses bibliothèques, à savoir jQuery, Angular, React sur Bootstrap, et puis une autre dont le nom m'échappe. On a été tester tous les composants ; on a regardé s'ils étaient accessibles et on l'a publié. Mes collègues développeurs ont ensuite publié les méthodes de correction.

Sur cette diapo, vous avez la méthode de correction pour le tooltip React. Mais l'ensemble du travail dont je vous parle est disponible dans les ressources. C'est mis à jour une fois par an, donc c'est très souvent en retard, forcément, voire très très en retard ! Mais peu importe, parce qu'en fait, cette ressource vous donne des indications. Si vous copiez collez les méthodes de surcharge dans vos scripts et que ça fonctionne, tant mieux ! Si non, ça vous permet de savoir à peu près comment vous pouvez essayer de les corriger.

Lorsqu'on ne peut pas les corriger, cette ressource donne une méthode alternative qui permet de conserver l'accessibilité. Par exemple, si vous faites un date picker, il faut que l'utilisateur ait la possibilité de saisir la date à la main, ça suffit.

ARIA va nous permettre également de patcher des mauvaises pratiques. Je vous ai mis deux exemples courants, auxquelles il faut faire attention.

Le premier - ça ne se voit pas beaucoup là, sur les screenshots que j'ai faits - c'est cette maladie des développeurs de faire des boutons avec des liens. Un lien, c'est fait pour afficher une ressource, ce n'est pas fait pour faire un bouton.

Vous avez ici un lien avec un joli a href avec un JavaScript void, où devant, on voit a href="#" qui permet d'afficher et de masquer une zone. On tape très fort sur ce sujet-là parce que si je suis aveugle, ce que moi je vais entendre, c'est un lien qui va me dire par exemple « afficher les actualités ».

Et en fait, en réalité, ce que ça fait, c'est que ça affiche une zone et quand je reclique dessus, ça la masque. Mais si c'est un lien et que c'est que c'est mal fait, ce qui est le cas ici, il ne se passe rien lorsque je clique sur le lien.

En tant qu'utilisateur aveugle, je me dis que soit c'est un lien qui ne marche pas, soit il y a quelque chose quelque part qui s'est ouvert - un nouvel onglet, une nouvelle fenêtre ou je ne sais quoi, et que parce que je ne vois pas la page, je ne le sais pas. Ici, on a un lien avec a, avec href qui sert à rien et une jolie propriété ARIA parce que les développeurs ont essayé de faire de l'ARIA avec une propriété qui s'appelle aria-expanded. aria-expanded, c'est du switch (true/false) qui permet de signaler que la zone contrôlée est ouverte ou masquée.

Quand on est face à ça, soit on change le code HTML et on remplace le a par le button, on supprime le href et on a terminé le job. Soit, on ne peut pas, parce que c'est généré ou autre. A ce moment-là, on va utiliser ARIA, donc sur ce lien a href, on va mettre un role="button" et c'est tout !

On a une propriété supplémentaire qui s'appelle aria-controls qui stocke l'ID de la zone qui est contrôlée, mais c'est tout, donc ça on le fait, et très souvent, les patchs que l'on fait avec ARIA sont faits côté front. C'est de la surcharge.

Un autre exemple rapidement : les champs de formulaires sans labels sur lesquels on fait des zones de saisie dans le langage HTML, on doit mettre des labels, on n'en met pas.

Et là c'est pareil, si on ne peut pas éditer le code HTML - ici c'est un paragraphe qui contient un passage de texte et un input de type texte - avec ARIA, on va faire une surcharge, on va lui mettre un aria-label, qui va reprendre le passage de texte de telle sorte que l'utilisateur de lecteurs d'écran, qui lorsqu'il rencontre des éléments de formulaires n'a accès qu'aux éléments de formulaires eux-mêmes, va pouvoir avoir l'information qu'on lui demande de saisir.

Ce sont donc trois utilisations d'ARIA :

  1. définir des composants ;
  2. équiper les composants ;
  3. patcher, soit du code HTML, soit du composant quand on ne peut pas faire autrement.

Je vais en terminer avec l'accessibilité des CMS. Nous allons lire tous ensemble ce joli avertissement : rendre un CMS capable de produire des contenus accessibles, c'est très complexe, c'est une course de fond.

Cela ne concerne pas simplement les RTE. De nombreux CMS disent : « ça y est, on est accessible » parce qu'ils ont mis CK Editor dans l'interface. CK editor est un RTE particulièrement doué pour l'accessibilité, mais l'accessibilité ne doit pas concerner que la zone d'édition mais l'ensemble de l'interface du CMS.

Il faut travailler en profondeur sur l'interface, ses fonctionnalités, les contenus générés automatiquement et les plugins. La grande problématique d'accessibilité des CMS maintenant, c'est les plugins !

Il faut également proposer des outils de tests automatiques et des aides aux contributeurs, c'est un point central ! Dans ATAG, il existe une recommandation qui nous dit que lorsque l'éditeur enregistre un contenu, on doit le scanner automatiquement, récupérer toutes les erreurs automatiques, afficher un rapport et des messages pédagogiques permettant au contributeur de comprendre ce qu'il doit faire et lui fournir, si possible, des méthodes de correction sans être obligé de rééditer le contenu.

Si vous voulez voir une implémentation ATAG, vous en avez une qui est quasiment miraculeuse, elle est dans Office. À partir de 2010, ils ont un moteur de détection et d'accompagnement de l'accessibilité qui est une merveille ! C'est une implémentation full ATAG. Vous corrigez l'accessibilité d'un document Office, sans éditer le contenu, uniquement par de l'interaction.

Il faut faire très attention aux wordings. Je vais vous raconter le drame de l'insertion d'images sous SPIP. Quand on insère une image sur l'interface par défaut, on a le choix, on peut mettre un titre à l'image ou on peut mettre une description. Laquelle produit l'alternative ? Naturellement, les contributeurs utilisent « description ». Manque de bol, le champ description ajoute une légende en-dessous de l'image. Ils retirent la description, ils essayent quand même, ils sont pleins de bonne volonté, ils utilisent alors le champ « titre ». Manque de bol bis, le titre produit une alternative oui mais peut-être, au cas où, pas forcément tout le temps.

Si vous voulez faire une alternative d'image sous SPIP, vous êtes obligés d'utiliser du code manuel, le meta langage de SPIP.

Il faut faire très attention au wording. Une alternative d'image, vous pouvez appeler ça comme vous voulez, mais il faut qu'il y ait le mot « alternative » dedans ! « Équivalent textuel », « alternative de l'image », mais ni « titre », ni « description ». Certaines personnes travaillent beaucoup sur les interfaces mais ruinent tous leurs efforts parce qu'elles ne choisissent pas le bon wording.

Pour l'accessibilité des CMS, comme je vous l'ai expliqué, on aura besoin de WCAG et du RGAA, de ATAG ou RGAA/CMS et d'ARIA.

On aura également besoin d'un plan d'amélioration, je devrais dire amélioration continue, mais c'est une amélioration sans jamais de fin en réalité. Donc, je disais un plan d'amélioration continue assez rigoureux, raisonnable et priorisé.

Lorsqu'on va commencer à s'attaquer à l'accessibilité d'un CMS, il va falloir prioriser. Il ne faut pas y aller et essayer de tout faire en même temps. On va aller de l'utilisateur le plus néophyte vers l'utilisateur le plus doué et pas l'inverse. C'est souvent l'inverse qui est fait, et c'est dommage ! Ce qu'on veut, c'est que le contributeur qui connaît rien à HTML soit capable de produire un minimum d'accessibilité.

Donc effectivement, on va commencer par le RTE et puis après, on va complexifier au fur et à mesure.

Wordpress, c'est dix ans de travail avec un cador, ils ont un cador de l'accessibilité chez Wordpress, un top ten ! Dix ans de boulot pour arriver là où ils en sont, le résultat est plutôt pas mal. Wordpress est, à l'heure actuelle, le CMS qui permet à des contributeurs néophytes de produire des contenus accessibles le plus facilement.

La norme WCAG, ou le référentiel RGAA, on va l'utiliser pour vérifier que les contenus produits, les contenus générés - on est côté front - sont accessibles.

Par exemple : si vous faites une petite fonctionnalité qui génère automatiquement un formulaire de contact, vous allez chercher le RGAA, vous regardez la thématique formulaires, si tout est bon vous n'avez rien à faire, sinon, il va falloir améliorer !

ATAG et RGAA/CMS vont vous servir à accompagner la mise en accessibilité de l'interface elle-même et de toutes les fonctionnalités de production et d'édition des contenus. Vous ne pourrez pas le faire tous seuls, vous aurez besoin de gens très spécialisés pour faire ça. C'est un domaine qui est vraiment très complexe. J'ai des cartes de visites, si ça vous intéresse.

ARIA on l'utilise pour tout le reste : c'est-à-dire, les composants d'interface, les composants d'interface de l'interface et les composants d'interface que l'on va produire dans le contenu évidemment.

On l'utilise aussi pour patcher, c'est quelque chose qui se fait souvent à l'heure actuelle, pour patcher un plugin qui est très utilisé, une petite fonctionnalité d'inscription automatique à la newsletter. Il y a tout ce qu'il faut mais pas de label sur le champ de saisie. C'est dommage, donc on va utiliser ARIA pour aller patcher ça côté client.

Pour résumer, il faut travailler avec tout : les WCAG, ATAG, le référentiel opérationnel RGAA, les référentiels CMS et ARIA.

Des ressources utiles

Je vais juste terminer en vous disant qu'il existe, en accompagnement au RGAA, un ensemble de ressources absolument incroyables, on en a une trentaine.

Je vous en ai mis quelques-unes ici sur ce slide :

J'ai un dernier message un très important : si vous voulez faire de l'accessibilité, il faut vous former.

Vous pouvez très bien prendre le RGAA et ses ressources, puis passer de longues semaines à vous autoformer, ensuite sortir votre site et puis vous faites appel à quelqu'un comme moi, j'arrive et je vous dis « Ce n'est pas bon ! ». C'est un domaine, je me répète, de technicité quasi zéro, la complexité ne vient pas de la technicité, elle vient de l'expérience. L'expérience ne se transmet que par la formation.

Ce sont des formations assez légères, il nous faut trois jours pour former un développeur. En trois jours, vous avez vu toutes les thématiques, vous avez un petit peu manipulé et surtout vous savez où trouver l'information.

Conclusion : formez-vous, formez-vous, formez-vous ! Et cette fois-ci, j'ai fini !