Transcription textuelle de « Accessibilité, je t’emmènerai jusqu’au bout du back », ma conférence pour Paris Web 2017

Un voilier sur la mer
Image d’introduction de ma conférence : un voilier sur la mer – © Julie Moynat

Transcription textuelle de ma conférence pour Paris Web le 5 octobre 2017

En début d’année 2017, Alex Bernier, le directeur de l’association BrailleNet m’a contactée afin que je réalise l’intégration pour la refonte du site de BrailleNet sous WordPress. J’ai eu de la chance car Capgemini a accepté de prendre ce contrat peu commun par rapport à nos projets habituels.

Bien sûr, le site devait être accessible côté front. Et, il se trouve qu’au moins un des utilisateurs principaux est non-voyant ; le site devait donc l’être aussi côté back, un minimum. Même si celui-ci rédigera occasionnellement des articles, il faut qu’il puisse administrer le site et c’est toujours mieux quand on peut être autonome.

Je vais faire un petit tour d’horizon des problématiques rencontrées :

  1. Une petite diapo sur le front-office (plutôt design)
  2. Un tour dans le back-office
    1. Le back-office de WordPress natif
    2. Deux extensions de renom : ACF et Polylang (un peu front et beaucoup back)
  3. Les extensions de formulaires (front et back)

Front-office : Un design pensé accessible en amont

Le nouveau site de BrailleNet est un site assez simple dans sa conception. Quand le designer m’a présenté les maquettes, je n’ai pas vu d’élément majeur qui pourrait poser problème comme la mise en place de scripts par exemple, en dehors du menu déroulant.

Le ratio de contraste des couleurs a bien été vérifié par le designer en amont.

On a fait des points entre designer et intégratrice pour expliquer les maquettes et évaluer la faisabilité technique. Certains points d’accessibilité ont été soulevés :

  • Le menu déroulant posait problème sur la maquette car il se déroule au survol et il devait se dérouler sur 2 niveaux. Cela posait problème pour l’affichage du 2ème niveau qui aurait pu se retrouver masqué selon certaines tailles de fenêtre. On a donc mis un seul niveau déroulant et un petit bloc dans les pages parentes qui liste les sous-pages.
  • Le bloc prévu dans l’en-tête pour changer de langue affichait initialement uniquement un lien pour passer en anglais avec le libellé « EN » affiché. Ce n’était pas suffisamment clair et j’ai donc conseillé de mettre le libellé « Langue » devant et d’ajouter la langue active : « FR ».
  • Les effets au survol qui ajoutaient un fond de couleur et un icône par dessus le texte n’ont pas été mis en place au focus clavier pour ne pas empêcher la lecture.
  • Le lien « Aller au contenu » était bien visible ; cependant, en mobile, il se retrouvait dans le menu burger. Il en a donc été sorti puisqu’il n’était, sinon, pas facilement accessible.

Un petit tour dans le back-office

Comme je le disais en introduction, il faut que mon utilisateur aveugle puisse contribuer dans le back-office. Pour cela, il faut que ce dernier soit un minimum accessible, plus qu’un minimum d’ailleurs. Afin de l’aider à contribuer, j’ai entrepris de créer une documentation dans laquelle il fallait donc que j’explique ce qui se passe dans le back-office pour quelqu’un qui voit mais aussi pour quelqu’un qui ne voit pas. Ça m’a amené à tester le back-office de WordPress. Dans l’ensemble, ça allait plutôt bien mais j’ai rencontré quelques soucis comme sur la page de contribution des menus, par exemple.

Back-office WordPress : Les menus

La page de contribution des menus est assez complexe parce qu’elle est organisée entre des onglets, des accordéons et des colonnes mais on n’a pas de hiérarchie de titres, par exemple.

En haut de page, j’ai mes onglets « Modifier les menus » et « Gérer les emplacements ». Quand on voit bien, on sait que « Modifier les menus » est l’élément actif parmi ces deux onglets sauf qu’en fait, dans le code, c’est juste deux liens côte-à-côte donc on n’a aucunement cette information quand on ne voit pas l’écran. C’est un premier point qui est un peu gênant.

