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

Je l’évoquais dans mon article de retour sur Paris Web 2017, j’ai assisté à mon premier Paris Web et en tant qu’oratrice le 5 octobre 2017.

J’ai donné une conférence à propos d’un retour d’expérience sur la réalisation d’un site web sous WordPress qui se devait d’être accessible du front au back. Oui, ce grand oublié de l’accessibilité dans les projets !

Comme 40 minutes de conférence passent vite, j’avais envie de partager avec vous quelques points que je n’ai pas eu le temps d’évoquer.

Par ailleurs, j’ai été un peu perturbée au début de ma conférence par un retardataire (qui est tout excusé ;-)), un sac qui tombe, les micros mal positionnés (d’ailleurs, le tout début de ma conférence n’est pas disponible dans la vidéo) puis par les pancartes qu’on me montrait pour m’indiquer le temps restant (je sais, c’est pour notre bien !).

Je n’ai pas forcément été aussi fluide et dynamique que je l’aurais souhaité. Mais c’est le jeu quand on fait l’une des deux premières conférences d’un évènement et quand on n’est pas très habituée à cette pratique ! Mes « euh » à répétition et mes inversions gauche / droite sans que je m’en rende compte en disent long sur mon aisance en conférence ;-)
(Et puis j’ai dit des p’tits gros mots et je vous prie de m’en excuser. Je m’en vais de ce pas travailler sur le sujet.)

En tout cas, c’était une super expérience. Les conférences étaient toutes traduites en langue des signes, le staff était vraiment super sympa. Et puis, il y avait du monde dans la salle, merci de votre venue ; j’espère que vous avez apprécié et que vous avez appris des choses !

Resituer ma conférence un peu chamboulée au début

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.

J’ai donc fait un petit tour d’horizon des problématiques rencontrées.

• Le front-office avec WordPress – le thème : design pensé accessible en amont (oui, il est possible de concilier les deux) ;
• Le back-office de WordPress ;
  • Les menus ;
  • Les widgets ;
  • La contribution de contenu d’articles ou pages ;
  • Les médias ;
• Les extensions pour WordPress ;
  • Le cas ACF (Advanced Custom Fields), malheureusement plutôt négatif côté back ;
  • Le cas Polylang, heureusement positif côté front et back ;
• Les formulaires : front et back, un champ de bataille ;
  • Faisons le point sur ce qu’est un formulaire accessible ;
    Notes :
    • J’ai proposé de mettre un attribut role="alert" sur le message d’erreur global en haut du formulaire. On peut aussi lui préférer un attribut tabindex="-1" pour y placer le focus en JavaScript après soumission du formulaire et apparition du message. Cela permet aussi d’avoir le focus plus proche des champs du formulaire qu’il faudra corriger (au lieu de naviguer à nouveau dans toute la page après un rechargement).
    • Peu après, lors du 24e séminaire AccessiWeb, j’ai découvert qu’il était désormais permis de regrouper des champs comme avec un fieldset / legend mais avec des attributs ARIA en remplacement (cf. la partie sur le test 11.5.1). Cette technique pourrait servir à ACF avec le problème de rétrocompatibilité que j’évoque dans ma conférence.
  • La folie des extensions ;
  • Gravity Forms, extension de rêve ? Tour d’horizon du front et du back.

Pour finir, dans ce projet, je me suis retrouvée honteuse d’avoir proposé des extensions normalement géniales pas si géniales pour tout le monde ; mais il n’y a bien souvent pas d’alternative.

Alors, je me suis mise à faire des tickets. J’ai été très contente des réponses apportées par la communauté accessibilité de WordPress même s’ils manquent de moyens pour corriger les tickets et que certaines corrections demandent tellement de travail qu’elles ne peuvent pas être prises en compte rapidement. Les échanges, par tickets publics, avec les développeurs de Polylang et Caldera forms ont été géniaux.

En revanche, pour les extensions comme ACF ou Gravity forms où ils n’utilisent pas de plateforme de gestion des tickets et où il faut les contacter par e-mail, les échanges n’ont finalement abouti nulle part pour le moment. J’ai eu vraiment la sensation qu’ils se moquaient totalement que leur extension pose un gros problème aux personnes handicapées et à toutes celles qui naviguent au clavier ; même si ce n’est sans doute pas le cas. Il leur faut certainement du temps pour corriger certains points mais l’absence de possibilité de suivi de ses demandes ne laisse pas très optimiste ; d’autant plus quand on donne la solution pour corriger le problème.

