Produits Entr'ouvert » Combo

Le choix niveau UI est d'utiliser un bouton qui ouvre un container en dessous.
Comme pour un accordion ou un collapse. Pourquoi pas.
Quelques remarques alors :

• La liste `additional-[forms|links]` devrait avoir un label. Souvent, on ajoute un attribut `aria-labelledby` qui pointe vers l'id du bouton.
• donc le bouton devrait avoir un id
• Je me demande si c'est une bonne idée de masquer le bouton par un display=`none` une fois cliqué. On perd le focus. À tester. Ou alors donner le focus à la list `additional-*`.
• Je ne suis pas pour différencier avec 2 class `additional-forms` et `additional-links` parce qu'ils ont le même style. J'utiliserais une class unique pour les 2 : `additional-list`. L'idée étant qu'à terme on ai un seul composant de type `links-list` pour styler toutes les listes de liens, que ce soit des demandes ou autre et cette class risque de devenir dans un avenir certain `links-list--additional-list`.
• Et si on en profitait pour proposer un feedback visuel un peu plus efficace que tout afficher d'un coup ? Un petite animation CSS ? Les items qui apparaissent les 1 après les autres ?

Et si on en profitait pour proposer un feedback visuel un peu plus efficace que tout afficher d'un coup ? Un petite animation CSS ? Les items qui apparaissent les 1 après les autres ?

Côté publik-base-theme peut-être mais limitons ce ticket au balisage pour l'accessibilité.

ha oui, maintenant que j'ai une branche correctement nommée, il faudrait peut-être que je regarde du côté des tests ce qui se passe :)

Remarques sur les noms de class. On a :

• .more-items (pour le bouton)
• .additional-list (sur ul)
• .additional-list (idem, sur li)

J'en profiterais bien pour uniformiser et gagner en lisibilité en utilisant le même prefix "more-items" et utiliser la convention de nommage qui est là pour ça.

• .more-items--button
• .more-items--list
• .more-items--item

Ensuite, puisqu'on parle d'accessibilité, j'ai un doute sur les aria-labels utilisés sur les boutons. Autant `{% trans 'More forms' }` pourrait être valable en fonction de sa traduction pour la cellule 'demarches d'une catégorie", autant { trans 'More links' %} sera souvent hors contexte. La cellule "liste de liens" est utilisée dans beaucoup de cas de figures différents, et également pour lister des démarches.
Je propose plutôt un label générique de type "Plus de choix" ou "Plus de propositions" plutôt que "plus de liens".

un label "More items", ça irait ?

Je pense. En EN ça passe, tout dépend comment il sera traduit en FR :)

Côté HTML, je n'ai plus de remarque.
côté JS, tu peux simplifier le sélecteur sizzle en utilisant simplement ".more-items--button" (je n'ai pas encore commencé ma croisade `less Jquery`).

• `more-items` n'étant plus un élément li (et ayant changé de class), il faut repasser sur tous les thèmes (qui par exemple ajoutent des styles à l'élément li.more-items… ho joie!)
• ne jamais utiliser `!important` dans le core (sauf pour les class qui doivent imposer un comportement comme .hide ou mobile-only)
• et d'autres trucs, … Je vais t'aider.

Notes après la séance de travail avec Laureline :

• Utiliser une balise `button` pour l'élément `.more-items--button` parait compliqué. L'élément hérite alors de tous les styles de %button (ligne 140 de _forms.scss, qui applique les styles), ce qui modifie le comportement graphique et impacte alors tous les thèmes existants. Il a été décider de conserver une balise `a` sans `href` et d'y ajouter les comportements d'un bouton via `role=button`, `tabindex=0` et une gestion des touches `enter` et `space` via JS.
• Placer `.more-items--button` en dehors de (après) la links-list lui fait perdre l'effet appliqué par `$cell-entry-hover-effect` qui a besoin d'un parent positionné et zindexé pour fonctionner (appliqué sur l'élément ul). Il a été décidé de conserver (pour le moment) l'emplacement actuel du bouton (dernier item de la liste). Positionner le bouton après la liste serait possible une fois le code des effets simplifié en utilisant simplement le background du bouton plutôt qu'un pseudo-element avec un z-index négatif.

Malgré ces revers, l'amélioration de l'accessibilité sur ce module n'est quand même pas négligeable.

Quelle est cette histoire de deuxième liste ? C'est peut-être quelque chose qui peut dégager ?

Quelle est cette histoire de deuxième liste ?

Les items supplémentaires se trouvent dans une seconde liste. Le bouton doit pouvoir afficher/masquer un container cible (aria-controls = id de la boite à afficher.

<ul>
  <li>Item Visible</li>
  …
  <li><a class="add-more-items--button" … aria-controls="more-items"></a></li>
</ul>
<ul class="more-items" id="more-items">
  <li>Item invisible par défaut</li>
  …
</ul>

Mais ça pourrait évoluer, il y a des intégrations qui stylent le <li class="more-items"> mais d'un rapide coup d'œil pas d'attention particulière à la liste qui suit, et donc on pourrait tous les mettre dans une unique liste, et avoir le bouton "+" venir s'insérer dedans, il me semble.

et donc on pourrait tous les mettre dans une unique liste, et avoir le bouton "+" venir s'insérer dedans, il me semble.

je ne suis pas sûr de comprendre, tu proposes de revenir à l'état actuel ?

<ul>
  <li>Item Visible</li>
  …
  <li><a class="add-more-items--button" … aria-controls="more-items"></a></li>
  <li display="none"> Item invisible par défaut </li>
  …
</ul>

Il faudrait pour cela que l'attribut aria-controls du bouton possède une liste d'identifiants, correspondant à l'id de chaque item caché.

Dans l'état actuel du patch (avec 2 listes), le design du bouton '+' ne pose plus de problème. Le problème qui reste à régler c'est les hacks pour $cell-border-radius

je ne suis pas sûr de comprendre, tu proposes de revenir à l'état actuel ?

Je parle sans suivre assez, désolé, j'avais cru qu'il y avait des cas où plusieurs listes étaient utilisées, mais non, la question apparait uniquement parce que ce ticket amènerait ça. (et donc normal qu'il n'y ait pas dans les intégrations existantes de gestion particulière du cas "deux listes").

Go pour tout; on a du temps ensuite en recette pour détecter d'éventuels ajustements.