Ensuite, on a notre organisation en deux colonnes. Dans ma colonne de gauche, j’ai toute la liste des éléments que je vais pouvoir ajouter à mon menu et dans ma colonne de droite, j’ai les éléments que j’ai ajouté dans mon menu. Sauf que, quand je vois mon écran, je sais très bien que quand je coche un élément et que je clique sur « Ajouter au menu », ça part dans la colonne de droite. Si je ne vois pas, je ne sais pas du tout où ça va. Comme je n’ai pas de titre à mes colonnes, c’est assez compliqué de passer de l’une à l’autre quand on navigue au clavier, il faut tout re-déplier donc c’est un peu compliqué.

J’ai également des accordéons dans la colonne de gauche et dans celle de droite. Dans la colonne de gauche, le lecteur d’écran me dit bien que ce sont des accordéons quand j’arrive dessus donc il me dit que je peux les déplier, etc. En revanche, dans la colonne de droite, j’arrive sur mon lien, je sais que c’est un lien mais je ne sais pas que ça déplie la configuration de mon élément de menu. Il faut le deviner quand on ne voit pas l’écran. Je l’ai expliqué dans ma documentation et j’ai fait un ticket au cœur de WordPress pour leur suggérer d’améliorer cet écran pour qu’il soit plus accessible.

On a quand même un truc bien dans cet écran, c’est qu’on peut ordonner les éléments de menus par glisser / déposer. Cette fonctionnalité ne fonctionne qu’avec la souris mais j’ai une alternative pour déplacer mes éléments avec des petits liens « Déplacer un cran vers le haut », « Descendre d’un cran ». C’est un peu plus chiant mais, au moins, on peut le faire donc c’est assez cool !

Back-office WordPress : Les widgets

Je me tourne vers l’écran des widgets. Quand je l’ai mis dans ma documentation au début, je me suis dit : en fait, c’est con parce que je ne peux rien faire avec mon clavier. Je navigue avec la touche de tabulation dans ma page et je n’atteins rien. Du coup, j’ai fait un ticket aussi au cœur de WordPress. On m’a dit qu’en fait, dans le petit accordéon « Options de l’écran » qu’il y a tout en haut des pages de l’administration de WordPress, il y a un bouton « Activer le mode accessibilité ». Il faut le savoir ! D’autant plus que, ce bouton « Options de l’écran », en fait, personne ne le voit jamais ; c’est formidable !

Il faudrait juste que cet écran de widgets soit accessible de base ; ce serait quand même la meilleure solution. Mais bon, comme c’est un peu compliqué à mettre en place car il faudrait tout refaire, il faut au moins que ce bouton soit accessible directement sans être caché dans un accordéon. Ce serait quand même plus facile.

Par ailleurs, la semaine dernière, Gaël Poupard, que vous connaissez sans doute car il a fait quelques conférences ici, a fait une présentation sur le Customizer de WordPress. J’ai alors découvert qu’on pouvait configurer les widgets, les menus, etc. via ce Customizer. Dans l’administration de WordPress, on le retrouve dans le menu à gauche dans « Apparence » puis « Personnaliser ». Au clic, ça ouvre la page en front-office en deux colonnes : à gauche, le Customizer où vous pouvez faire tous les réglages, à droite, vous voyez votre site qui se met à jour en temps réel quand vous faites les réglages. Ça fait encore une alternative accessible pour contribuer les widgets donc, finalement, on s’en sort bien.

Back-office WordPress : La contribution de contenu

