L'accessibilité, c'est pas si facile : présentation

Intro

Aujourd’hui, on va parler d’accessibilité numérique, mais pas que, en fait. On va parler de comment on bosse dans l’industrie du développement web. Ça va être un petit coup de gueule ce soir, parce qu’on va se rendre compte que sans trop faire exprès, depuis quoi, 4, 5 ans peut-être, par défaut, on code des sites qui ont une expérience utilisateur au rabais.

Bim ! Voilà, ça c’est nous qui tapons sur le développement web. Non bon, j’rigole.

L’accessibilité numérique, c’est quoi ?

Bon avant de se plaindre sur notre industrie, c’est quoi déjà l’accessibité numérique, rapidement ?

C’est faire en sorte que quand on code des sites, ça marche pour tout le monde, quels que soient les handicaps des gens. Donc ça va être : je tremble, je suis aveugle, je suis tétraplégique, j’ai des troubles de l’attention, etc. Vraiment, on va essayer d’inclure le plus de monde possible. Tous les acteurs d’un projet numérique doivent faire des choses pour ça, en particulier les développeurs, et notablement sur deux points. D’abord, faire en sorte que je puisse naviguer au clavier de façon exhaustive sur mon site ; c’est-à-dire que, si j’ai pas de souris, bah c’est pas grave, je vais quand même pouvoir utiliser tout le site, interagir avec toutes les parties du site. Et ensuite…

Vous devinez ou pas ?

Oui, bien joué ! Un cadeau ce soir au Joker’s pour le gagnan… non ? bref. Merci oui, effectivement, on va aussi supporter les “outils d’assistance”, on appelle ça. C’est faire en sorte que n’importe quel outil d’assistance qu’un utilisateur peut utiliser, par exemple un lecteur audio si je suis aveugle, où je vais naviguer principalement au clavier et où il y aura quelque chose en vocal qui va me dire tout ce qui se passe, on va le supporter au niveau technique, on va devoir coder des choses. Voilà en gros ce que c’est l’accessibilité numérique.

Idée reçue : l’accessibilité, c’est facile

Bon moi je pars d’une idée reçue (en vrai pas si reçue que ça, mais bon on est là pour provoquer un peu), c’est que c’est assez facile l’accessibilité numérique. Bah oui, je rajoute un alt sur ma balise img, je mets quelques attributs aria-quelquechose par-ci par-là, et puis c’est bon c’est OK, je peux arrêter de toucher mon clavier tellement c’est facile. Bon en vrai, c’est pas si simple.

On va prendre un cas vraiment classique du web. Moi je fais du badminton, il y a une appli que j’utilise beaucoup qui s’appelle BadNet (clin d’oeil à tous les badistes ce soir). J’ai pris cet exemple parce que c’est vraiment typique d’une appli qu’un prestatataire de création d’applications sur-mesure peut construire pour un client qui a un budget classique. On va regarder à quel point l’appli est accessible.

Premier truc que je peux faire, c’est un petit audit automatique. Donc ça, vous connaissez peut-être, c’est Google LightHouse.

Wow, super accessible ! Incroyable, Google lui-même nous met le tampon “accessible à 96%“. Génial en fait, c’est facile ! Bon, on va quand même tester un peu ensemble hein… Là, l’idée c’est que je vais naviguer au clavier sur la page de BadNet. J’appuie sur tabulation pour passer d’un élément à l’autre, et je vois si j’arrive à accéder à tout. …Ah bah là on voit que bizarrement, j’arrive pas à accéder à plusieurs liens du menu, dont celui des tarifs. Et puis là, tous les petits onglets concernant le tournoi que je regarde, je n’arrive pas à y accéder. En 10 secondes de test je me rends compte que, ah, peut-être que c’est pas si “accessible à 96%” que ça. Vraiment, il y a la moitié des liens, je sais pas pourquoi, j’arrive pas à y accéder, donc gros point négatif d’accessibilité, on est sur un blocage total.

Une appli web classique est rarement accessible. Mais pourquoi ?

Bon. Le mec de BadNet, il s’est pas dit “regarde gérard, les mecs au clavier, je vais faire en sorte qu’ils puissent pas accéder à la page de tarif haha !“. Non, il s’est juste un peu trompé, ça arrive. Mais comment il a fait pour se tromper ?

Le problème, c’est qu’on utilise une SPA. Une Single Page Application. Vous savez, les applis avec un client JavaScript “lourd”, faites en React, Vue et autres. Les SPA, qu’on met en opposition aux MPA, les Multiple Page Applications. Les trucs qu’on pourrait presque dire à l’ancienne maintenant, faits avec Django et Jinja, Symfony et Twig, Ruby on Rails, etc.

Mais attendez… je vous ai dit “l’accessibilité c’est pas si facile”… mais en fait… “l’accessibilité SPA si facile” !

