Palmarès 2021 des idées fausses sur l'accessibilité, en forme de retour d'expérience

Je me présente. Je suis développeuse Web. Au lycée, j’ai commencé à écrire du CSS. Ensuite, j’ai fait beaucoup de maths et beaucoup de physique. Ensuite, j’ai fait du PHP et j’ai décidé de devenir développeuse Web. J’ai commencé en 2010.

10 ans plus tard, je suis devenue développeuse indépendante et j’ai passé la certification Opquast, on verra bientôt pourquoi. Encore un an plus tard, j’ai passé la certification avec Access42 pour coder et développer des sites accessibles.

Voilà ce que je fais dans la vie, professionnellement. Pourquoi suis-je allée passer la certification Access42 Accessibilité ?

C'est parce que, alors que je venais de me lancer et que je communiquais sur le fait que j’avais eu ma certification Opquast, il y avait des gens qui venaient, qui voulaient me donner des sous et que je travaille pour eux en disant : « Ta certification Opquast, ça m’intéresse parce que j’ai des besoins ou des obligations en termes d’accessibilité ».

J’ai été d’accord, mais ce n’est pas du tout là-dessus que j’avais communiqué, donc c’était un peu étrange.

De quoi on parle ? On parle de Opquast. Opquast, c’est beaucoup de choses, notamment une liste de 240 règles qui ratissent tout ce qui concerne la qualité Web et la qualité expérience utilisateur sur vos sites. Ça ratisse beaucoup plus large que la technique et ça ratisse beaucoup plus large que l’accessibilité.

Qu’est-ce qu’on a en face ? En France, on a le Référentiel général d’amélioration de l’accessibilité ou RGAA, qui est une obligation légale pour certaines entreprises et pour tout ce qui est service public.

Ça parle uniquement d’accessibilité. Il y a un certain nombre critères regroupés en catégories. Ça peut ressembler un peu à Opquast, dans le sens où on a une liste de règles que l’on doit appliquer pour être conforme, mais ce n’est pas pareil.

L’idée fausse, c’est que quand on est expert Opquast, on est expert accessibilité. Ce n’est pas tout à fait vrai. Je m’en suis rendu compte quand j’ai essayé de faire de l’accessibilité avec une certification Opquast.

Comme je l’ai dit, Opquast ratisse très large. Ça ne parle pas que de technique, ça ne parle pas que d’accessibilité. Ça parle aussi de sécurité, aussi bien du point de vue technique que du point de vue fonctionnel. Par exemple, là, j’ai écrit "une adresse de livraison qui doit pouvoir être différente de l’adresse de facturation". Ce n’est pas du tout purement technique. Ça ratisse vraiment très, très large.

Dans les critères RGAA, il y a pas mal de technique. Il y a aussi un peu de règles qui vont parler de design et quelques-unes qui vont parler de contenus.

On peut être expert Opquast, respecter toutes les règles Opquast sur un site et ne pas être conforme au RGAA parce que le RGAA va chercher des choses beaucoup plus pointues sur certains points. Pour autant, il y a quand même un bon tiers des règles Opquast qui ont un impact positif sur l’accessibilité. J’ai quand même dû chercher pour trouver des critères RGAA qui n’étaient pas dans Opquast.

Il y a beaucoup de points communs. Opquast, ça va être une très bonne base pour avoir un site bien accessible derrière, mais ça ne suffira pas forcément si vous avez une obligation d’accessibilité légale.

Sans transition, on va passer à l’idée fausse, qui est la suivante. J’avoue que c’était plutôt moi qui la disais à une époque. Je disais que si tu utilises un framework JavaScript qui ajoute des attributs HTML qui n’existent pas, ça va te pourrir l’accessibilité de ton site.

Dit autrement, HTML non standard, ça veut dire que ton site est inaccessible et HTML standard, ça veut dire que ton site va être accessible.