La contribution de contenu, globalement, pour les pages et les articles, ça se passe plutôt bien. Il y a juste un truc qui m’a fait un petit peu « bugger », si on peut dire. J’essayais d’expliquer comment on peut modifier l’URL de la page. Donc, en naviguant au clavier, j’étais dans mon champ « Titre » et j’ai fait TAB pour aller à l’élément focusable suivant et je suis arrivée dans mon bloc WYSIWYG. En fait, juste entre les deux, j’avais quand même pas mal de choses. Et, mon permalien, pour le modifier, je suis obligée de faire MAJ + TAB (retour arrière dans la navigation clavier). Donc, là, c’est pareil, si on ne voit pas l’écran, on ne peut pas savoir que c’est là et donc deviner qu’il faut faire MAJ + TAB pour aller le trouver. C’est un petit peu gênant.

Back-office WordPress : Les médias

On a un dernier écran dans le back-office de WordPress qui m’a un peu posé problème, c’est celui des médias. Cet écran est un peu compliqué, même pour la communauté accessibilité de WordPress. Ce qu’on m’y a dit est que cet écran devrait être refondu totalement parce qu’il n’est pas du tout accessible donc, c’est quand même problématique.

Mon premier problème, ç’a été qu’en le testant avec le lecteur d’écran NVDA, je me suis rendue compte que je ne pouvais pas cocher les images. C’est un truc tout bête et, du coup, je ne peux pas ajouter d’image dans mon article quand j’utilise NVDA. J’étais bien embêtée. J’ai fait à nouveau un ticket à la communauté WordPress où on m’a dit qu’il faut activer le mode manuel du formulaire dans NVDA avec INSER + ESPACE. Là, effectivement, on peut cocher les images. Le soucis qui reste est que, chaque fois qu’on coche une image, on a le focus qui est déplacé dans la colonne de droite pour modifier les textes alternatifs etc. de son image. À chaque fois qu’on coche une image et qu’on veut en ajouter une autre, on est obligé de refaire toute la navigation donc c’est horrible quand on navigue au clavier.

Extensions WordPress : ACF – Advanced Custom Fields

On va faire un petit tour dans les extensions où, là, ç’a été carrément moins cool que le back-office WordPress natif.

Pour ce site, on a utilisé ACF (Advanced Custom Fields) qui est une extension qui permet d’ajouter des champs dans le back-office pour ensuite les afficher dans le thème, un peu comme on veut. On m’a toujours dit que c’était l’extension géniale, super facile à utiliser dans le back-office et dans le thème. Oui, effectivement, ç’a été super facile sauf que quand j’ai dû faire ma documentation, je me suis rendue compte qu’il y avait des petits problèmes, quand même, dans le back-office. Par exemple, j’ai une liste de boutons radio « Type de bloc ». Normalement, quand on a une liste de boutons radio, c’est encadré dans une balise <fieldset> puisque c’est un groupe de champs et mon libellé commun à tous ces boutons radio, c’est une balise <legend>. Dans ACF, je pense qu’ils ne connaissaient pas ça et donc, il n’y a pas. Par conséquent, quand j’arrive sur mes boutons radio, ça ne me dit pas à quelle question je réponds. Si je ne vois pas l’écran, je ne sais pas à quelle question je réponds quand j’active un bouton radio. Une solution que j’aurais pu mettre en place mais je n’y ai pas pensé sur le moment, c’est de reprendre le libellé du groupe dans chaque <label>. C’est un peu redondant mais au moins ça permettrait de savoir à quelle question on répond quand on arrive sur un bouton radio.

On a également des éléments qui ne s’affichent qu’au survol. Là, on est un peu coincé quand on utilise le clavier puisque ça ne fonctionne qu’avec la souris. Par exemple, quand on utilise ACF Pro, on peut répéter des blocs de champs à volonté dans une page et les boutons « + » et « − » pour en ajouter ou en supprimer ne s’affichent qu’au survol. Je les ai donc affichés tout le temps via une surcharge en CSS. Quand j’ai dit à ACF que ça posait problème en navigation clavier, ils m’ont dit que d’un point de vue design, ils ne pouvaient pas faire ça. Je leur ai dit que, si ça gène pour le design, ils pouvaient regarder ce que fait WordPress sur les pages des listes de contenu parce que ça s’affiche effectivement au survol mais également au focus et qu’ils pouvaient donc s’en inspirer pour essayer de reproduire ce même comportement. C’était au mois de mai-juin. Ils m’ont dit qu’ils allaient le prendre en compte mais je n’ai jamais rien vu pour l’instant.

