j’ai donc lancé le chantier de refonte de la mediabox en m’inspirant très fortement de ce qu’a fait Placido que je remercie donc pour sa contribution et la mise a disposition de son code dans lequel j’ai allègrement pioché.
Pour assurer la compatibilité avec l’existant et pour garder une structure plus simple j’ai un peu divergé sur la forme et la position des pipelines et la façon dont on configure le tout, mais ça reste quand même très proche.
Vous trouverez donc une branche de travail sur le plugin mediabox https://git.spip.net/spip/mediabox/src/branch/dev/mediabox-extensible
qui en l’état ne fait visuellement rien de plus que le master, sauf à proposer un pipeline en plus pour permettre l’extension, obtenue après refonte.
La peinture n’est pas fraiche, il reste des bugs js sur l’intégration des box, des cas aux limites, et je pense unifier le namespace en ‘mediabox’ car ‘box’ tout court est pas assez différenciant et on risque des collisions.
L’intégration featherlight propose une configuration spécifique à cette box, mais ce n’est pas utilisé en l’état, j’ai repris telle quelle la css de la lib
Le plugin mediabox_plus propose aussi une page de test pour Z qui permet de tester les différentes utilisations de la box et de vérifier qu’on ne casse rien.
Si vous avez sous la main des petits cas un peu tordus n’hésitez pas à completer cette page
@nicod_ Oui ça fonctionnait bien et c’était déja compatible avec le markup existant (z-bloc ajax, iframe html… toussa) et les class css mediabox qui déclenchaient / definissaient les galeries
Dans le privé le seul soucis constaté c’était les maj successives de plugin ou les installations par lots qui ne s’affichaient pas dans la boite modal. Pour le reste c’était plutôt niquel.
Sur le sujet, je creuse un peu les libs récentes car j’ai un peu de doute sur l’accessibilité de featherlight...
Dans les libs dispos qui font tous les types de contenu et dont la licence serait compatible sans ambiguité je trouve https://biati-digital.github.io/glightbox/ qui a l’air pas mal du tout, moderne et maintenue
J'ai regardé succintement glightbox, qui me semble proposer les mêmes
prestations que featherlight, (avec un thème par défaut plus joli
peut-être).
En terme d'accessibilité, je ne vois pas trop où se situent les
différences ; navigation au clavier, label sur les boutons, animations
full CSS, ... c'est idem des deux côtés.
Si tu as un exemple en tête plus précis Cédric...
En terme de suivi, les deux projets semblent avoir atteint une certaine
maturité à en croire leur auteur respectif ; la liste des
fonctionnalités semblent figée.
Pour les chiffres, on est dans les mêmes proportions (featherlight ayant
quelques années de plus).
Autres infos potentiellement pertinentes pour une décision:
Featherlight 9k de js et 2k de CSS, glightbox 53k de js et 14k de css (tout minifié tel que téléchargé de Github), par contre glightbox intègre un player video plyr et supporte direct les galeries qui nécessitent une extension de 4+2k pour featherlight, donc featherlight semble quand même plus léger.
Les dernières modifs de featherlight datent de 13 mois, celles de glightbox de 6 jours ...
Oui j’ai vu tobii aussi mais je l’ai pas retenue car :
• la v1 est archivée, figée, donc pas question de démarrer une nouvelle séquence dessus
• la v2 est en beta, et de ce que j’ai testé ça semblait globalement pas très fini - mais les seules démos sont sous codepen, ce qui facilite pas le test en conditions réeelles.
Mais globalement donc cette v2 me parait encore très jeune et pas rôdée et j’ai pas trop envie d’essuyer les plâtres et de se retrouver à maintenir une box en plus du reste...
Mais donc,
ce qui aiderait vraiment,
c’est un test éclairé et comparé sous l’angle de l’accessibilité, de featherlight et glightbox, pour décider laquelle embarquer par défaut dans le core...
Est ce que tu aurais une démo en ligne de featherlight avec au moins une galerie, des images avec descriptions, voir de l'ajax, qui pourrait servir de base de test ?
Les items de navigation sont des span sans tabindex, donc inaccessibles au clavier.
Et sur ton site, le texte descriptif n'est pas du tout lié à l'image (pas d'utilisation de l'attribut alt ni d'attribut aria labelledby ou describedby).
Mais donc,
ce qui aiderait vraiment,
c’est un test éclairé et comparé sous l’angle de l’accessibilité, de featherlight et glightbox, pour décider laquelle embarquer par défaut dans le core...
Je peux demander à des experts avec qui je suis en contact.
Un premier retour :
En regardant rapidement ces 2 solutions, elles sont, toutes les 2, très éloignées des standards d'accessibilité.
Elles possèdent de nombreux problèmes bloquants.
Je ne sais pas si vous pourriez les adapter, mais même dans ce cas je ne pense pas qu'elles constituent une bonne base de départ.
D'un point de vue global, je pense qu'il faudrait peut-être partir d'une ressource qui clame son respect de l'accessibilité (même là il n'y aura pas forcément que des bonnes choses) car lorsque le sujet n'est pas explicitement déclaré, il serait miraculeux d'en avoir une prise en compte, même minimale.
Oui je suis bien d’accord, encore faut-il trouver une telle ressource ! Continuons de chercher donc, mais si par hasard il y’a des ressources connues on est preneur !
Oui je suis bien d’accord, encore faut-il trouver une telle ressource ! Continuons de chercher donc, mais si par hasard il y’a des ressources connues on est preneur !
Parmi mes ressources habituelles (et validées), les composants de Nicolas Hoffmann, dont sa modale, qui existent en version jQuery :
focus sur le premier élément tabulable
tab et shift-tab ne se déplacent pas en dehors de la fenetre modale
fermeture avec Esc ou au clic à l'extérieur de la fenêtre
Pas mal du tout, ça gère plein de choses nativement.
A confirmer quand même, en France c'est le RGAA qui s'applique, pas le WCAG.
Premiers retours sur Modaal par Eric, de Temesis, avec qui je collabore sur un projet :
C'est bien mieux à la base, il manque quand même au moins 3 caractéristiques techniques importantes qui ne permettent pas actuellement le respect de WCAG/RGAA :
* l’élément déclencheur doit être un bouton (ici c'est un lien)
* Sur la modale (le div avec role="dialog") : supprimer aria-selected (aucun sens ici) et supprimer tabindex="0" (le focus doit être géré autrement)
* Quand la modale est affiché, des contenus en arrière-plan (tout ce qui n’est pas dans le div role="dialog") sont restitués dans les assistances technologiques et il est parcouru au clavier.
(pour ça, il y a une technique à repiquer dans les modales de Nicolas Hoffmann)
Il y a sûrement aussi d'autres éléments plus mineurs et/ou améliorables.(je n'ai pas regardé les aspects transversaux comme les visibilité du focus clavier ou autres)
Dans la galerie :
Il s'agit en fait d'un autre composant (le fait qu'il est dans une modale est anecdotique). Là, effectivement ça marche au clavier et c'est déjà pas mal, la gestion du focus clavier semble correcte dans ce contexte, mais tabindex="0" pour le gérer n'est pas une bonne chose (comme plus haut)
Mieux mais pas complètement parfait non plus donc...
Bon donc en synthèse, après une rapide revue des troupes :
• la modale de Nicolas est top et accessible… pour une modale : elle fait très bien le job pour un usage de modale avec interactions, mais elle fait pas du tout la gestion des medias (ie gérer le chargement d’images, d’iframe, adapter la taille de la popin à la taille des images, gérer les galeries avec le passage suivant/précédent...)
• featherlight pas plus que glightbox ne sont particulièrement accessibles (on a bien une navigation au clavier dans les 2 cas, mais c’est le service minimum)
• tobii se revendique accessible mais est encore totalement en dev cf https://github.com/rqrauhvmra/tobii/issues/28
• modaal https://humaan.com/modaal/ semble la plus intéressante, avec une bonne base concernant l’accessibilité et le support des medias et galleries…
MAIS elle ne semble pas très activement maintenue. Je vois des PR et des Issues sur https://github.com/humaan/Modaal qui sont un peu gênantes, concernent l’accessibilité ou le support des versions récentes de jQuery
On a donc aucune solution prêt à l’emploi et que des emmerdes à gérer
cette réflexion me fait penser : y-a-il une obligation/raison (en dehors du coup de maintenannce) à avoir un même outil pour les 2 fonctionnalités (interactions vs galerie) ?