La réalité est beaucoup plus compliquée que ça. En réalité, un HTML standard, ça va être une bonne base pour l’accessibilité, mais ça sera, dans l’immense majorité des cas, complètement insuffisant.

À l’inverse, certains écarts aux standards, typiquement les attributs qui n’existent pas et qui sont ajoutés sur les éléments HTML, ça ne pose pas de problème d’accessibilité.

Il y a tellement de possibilités pour faire un site inaccessible que l’on ne peut pas s’arrêter juste au HTML. Un HTML bien fait, c’est une base. Ensuite, il faut quand même surveiller le CSS, le JavaScript. Il faut même sortir du métier du développeur et d’intégrateur parce qu’il faut aussi faire attention aux contrastes au niveau du design. Il faut faire attention au contenu, dans le sens où il faut prévoir des textes alternatifs sur les images. Il faut rédiger le texte d’une manière compréhensible.

Le HTML standard, c’est pas mal, mais on ne peut pas se contenter de ça pour l’accessibilité et on peut pardonner certaines choses que pardonnent aussi les lecteurs d’écran.

Celle-là, je l’ai entendu après six mois. Je venais d’arriver sur un projet. On avait été me chercher justement pour parler d’accessibilité avec mes collègues et quelqu’un m’a dit : "Notre site, il est bien. Il va être accessible puisqu’on n’a pas de JavaScript".J’ai un petit peu levé les sourcils comme ça : "Si tu le dis". Mais quand même, je n’étais pas complètement convaincue.

L’idée derrière, ça veut dire que si on n’a pas de JavaScript, on est accessible parce qu’on ne peut pas faire de JavaScript accessible, peut-être. Il y a aussi une idée qui est assez répandue. Ce serait que les lecteurs d’écran ne liraient pas le JavaScript.

La réalité, c’est que c’est faux. On peut tout à fait écrire du JavaScript accessible. Ça demande un peu de travail, mais c’est possible. Je vais en reparler juste après.

À l’inverse, on peut être très, très inaccessible sans avoir besoin d’écrire une seule ligne de JavaScript. C’était le cas du site sur lequel je venais d’arriver. Maintenant, ça va mieux.

Parfois, il y a des choses que vous allez faire sans JavaScript qui vont être inaccessibles : toutes les apparitions de contenu au survol de la souris, les super animations fancy en CSS. Parfois, vous aurez besoin d’ajouter du JavaScript pour que ces choses soient accessibles aux personnes qui utilisent un lecteur d’écran.

Voilà la réalité du JavaScript. J’avoue que ce n’était pas évident pour moi il y a un an, mais maintenant, ça va mieux. Merci les deux formations que j’ai suivies, qui m’aident là-dessus.

Je vous le disais, on peut écrire du JavaScript accessible, ce n’est pas forcément compliqué. Pour ça, je voulais vous parler des ARIA Authoring Practices ou Aria Authoring Practices en français.

Note de transcription : la blague était également mauvaise à l'oral.

C'est un titre que j’aurais du mal à le traduire en français comme ça. Qu’est-ce que c’est ? Il s'agit un document avec une très longue table des matières que je vais vous expliquer.

Note de transcription : je navigue dans les ARIA Authoring Practices en prononçant les paragraphes suivants, jusqu'à la fin de la section.

C’est un document qui vous explique comment vous pouvez faire des interfaces riches, parce que le R dans ARIA, c’est pour Riche. ARIA vous permet de faire des Applications Riches sur Internet et Accessibles.

Il y a quelque chose qui est très, très intéressant dans ce document-là, ce sont les designs patterns. Vous avez une trentaine de designs patterns qui sont des éléments d’interface. Ils vont vous expliquer comment faire des éléments d’interface accessibles.

Les designs patterns contiennent des éléments très simples comme le lien, si vous ne pouvez pas faire un vrai lien pour une raison ou pour une autre, ou les checkbox ou les boutons radio. Ils contiennent également des choses plus compliquées, comme la vue en arborescence, par exemple.