Pour les <fieldset>, j’ai oublié d’en parler, je leur ai demandé également s’ils pouvaient faire une correction mais ils m’ont dit que pour des raisons de rétro-compatibilité, ils ne pouvaient pas le prendre en compte car ACF est parfois utilisé dans le front-office également. Donc, en fait, ils en ont rien à faire de l’accessibilité et c’est formidable. (J’ai été un peu brute sur cette phrase, j’espère qu’il n’en ont pas vraiment rien à faire mais c’est le ressenti que j’en avais dans les échanges.)

J’ai eu un autre problème avec ACF : les liens et les boutons sans intitulé. Quand ils sont accessibles au clavier, on se rend compte que si on utilise un lecteur d’écran, il ne peut pas nous dire à quoi sert ce lien ou ce bouton. C’est déjà bien, on arrive à y aller au clavier mais si on ne sait pas ce qu’il fait, on ne va pas aller très loin. Au départ, je ne voulais faire que des corrections en CSS donc j’ai fait un truc un peu sale mais qui marche normalement dans la plupart des lecteurs d’écran : j’ai utilisé la propriété content en CSS pour mettre mon libellé. Avec le recul, je me dis que j’aurais mieux fait de le faire en JavaScript pour mettre directement le libellé dans la balise.

Extensions WordPress : Polylang, dans le back-office

J’ai aussi utilisé Polylang. Ç’a été autre chose. On l’a utilisé pour gérer le multilingue dans le site puisqu’il devait être disponible en français et en anglais. Je n’ai trouvé qu’un seul problème d’accessibilité. J’ai fait un ticket au développeur et il l’a corrigé très rapidement. On a très bien échangé. À la fin, il m’a même dit de ne pas hésiter à lui reporter d’autres problèmes d’accessibilité que je pourrais rencontrer. Des retours comme ça, j’en voudrais à chaque fois que je fais des tickets sur l’accessibilité. Malheureusement, ça n’arrivera jamais mais merci au développeur de Polylang parce que c’est vraiment agréable ce genre de retour.

Pour vous expliquer le problème que j’avais, c’est que le bouton pour afficher toutes les langues qui se trouve dans la barre d’outils de WordPress tout en haut n’était pas accessible au clavier alors que les autres éléments natifs de WordPress fonctionnent de façon à pouvoir y aller au clavier. Je ne pouvais donc pas filtrer mes langues dans le back-office. Ce n’était pas si grave que les problèmes qu’on pouvait avoir dans ACF et ç’a été corrigé vraiment rapidement donc c’était vraiment super !

Extensions WordPress : Polylang, dans le front-office

Dans le front-office, Polylang, ç’a été génial aussi parce qu’on est vraiment libre de produire le code qu’on veut. Donc, le code le plus accessible possible, on peut le faire. Par exemple, pour ma barre de langue, j’ai pu utiliser les attributs hreflang pour indiquer la langue de mon lien. J’ai pu utiliser l’attribut lang pour indiquer la langue de mon contenu à l’intérieur de mon lien. J’ai aussi et surtout pu masquer aux lecteurs d’écran les « FR » et « EN » qui ne sont pas terribles en termes de restitution et mettre à la place un texte qui sera restitué complètement : « Français » et « English ». Bien sûr, on indique autrement que par le changement de forme et de couleur que le français est la langue active donc on indique que c’est la langue actuelle. On l’indique également dans l’attribut title car ça peut toujours servir aux utilisateurs de souris. (Voir l’extrait de code dans le diaporama – diapositive 11)

Les formulaires : front et back, un champ de bataille