L’accessibilité web est encore loin d’être une évidence et une priorité mais ça progresse grâce à des personnes bienveillantes comme la communauté accessibilité de WordPress ou le développeur de Polylang ou des extensions améliorant l’accessibilité d’autres extensions.

Merci à elles et à eux !

Complément d’information autour de ma conférence…

…parce que le temps manquait !

Le référentiel CMS ou ATAG pour évaluer l’accessibilité d’un back-office

Suite au retour de Florian Sanders et Sylvie Duchateau sur ma conférence, je me rends compte que je n’ai pas parlé de ATAG (Authoring Tool Accessibility Guidelines) et du référentiel CMS réalisé par la DINSIC. Cela aurait bien mérité un petit mot mais ça m’est sorti de la tête ! Merci Florian et Sylvie de le rappeler ;-)

Dans les questions, à la fin, j’ai répondu que je n’avais pas audité le back-office de WordPress avec le RGAA (Référentiel Général d’Accessibilité pour les Administrations). En effet, si le RGAA n’est pas l’outil en tant que tel pour auditer l’accessibilité d’un back-office de CMS, il est malgré tout le premier critère du référentiel CMS. Le respect de la norme WCAG (Web Content Accessibility Guidelines), sur laquelle est basé le RGAA est nécessaire pour respecter la norme ATAG, sur laquelle est basé le référentiel CMS.
Certains éléments ne peuvent qu’être communs comme la construction d’un formulaire, la structuration de l’information dans une page, les interactions clavier avec des boutons, etc. Mais il y a un certain nombre d’autres critères à prendre en compte pour, notamment, aider les contributeurs et contributrices à la production de contenus accessibles.

Je n’ai effectivement pas fait d’audit du back-office de WordPress ni via le RGAA ni via le référentiel CMS. Je souhaitais surtout que les utilisateurs et utilisatrices aveugles puissent l’utiliser un minimum. Il s’agissait notamment de tester la navigation au clavier et le retour du lecteur d’écran. Tout n’est pas parfait mais heureusement, mon utilisateur non-voyant maîtrise également le code et préfère généralement les administrations en lignes de commande. Par conséquent, il arrive malgré tout à bien s’en sortir. Ce ne sera malheureusement pas forcément le cas pour toutes les personnes non-voyantes mais les plus gros problèmes sont, au moins, un tant soit peu corrigés.

Le petit script WordPress qui fait la différence

Ce projet m’a donné l’occasion de découvrir le petit script « skip link focus fix » qui permet de rétablir un fonctionnement correct des ancres sur Internet Explorer : lorsqu’on clique sur un lien vers une ancre, la prochaine tabulation se fera bien sur le prochain élément focusable après l’ancre.

Un bug Internet Explorer (IE) / Edge avec outline-color

Lors de la sortie du nouveau site de BrailleNet, on m’a demandé sur Twitter quelle était la raison de ce parti pris de mettre l’outline en pointillés sur tous les navigateurs et de casser le style natif.

Lors de mes tests en navigation clavier, je me suis rendue compte que, si on précise dans la CSS uniquement la propriété outline-color (pour des raisons de contraste afin de le rendre toujours visible), alors, sous IE et Edge, cela supprime visuellement complètement l’outline. Il est donc toujours nécessaire de repréciser l’outline-width ainsi que l’outline-style. Cela signifie que nous ne pouvons pas conserver le style natif du navigateur sur Chrome qui met un halo, par exemple.

J’ai donc créé un ticket à Microsoft qui le corrigera peut-être un jour.

Note de 2022 : la plateforme de tickets de l’ancien Microsoft Edge n’existe plus. J’ai donc vérifié le comportement sur le nouveau Edge via le CodePen que j’avais créé à l’époque et il n’y a plus de soucis (en même temps, ce n’est plus le même Edge). Par ailleurs, Internet Explorer 11 est mort avec l’arrivée de Windows 11 qui l’a supprimé.

Voir « Accessibilité, je t’emmènerai jusqu’au bout du back » en vidéo et en diaporama

• La vidéo de ma conférence
  Note : Il manque un morceau du début de ma conférence dans la vidéo (on voit que je parle mais on n’entend rien) que j’ai comblé dans la transcription textuelle.
• Transcription textuelle de la vidéo
• Le diaporama de ma conférence