Qu'est-ce que ce document explique ? Je vais prendre, par exemple, les modales. C’est bien ça, les modales, on en met partout. Pour chaque designs pattern dans ce document, vous avez d'abord un exemple. Ensuite, on vous dit comment votre bout de JavaScript doit réagir selon les touches sur lesquelles on appuie au clavier. Et enfin, on vous dit aussi quelles propriétés ARIA vous devez ajouter sur vos éléments HTML.

Là, je vous montre le paragraphe keyboard interaction de la modale. Quand on appuie sur TAB, il faut que ça fasse ça. Quand on appuie sur Shift Tab, il faut que ça fasse ça. En général, il faut que ça déplace le focus d’une manière prévisible. Quand on appuie sur Échap, ça doit fermer la fenêtre modale. Le but est que toutes les modales de tous les sites se comportent pareil quand on interagit avec elles au clavier.

Ce que je trouve très intéressant dans ce document, c’est que vous n’avez rien à inventer. Ça vous demande du travail parce qu'en général, il faut écrire du JavaScript en plus pour observer ce qui se passe au clavier pour ne pas dépendre que de la souris. Mais c'est hyper concret. Vous n'avez pas besoin de vous demander : "Il faudrait que je mette ci ou que je mette ça ? Je n'en sais rien."

J'aime beaucoup ce document et je le partage beaucoup à mes collègues développeurs quand j'arrive sur un projet. Cela permet de prendre des bouts d'interface qui existent déjà et de ne pas devoir réinventer la roue. En fait, vous avez le plan de la roue, vous avez juste à la coder. "Juste". Vous avez à la coder, mais vous n'avez pas du tout de travail de conception ou de réflexion qui peut prendre du temps, pour un résultat qui risquerait de perdre utilisateurs qui en ont besoin.

Souvenez-vous, donc, de ce document : ARIA Authoring Practices. Il est vraiment hyper intéressant.

Voilà, c'était JavaScript versus accessibilité.

Parfois, je parle d'accessibilité et les gens me disent : "C'est trop difficile, j'arrête, c'est trop compliqué pour moi".

Demandez-vous : est-ce que les internautes qui arrivent sur votre site complètement inaccessible avec un lecteur d'écran vont, eux, trouver cela trop difficile aussi ? Essayez de vous mettre à la place de l'autre.

Une variante de la même idée. C'était un apéro avec d'autres parents d'élèves où j'explique que je me suis lancée à mon compte, que je travaille dans le Web, que je fais de plus en plus d'accessibilité. Et là, spontanément, la nana en face de moi me dit : "L'accessibilité, c'est chiant".

Mets-toi à la place des autres, tu es aveugle et ton site ne marche pas. Tu ne peux pas utiliser ton service public, tu ne peux pas déclarer tes impôts. C'est plus chiant que de devoir ajouter 2-3 attributs ou d'écrire 15 lignes de JavaScript.

Donc, voilà, celle idée-là, je ne l'aime pas trop. Mais hélas je l'entends souvent dans plusieurs saveurs différentes.

Je concède que parfois, ça peut être un peu touchy, un petit peu délicat de faire des interfaces pleinement accessibles. Là, sur la capture d'écran, je vous ai mis le début, et juste le début, de comment créer une vue en arborescence accessible au clavier.

OK, c'est compliqué. Mais une vue en arborescence, c'est une interface compliquée.

Et il faut quand même avouer que des vues en arborescence, on ne code pas ça tous les jours. En revanche, ce qui est hyper courant, ce sont les formulaires, les liens, les menus de navigation, les images, les vidéos… Pour ces éléments-là, on n'a pas d'excuse, en tant que développeur, de ne pas prendre les quelques minutes de plus pour les rendre accessibles.