Oh là là, c’était un complot, c’était un prank ! Il y a une caméra ici, ici…

Le problème des Single Page App

Non, bref, on rigole, mais soyons sérieux deux minutes. C’est quoi le problème avec les SPA ?

Le problème avec les SPA, c’est qu’on a des super pouvoirs. Vraiment, on a ce super pouvoir JavaScript à disposition pour faire absolument tout ce qu’on veut. On peut tout intercepter via JavaScript, on peut tout manipuler en Javascript, voilà, c’est super balèze. Ce super pouvoir il me permet de simuler énormément de comportements classiques du navigateur pour arriver à mes fins.

Comment ça, simuler ? Par exemple, quand je clique sur un lien interne dans ma SPA, je dois gérer plein de trucs.

Potentiellement, j’imite le comportement d’un élément HTML, après faut que je prévienne que je suis en train de charger quelque chose, je fais ma requête réseau, puis je mets à jour ma page moi-même, puis je mets à jour l’URL, le titre, etc, etc. Là je viens de faire une liste qui est déjà assez complète, mais sûrement pas exhaustive. J’ai plein de trucs à faire.

Quand je fais une MPA, petit aparté, qu’est-ce que je dois faire déjà ? Vu que quand je fais une MPA, je respecte les standards du web par défaut, ben…

Voilà, j’ai rien à coder en fait. J’ai pas de framework à utiliser qui recolle les choses pour moi, tout est fait de façon classique.

Bon si je reviens sur ma SPA là, à la limite, simuler, c’est quoi le problème ? On peut bien le faire, non ? Ben, bof. C’est difficile de bien le faire.

Simuler correctement sur le web, c’est pas évident

Je reviens sur la liste des choses à faire de tout à l’heure. E-ce qu’on pense vraiment à faire tout correctement ?

Souvent par exemple, premier truc que je fais, c’est que je veux avoir des liens internes qui vont pas recharger une vraie page. Donc je vais soit intercepter un vrai lien, soit je vais le créer de moi-même. C’est souvent qu’on voit des balises HTML span avec des événements au clic dessus… Mais si je fais ça, est-ce que je pense bien à faire en sorte que le clavier, il est bien supporté ? Ok bon ben je vais mettre un événement keydown, ok. Je vais rajouter un tabindex, ok. Est-ce que je pense bien que je peux faire ctrl + clic sur le lien pour que ça l’ouvre dans un nouvel onglet ? Ah oui bon, je le code… Est-ce que je peux faire clic molette aussi ? Ah ok, je rajoute…

Voilà, vous voyez, la liste est de plus en plus longue. Et il faut que je pense à tous les systèmes d’exploitation, que je pense à tous les cas que je dois simuler.

Autre exemple, prévenir que je suis en train de charger quelque chose. Je vais peut-être mettre un petit élément d’interface qui tourne dans mon appli. Mais est-ce que je le fais pour les lecteurs d’écran ? Le lecteur d’écran lui, si je passe d’une page à une autre, il est notifié par le navigateur vocalement : “chargement…“. Puis il est notifié que le titre de la page a changé. Mais moi, dans ma SPA qui change pas véritablement de page aux yeux du navigateur, si je ne pense pas à gérer ça, dans mon code, la personne utilisant un lecteur d’écran, elle sait pas qu’elle a bougé. Elle sait pas qu’il y a quelque chose qui a changé. Donc là potentiellement, rien qu’à partir de là, j’ai totalement bloqué un accès.

Pareil pour gérer le focus clavier, si je remets pas le focus clavier au bon endroit, c’est assez déroutant.

Et enfin, “gérer le bouton précédent”, on va le voir juste après que ça, c’est pas forcément un problème d’accessibilité, mais c’est à mes yeux un des problèmes majeurs d’expérience utilisateurs qu’on a brisé en tant qu’industrie. BAM. Réveillez-vous ! Allez venez on va manifester.

Bref, reprenons BadNet (je les adore, promis). Finalement pourquoi j’arrive pas à accéder à mes petits liens en haut là ? Ces liens internes faits maisons, on voit qu’ils ont implémenté ça avec des balises a, ok super, ça c’est bien. Mais elles ont pas de href. Ça gêne pas à faire marcher les choses avec une souris, mais faut savoir que dans les standards du web, le navigateur, lui, s’il voit pas de href sur un lien, il enlève ce lien de la liste des éléments focalisables au clavier. Pour régler le problème, j’avais juste à mettre un href="#". Comme ça le système fait maison en JavaScript continuait de marcher, et le clavier, il marchait aussi. Donc pas très compliqué techniquement, mais fallait le savoir.