On va passer aux formulaires. Les formulaires, comme je le disais en introduction, ç’a été un peu compliqué. Il y a beaucoup d’extensions de formulaires pour WordPress. J’en ai fait un peu le tour et c’est là où j’ai vraiment déchanté sur la réalisation de ce site. En effet, WordPress ne fournit pas la création de formulaires nativement donc on est obligé d’utiliser une extension. D’abord, j’aimerais qu’on se mette d’accord sur ce qu’est un formulaire accessible en front, a minima.

  • La base, c’est que tous les champs ont une étiquette : généralement la balise <label> qu’on associe au champ via son attribut for dont la valeur est l’identifiant du champ. Quand l’utilisateur arrive en focus sur le champ avec son lecteur d’écran, ça lui lit le libellé et il sait ainsi ce qu’on attend de lui dans ce champ de formulaire.
  • Ça, on l’a vu côté ACF : les groupes de champs sont regroupés correctement. Ma liste de boutons radio, je l’encadre dans une balise <fieldset> avec une balise <legend> pour libellé commun.
  • Et, quelque chose qui est très souvent oublié, on va rattacher, bien sûr, les messages d’erreur à leur champ. Quand j’arrive sur mon champ et qu’il est en erreur, ça doit me lire à la fois son libellé et le message d’erreur pour que je puisse appliquer la correction. Pour ce faire, on utilise l’attribut aria-describedby qu’on met sur le champ et sa valeur est l’identifiant du message d’erreur. Ça nécessite un peu de développement car il faut mettre un identifiant unique sur chaque message d’erreur. Il faut aussi le savoir parce qu’ARIA n’est pas quelque chose qui est très connu par défaut puisque c’est une spécification vraiment à part du W3C.
  • Généralement, on va vous demander, en accessibilité, d’indiquer dans la balise <title> de votre page que le formulaire contient des erreurs. Ce n’est pas forcément possible. Quand on utilise un CMS, on n’a pas toujours la main sur ça. L’idée serait de pallier ce problème en affichant un message d’erreur global en haut du formulaire et on lui met un attribut role="alert" comme ça, il sera lu quand la page sera rechargée et on saura qu’il y a des erreurs dans le formulaire. Si vous voulez en savoir plus, voici le lien de l’excellent guide de l’intégrateur pour des formulaires accessibles par la DINSIC. Ils ont fait du super bon boulot et c’est en français donc vous n’avez plus d’excuse pour ne pas faire des formulaires accessibles après ça.

Les formulaires : la folie des extensions

Pour en revenir aux extensions de formulaire que j’ai pu tester côté WordPress ; il y en a pas mal.

J’ai testé :

  • Contact form 7 + Accessible defaults qui sont deux extensions qui fonctionnent ensemble puisque Accessible defaults est l’extension qui va corriger quelques problèmes d’accessibilité de Contact form 7. Malheureusement, ça fait un moment qu’elle n’a pas été mise à jour et ce n’est pas vraiment parfait.
  • Formidable forms
  • Ninja forms
  • Caldera forms
  • Form Maker by WD : celui-là est très drôle car il a une jolie baseline qui dit user-friendly drag & drop Form Builder Plugin donc il est génial pour les utilisateurs parce qu’il utilise le glisser-déposer… (Gros points de suspension)
  • Forms – Form builder and Contact form
  • Visual Form Builder

J’ai vu dans le front-office

Dans toutes ces extensions, j’ai rencontré des problèmes. Notamment, pour la partie front-office :

  • Il n’y en a aucune qui gère les balises <fieldset> et les balises <legend>. Donc là, pour les boutons radio et les checkbox, c’est mort !
  • Il n’y a qu’une seule qui attache les messages d’erreur à ses champs, c’est Caldera forms. La raison est qu’au départ, on devait utiliser cette extension, jusqu’à s’apercevoir que le back-office n’était pas du tout utilisable au clavier. J’ai donc eu le temps de faire un ticket pour leur demander de faire ça en correction. Ils l’ont pris en compte très rapidement donc, encore une fois, ce retour a été très positif. Mais, j’ai dû arrêter là mes tickets puisqu’on ne l’a finalement pas utilisée.
  • On a également des messages d’erreur qui s’affichent à la volée pour Ninja Forms. C’est embêtant parce que, de toute façon, les messages d’erreur ne sont même pas rattachés à leurs champs donc, déjà qu’en termes d’UX, c’est pas bon mais en terme d’accessibilité, c’est mort. On ne peut pas soumettre le formulaire tant qu’on n’a pas corrigé les erreurs mais on ne sait pas qu’il y a des erreurs donc, bon bah, c’est la merde !
  • Pour la fameuse extension qui est géniale pour les utilisateurs, il se trouve qu’elle fait des champs sans balise <label>. Donc, elle est vraiment géniale !