Il faut quand même reconnaitre qu'un formulaire à rendre accessible, ce n'est pas hyper compliqué. En 2021, je vois encore, en prod, des nouveaux sites qui sortent où les label ne sont pas reliés à leur input, alors que ça demande une vingtaine de caractères, et que 95 % des frameworks existants le font à votre place.

Il y a des choses que je pardonne. Par exemple quand j'arrive sur un site qui n'est pas utilisable au clavier, parce que ce sont des choses qu'on ne peut pas forcément deviner si l'on n'a pas été formé.

Mes les attributs id et for sur les input et les label, c'est la base du HTML. Franchement.

Et regrouper les champs semblables dans un fieldset, notamment, par exemple, quand on a des boutons radios : c'est pareil, ce n'est pas sorcier. On le voit une fois, ça ne coute rien de le refaire après. Surtout que cet élément qui sert à regrouper les champs est souvent déjà présent… sous forme de div.

Remplacer un div par un fieldset, ne porte pas forcément à conséquence, sauf peut-être sur Google Chrome quand on veut faire du grid. Et, dans ce cas-là, on peut mettre des attributs ARIA sur le div au lieu de mettre un vrai fieldset. Mais, déjà, il faut savoir que le fieldset, existe.

Je veux bien croire qu'une vue arborescence, ce soit compliqué et impossible à deviner. Mais c'est pour ça qu'il y a des gens qui ont fait le travail de réflexion à notre place avant.

Les formulaires, c'est pareil, il y a des gens qui ont fait le travail à notre place. Et même, le navigateur fait à votre place le travail de l'accessibilité. Tout ce que vous avez à faire, c'est dire ce libellé, il est relié à cet input. Et ça prend une minute, même pas. On pourrait faire un concours de qui ajoute le input/for le plus rapidement possible, peut-être que ça marcherait.

Donc quand même, s'il vous plait, faites au moins la base, histoire que vous ne perdiez pas trop de karma quand un utilisateur en situation de handicap arrive sur votre site, pour qu'il ne soit plus en situation de handicap justement.

Puisqu'on a parlé de trucs basiques, parlons maintenant de trucs pas basiques. Quelqu'un m'a dit que comme ils allaient faire du service public, il ne pouvait pas utiliser son framework JavaScript préféré pour faire une Single Page Application, SPA.

En fait si, tu peux utiliser ton framework JavaScript.

Je suis allée voir les quelques frameworks JavaScript que je connais, parce que je suis un petit peu une bille en frameworks JavaScript. Honnêtement, je n'y connais pas grand-chose.

React, Vue, Angular… ils ont une section de leur documentation qui est dédiée à l'accessibilité. Ce qui m'embête un peu, c'est que d'habitude, l'accessibilité est dans la section "Avancé" de la documentation. Et dans cette section "Avancé", ils vous expliquent qu'il faut mettre un for et un id sur les labels pour les relier à leur input. Mais ça, ce n'est pas "avancé".

Et souvent, ils vont vous donner certains points à garder en tête pour faire des SPA accessibles. En gros, sur une SPA, Single Page Application, vous pouvez faire des applications accessibles, mais il faut être vigilant et, idéalement, le prévoir dès le début du dev. En effet, vous allez devoir gérer beaucoup de déplacements de focus, que vous n'auriez pas forcément à gérer sur une application classiquement générée côté serveur. Quand vous changez de page, vous devez déplacer le focus en début de page pour que les utilisateurs qui ne voient pas ne soient pas complètement paumés.

Ça demande un petit peu plus de travail. Mais oui, si tu veux utiliser ton framework préféré, il faut bosser un petit peu après.

Je vous présente une ressource que j'aime bien, qui vient d'Orange. Ce sont les guidelines d'accessibilité sur Orange. Ils ont notamment une page pour les Single Page App, que je vous présente ici. Je l'envoie souvent aux développeurs de JavaScript pour leur expliquer ce qu'ils ont à faire.