Autre exemple, là, par rapport au bouton précédent du navigateur. Ça vous arrive je suis sûr, de vous balader sur votre mobile, vous avez pas forcément beaucoup de réseau, vous cherchez des trucs, vous faites “Retour”, et là ça recharge toute la page, ou alors le scroll ne se remet pas bien où il était. Ça, c’est vraiment typique des problèmes des SPA.

Ici on voit qu’il refait des requêtes réseau à chaque fois que je fais retour. Alors qu’un navigateur classique, vraiment, j’ai rien à coder sur mon serveur avec des fichiers HTML classiques, quand je fais retour, il me prend le cache directement, c’est un snapshot instantané. Donc le scroll se remet parfaitement bien, et j’ai pas de problème de “race condition” entre mes données que je charge et le scroll que je veux remettre. Et ça c’est vraiment un problème qu’il y a sur 99% des SPA aujourd’hui, et pour zéro bonne raison. C’est juste qu’on fait pas assez bien les choses.

Qu’est-ce qu’on fait ?

Bon super Manu, tu te plains depuis 10 minutes, mais on fait quoi ?

On se rend compte que pour certains des points que j’ai cités, la finalité c’est qu’on crée des choses de moins bonne qualité, on a un peu cassé le web comme ça, c’est pas la fin du monde mais c’est frustrant, quoi. Et certains autres points, on se rend compte, j’ai juste pas fait attention à certains attributs HTML, et j’ai totalement bloqué l’accès à certaines personnes. Donc là c’est quand même grave.

Choix 1 : arrêter les SPA

Première solution, j’arrête de faire une SPA. En vrai tous ces trucs, là : Symfony, Ruby on Rails, bref, les MPA, ça marche très très bien. Il y a encore plein de sites qui font ça. Je pense que nous tous, on devrait arrêter de se dire par défaut “ouais, faisons une app Vue ou React”, ça résout pas forcément tous les problèmes, on voit que ça en crée facilement, et on voit même qu’on a moins de choses à coder dans une MPA, donc potentiellement si j’ai peu de budget c’est même peut-être la meilleure solution. Et puis si j’ai des intéractions fortes à rajouter, je peux peut-être m’aider un peu avec des outils en plus comme Hotwire ou htmx.

Choix 2 : continuer les SPA, mais mieux s’outiller et mieux se former

Bon super Manu, mais on va pas rester dans l’âge de pierre, nous on veut rester dans le full JS ! Donc dans ce cas là, vraiment, il faut je pense à m’équiper. Aujourd’hui, tous les problèmes que j’ai cités, en réalité, ils sont résolus. C’est pas du tout un problème de faire une SPA. Le problème, c’est qu’on n’est pas forcément conscients des problèmes qu’on crée, à cause de nos fameux super pouvoirs là, on se rend pas compte des bêtises qu’on fait, parce qu’on arrête un peu de suivre les standards.

Mais il y a un peu un renouveau dans le monde des frameworks JS depuis un ou deux ans, où il y a deux frameworks qui ont mis les pieds dans le plat. SvelteKit et Remix sont, un peu comme cette présentation en fait, en mode, “bon les gars, qu’est-ce qu’on fait là, faudrait peut-être qu’on se réveille sur l’expérience utilisateur”. Bref, eux, ils ont fait pas mal fait bouger les choses, je vous laisse découvrir ça de vous-même. L’idée de ces frameworks, c’est de nous aider à abstraire un peu les problèmes de chargement de données, les problèmes d’accessibilité… les régler pour nous, pour que les problèmes soient (en partie) résolus et qu’on arrête de créer des soucis sans faire exprès.

Et puis enfin, l’idée aussi, c’est de se former et se renseigner sur l’accessibilité. Vous pouvez bosser avec moi pour ça, c’est avec plaisir.

Conclusion : un grand pouvoir implique de grandes responsabilités

Comme dirait Ben : (imitation ultra nulle) Un grand pouvoir implique de grandes responsabilités, Peter.

Tout ça pour dire encore une fois, il y a pas de problème à faire des applis 100% JavaScript. Mais il faut vraiment être conscient que dans un tel contexte, c’est super facile de faire des bêtises sans s’en rendre compte. On a vu que le problème n’est pas forcément technique. Il est vraiment organisationnel, il est vraiment humain. Pour faire un produit web il y a tellement de gens différents qui interviennent, chacun avec son lot de connaissances, c’est impossible que tout le monde connaisse parfaitement l’accessibilité. C’est super facile de mettre une erreur dans le code. Sachant qu’en plus, on utilise plein d’outils open-source qui ont eux-mêmes ces problèmes là.

Tout ça pour conclure sur quoi ? Équipons-nous des bons outils, formons-nous un minimum, parce que faut bien penser qu’on crée des sites avant tout pour des utilisateurs, avant tout pour des personnes.