J’ai vu dans le back-office

Dans le back-office, c’était la fête aussi !

  • La plupart des extensions ne respectent pas les standards de WordPress pour le back-office et ça coince un peu parce que des développeurs ont créé une identité visuelle pour leur extension. Il n’y a pas de soucis avec ça, c’est très bien mais la mettre en place complètement dans le back-office de WordPress et s’abstraire de tout ce qu’il y a autour, ça devient quelque chose de catastrophique. En effet, les développeurs, en général, ne sont pas formés à l’accessibilité. Ils font donc ça comme ils le sentent. Ça a l’air joli mais derrière, ce n’est pas utilisable. Pourtant, WordPress prévoit des standards qui sont pensés pour l’accessibilité donc ça leur enlèverait une épine du pied.
  • On a du glisser-déposer à peu près dans toutes les extensions.
  • On a des pseudo-boutons inatteignables au clavier donc c’est pour ça notamment que Caldera Forms n’a pas pu être utilisé. On peut avoir des balises <img /> qui servent de boutons ou des <div> tout simplement, ça ça se voit beaucoup aussi. À la souris, ça marche mais on ne peut pas prendre le focus dessus donc je ne peux pas configurer mes formulaires au clavier.
  • On a des boutons et des liens sans intitulé, comme on le voyait avec ACF. Si j’arrive à y aller, je ne sais même pas ce que ça fait derrière donc je suis coincée si je ne vois pas l’écran.
  • Il y a aussi Formidable Forms qui a décidé de ne pas traiter l’accessibilité dans son back-office pour les formulaires. J’ai un paramétrage de mon extension qui se fait avec des champs de formulaire mais je n’ai pas de balises <label> associée à ces champs. Donc, si je ne vois pas l’écran, encore une fois, je ne peux pas configurer mon formulaire.

Les formulaires : Gravity forms, extension de rêve ? Le front-office

Face à ce constat, on s’est tourné vers Gravity forms. C’était notre dernier recours car Gravity forms est une extension payante mais on n’avait plus le choix.

J’ai voulu regarder un petit peu ce que ça donnait et je suis allée voir le site de démo de Gravity forms. Le formulaire est dégueulasse, pas du tout accessible. Et j’ai voulu voir le back-office mais il n’y a pas de démo. J’ai dû me fier à des captures d’écran en me disant ça a l’air de respecter les standards de WordPress, ça devrait être pas trop mal. Et puis, pour corriger le front-office, de toute façon, il y a une extension qui est prévue pour ça donc d’après la description de cette extension, ça corrige tout. Ça devrait être bien !

On l’a acheté, on a essayé et je me suis rendue compte qu’il y avait des balises <fieldset> et <legend> pour, notamment, les boutons radio et checkbox donc c’est déjà un bon point puisqu’il n’y en avait aucune qui le faisait parmi toutes les extensions que j’avais testées.

J’ai également un message d’erreur global avec un attribut role="alert" tout en haut du formulaire comme je l’expliquais précédemment. Dans Gravity forms, ça me dit que j’ai des erreurs dans le formulaire et ça me liste tous les messages d’erreur pour chaque champ. À la fin de chaque message d’erreur, j’ai un lien qui m’emmène directement vers le champ en erreur.