Donc, qu'est-ce que vous voyez ? En gros : pensez à mettre à jour le titre de la page, même si la plupart des frameworks le font déjà tout seuls ; précisez à l'utilisateur qu'il change de page ; déplacez le focus ; faites du HTML propre ; gérez l'historique… etc.

Cette page-là est très cool. Elle n'est pas très longue et c'est bien de l'avoir en tête dès le début du développement, pour éviter la grosse désillusion quand l'audit arrive en fin de développement et qu'il faut tout recoder.

J'ai perdu du karma pas mal comme ça en disant : "Il est joli ton site, mais je n'arrive pas du tout à m'en servir au clavier. Je crois que tu vas devoir rebosser deux semaines dessus. Désolée". Mais pas tellement désolée non plus.

Parfois, il y a des gens à qui j'explique tout cela, ils sont très enthousiastes et ils me disent : "C'est trop bien. J'ai compris. Je vais mettre des ARIA labels partout, en plus des textes alternatifs, en plus des descriptions pour bien tout expliquer. Et ça sera bien accessible".

Et en fait, après, ce n'est plus accessible du tout.

Comment cela se passe ? Ils font une image avec un texte alternatif : super ! Ensuite, ils ajoutent aria-label="image". Oui mais non, parce que du coup, ça ne marche plus. Enfin, ça marche. Mais le lecteur d'écran va juste dire "image" au lieu de mettre le beau texte alternatif qui avait été prévu au début.

Une image que j'aime bien compare aria-label à une grosse pelleteuse qui enterre tout le reste. Donc, du calme.

La documentation de ARIA le mentionne directement : il vaut mieux ne pas mettre de ARIA, plutôt que de mettre du mauvais ARIA. Dans une grande majorité des cas, vous n'avez pas besoin d'ajouter des attributs ARIA sur du HTML standard. Pour un formulaire, à moins que vous vouliez faire du CSS grid sur un élément fieldset, vous n'avez pas besoin d'ajouter du ARIA dans l'immense majorité des cas.

Note de transcription : en fait si, il faut quand même ajouter du ARIA dans la majorité des formulaires. Notamment pour décrire le format attendu dans un champ s'il est spécifique, ou pour relier les messages d'erreur à leur champ. Ce qui est vrai en revanche, c'est que dans l'immense majorité des cas, il n'y a pas besoin d'ajouter de aria-label.

On arrive à la fin. Pour résumer, si vous voulez partir avec des idées qui ne soient pas complètement pétées :

• L'accessibilité, ça commence avec du bon HTML sémantique. Mais cela concerne aussi le JavaScript, le CSS et, au-delà de la technique, le design (avant la technique, du coup), et les contenus. Tout le monde, tous les métiers sont impliqués dans l'accessibilité.
• Quelque chose d'autre que je veux que vous reteniez, surtout si vous ne pratiquez pas l'accessibilité au quotidien : l'accessibilité, ce n'est pas obligé d'être compliqué. Il y a pas mal de bon sens. Il y a deux ou trois choses à savoir pour faire déjà 80 % du boulot. Et les derniers 20 %, effectivement, on peut les laisser à quelqu'un qui a été spécifiquement formé là-dessus. Mais si vous commencez dès le début avec les choses simples, ce sera déjà pas mal.
• Et finalement : Opquast, ça contient de l'accessibilité, mais pas que. Et à l'inverse, Opquast ne va pas toujours suffisamment loin dans l'accessibilité si vous avez des obligations légales précises.

Aussi, voici quelques ressources que je veux que vous gardiez sous la main :

• le RGAA,
• les règles Opquast,
• le document ARIA Authoring Practices
• les ressources Orange Digital Accessibility

Ces deux dernières ressources sont hyper concrètes et très intéressantes.

Merci de votre attention et je vous retrouve sur Slack dans quelques instants. Et on arrête l'enregistrement.