a11y fixes

[ppom0]

Various accessibility fixes.

Every commit address one granular aspect.

[mrflos]

Hello @ppom0 , pour reviewer, ca va être compliqué car a priori tu sais ce qu'il faudrait améliorer et moi non, donc si tu es ok, on pourrait plutôt dire que quand c'est bon de ton coté, je teste et regarde juste d’éventuels changement de look, d'ui qui pourraient faire bizarre aux usager.es, mais en gros ca sera probablement auto-validé

[ppom0]

Carrément. Ce qui est important, c'est de constater d'un point de vue "connoisseur de YesWiki" qu'il n'y a pas de régressions :)

[ppom0]

Ok, j'ai réglé ce que j'ai pu sur la partie visualisation du site. Les changements sont petits mais multiples, et je pense que la différence est grande pour les personnes qui utilisent des lecteurs d'écran ou naviguent au clavier.

Des indices sur où le reste de mon temps devrait être dépensé ?

Je sais que y'a des problèmes dans les formulaires par exemple, mais il y en a beaucoup et je ne sais pas ce qui est prioritaire.

[mrflos]

la recherche? en particulier les actions bazarliste avec des facettes?

[mrflos]

merci @ppom0 ! Vu que c'est pas évident a relire, mais qu'il faudra le tester intensement, je propose de le merger maintenant, et si l'on doit faire des commits pour ajuster des comportements, on t'en parle sur le canal framateam yeswiki "dev a11y"!

[J9rem]

Merci @ppom0 pour les apports. 👍

En testant, je remarque que tous les div qui ont été remplacés par des button posent souci avec bootstrap car bootstrap n'empêche pas, par défaut, la propagation du clic après avoir ouvert/fermé le panneau associé (etc...)

Est-ce que l'usage de <button> est vraiment nécessaire pour respecter la norme a11y ?

• si oui, bon, il va falloir creuser côté .js pour bloquer la propagation des clics 💪
• si non, est-ce que nous pouvons revenir aux div ? 😃

Merci @ppom0 pour ta réponse qui me permettra de savoir dans quelle direction proposer un correctif.

[ppom0]

Bonjour ! Merci pour ces tests. Je n'avais pas vu ce problème de la propagation des évènements, déso !

L'usage de <button> permet plusieurs choses qu'il faudrait implémenter manuellement avec un <div>:

• Le focus (faisable avec un div avec tabindex="0")
• Le rôle sémantique (faisable avec un div avec role="button")
• Le statut (pressé...) (faisable avec un div avec aria-pressed, à mettre à jour manuellement)
• L'interactivité au clavier (faisable avec un div avec une écoute des évènements claviers)
• Peut-être autre chose que j'oublie :shrug:

Tout ça est faisable avec du JavaScript sans utiliser les composants standards, mais c'est vraiment se tirer une balle dans le pied : c'est beaucoup plus compliqué à réimplémenter correctement, alors que button gère tout ça par défaut. Dans le cas des accordéons, le seul truc qui n'est pas automatique, c'est aria-expanded, mais bootstrap le gère déjà.

Du coup, je pense que le plus simple est d'ajouter un e.stopPropagation(), comme ce n'est qu'une action. Mais moi non plus, je ne vois pas trop où placer ça actuellement :zipper_mouth_face:

Pour plus d'infos si ça vous intéresse et que vous avez un peu de temps, ces informations (↑) sont disponibles ici notamment : https://www.accessibility-developer-guide.com

[J9rem]

Merci @ppom0 pour ta réponse très complète.

Je vais donc essayer d'introduire dans le .js tous les correctifs nécessaires pour event.preventDefault() (event.stopPropagation() est plutôt destiné à ne pas autoriser les autres écouteurs d'évènements en plus du comportement par défaut et pourrait empêcher bootstrap de fonctionner)

[ppom0]

Yes, bien vu, merci ! Hésite pas à me ping si besoin d'aide.