Du coup, c’est pas trop mal sauf que quand je veux naviguer dans mon formulaire et corriger toutes les erreurs unes à unes, les messages d’erreur individuels qui se trouvent sous chaque champ ne sont pas rattachés au champ donc ça reste un problème pour corriger les erreurs.

Ce n’est pas parfait mais ça reste la meilleure extension de formulaire que j’ai trouvée d’un point de vue accessibilité dans le front-office.

J’ai fait un ticket pour ce dernier problème à l’extension qui corrige l’accessibilité ; je n’ai pas eu de retour donc je ne sais pas si, un jour, ce sera corrigé. En tout cas, j’ai pu échanger avec un développeur de Gravity forms sur Twitter qui m’a dit qu’ils ont eu un audit d’accessibilité et que, normalement, ils devraient implémenter toutes les corrections des problèmes d’accessibilité directement dans le cœur de leur extension. Ce serait vraiment génial si ça arrivait. Pour l’instant, ce n’est pas fait mais j’ai hâte.

Les formulaires : Gravity forms, extension de rêve ? Le back-office

Plongée en apnée dans le code source

Dans le back-office, j’ai eu des petits problèmes encore… En fait, en naviguant au clavier, je me suis vite retrouvée avec un piège au clavier et même plusieurs en fait. Si vous regardez ce premier lien dans le code :

<a href="#" onclick="return false;" onkeypress="return false;" class="gf_tooltip tooltip_bottomleft tooltip_form_standard_fields" title="<h6>Champs standards</h6>Les champs standards fournissent les fonctionnalités d’un formulaire de base."><i class="fa fa-question-circle"></i></a>

En arrivant sur ce lien là, je ne pouvais plus rien faire ensuite avec mon clavier. Si je ne vois pas l’écran, que je n’ai pas de souris, je n’ai plus qu’à éteindre mon ordinateur en restant appuyée sur le bouton de démarrage. La raison c’est que je pense que les développeurs ont voulu bien faire ; ils ont voulu que ça fonctionne avec le clavier sauf qu’ils ne savaient pas que la touche Entrée du clavier, ça fait un clic. Donc, je n’ai pas besoin d’avoir l’attribut onclick et l’attribut onkeypress qui double. Là, avec l’attribut onkeypress="return false;", ça me désactive mon clavier donc c’est formidable !

Même chose avec le deuxième lien :

<a class="" onclick="DuplicateForm(2);return false;" onkeypress="DuplicateForm(2);return false;" title="Dupliquer ce formulaire" href="#" target=""> Dupliquer</a>

À chaque fois que j’appuie sur une touche de mon clavier quand j’ai le focus sur ce lien, je duplique mon formulaire ; c’est génial !

Option bricolage JS et CSS

Donc, cette fois, j’ai fait du JavaScript pour corriger ; je n’avais pas vraiment le choix.

  • J’ai supprimé tous les attributs onkeypress en JavaScript et puis ça marche. J’ai envoyé ça à Gravity forms. Il faut savoir que les tickets avec eux se font par mails donc je n’ai pas vraiment de suivi. Je leur ai envoyé mon bout de JS en leur disant testez, regardez, ça marche toujours mais, ce n’est toujours pas corrigé.
  • J’ai également des liens qui n’ont pas d’attribut href. En fait, ce ne sont donc pas des liens mais des ancres. Si je n’ai pas d’attribut href sur une balise <a>, je ne peux pas prendre le focus et je ne peux donc pas atteindre ce lien au clavier. En JavaScript, j’ai donc ajouté un attribut href="#" pour corriger au moins la navigation clavier.
  • J’ai encore, comme pour ACF, des éléments qui ne s’affichent qu’au survol donc on les affiche tout le temps en CSS. C’est un peu gênant car ce sont quand même les boutons pour configurer un champ, pour le dupliquer ou le supprimer donc si ça ne s’affiche qu’au survol, je vais avoir des problèmes.
  • Quand je suis dans la configuration de mon formulaire, j’ai une colonne à droite qui liste tous les champs que je peux mettre dans mon formulaire. Ces champs sont découpés en petits accordéons qui ne se déplient pas au clavier. J’ai donc dû tous les ouvrir en CSS mais la colonne est en position fixe que j’ai également dû enlever. Ce sont des petits hacks en CSS mais qui changent tout pour l’utilisateur qui va naviguer au clavier.
  • Comme pour ACF encore, j’ai également des liens qui n’ont pas d’intitulé. Pour des raisons de maintenabilité, je n’y ai pas touché car ces liens ont un attribut title. Cet attribut peut être restitué par les lecteurs d’écran ; parfois en forçant mais ça limite un peu la casse. On a quand même un moyen de savoir à quoi servent ces liens.
  • Enfin, il y encore le glisser-déposer pour ordonner les champs. On ne peut pas lutter. À part se faire accompagner, je ne vois pas ce qu’on peut faire quand on n’utilise que le clavier (oui, dans ma conf, j’ai dit « souris », je me suis trompée !). On n’est donc pas encore à 100% d’autonomie pour Gravity forms même quand on corrige tous les petits problèmes précédents.

Conclusion

En conclusion, finalement, WordPress et ses extensions ne sont pas encore parfaits pour l’accessibilité mais malgré tout, ça progresse. Il y a des gens qui veillent à ce que ça avance. WordPress est pas si mal nativement. C’est peut-être plus au niveau des extensions qu’il y a plus un travail d’évangélisation et de formation à faire. J’ai quelques pistes pour aider à améliorer tout ça à notre niveau si on n’est pas forcément développeur. Si on l’est, on peut même aller encore plus loin.

  • On peut créer des tickets pour améliorer le cœur de WordPress sur make.wordpress.org.
  • On peut rejoindre la communauté accessibilité de WordPress. Tout se passe sur Slack où, le lundi soir, ils font tous des réunions pour faire le point sur tous les tickets du cœur de WordPress, voir qui peut corriger, tester, etc. Même si vous ne voulez pas participer, vous pouvez au moins voir comment ça se passe, c’est assez intéressant et on apprend des choses sur ce qui se passe du côté de WordPress. J’ai essayé de la rejoindre, j’ai participé à quelques réunions et après, c’était assez chronophage donc pour l’instant, je n’ai pas réussi à m’y tenir mais c’est l’objectif.
  • De la même façon qu’on crée des tickets pour WordPress, on va créer des tickets aux développeurs et développeuses d’extensions en leur donnant des pistes de solution et en leur expliquant les impacts utilisateurs. Si on leur dit juste que ça ne fonctionne pas au clavier et qu’en fait, ils n’ont aucune idée qu’il y a quand même un paquet d’utilisateurs qui naviguent au clavier, ils risquent de s’en moquer littéralement.
  • Je n’en ai pas beaucoup parlé mais ACF et Gravity forms sont les deux extensions pour lesquelles j’ai eu des soucis pour créer des tickets parce que leur plateforme de gestion de tickets est la messagerie. On est donc obligé d’envoyer des mails pour lesquels on n’a pas de suivi, on ne sait pas quand ça va être pris en compte, on sait pas si vraiment c’est ouvert de leur côté où s’ils s’en moquent. On ne sait pas si quelqu’un a déjà rencontré le même problème et on ne peut donc pas apporter sa touche personnelle à un même ticket. Ils doivent donc peut-être recevoir dix tickets pour le même problème. C’est donc un peu chiant pour les utilisateurs. J’aimerais bien savoir si les tickets que j’ai envoyé vont être traités ou pas.
    Si vous êtes développeur ou développeuse d’extension, je vous invite à ouvrir votre plateforme de gestion de tickets pour favoriser le suivi et la contribution.
  • Et, bien sûr, j’en ai parlé : respecter les standards de WordPress parce que c’est quand même vachement plus facile d’intégrer l’accessibilité dans son extension quand on suit ces standards.

Merci !

Je vous remercie de votre venue si nombreuse !