Accessibilité des boutons radios et checkboxes #4540

Open
opened 2 years ago by nicod_ · 20 comments
nicod_ commented 2 years ago
Owner

Ticket lié à celui ouvert sur le plugin saisies : spip-contrib-extensions/saisies#27


Les boutons radios et checkboxes devraient être regroupés dans un fieldset avec une légende.

Exemple à obtenir :

<div class="editer-groupe">
  ...
  <div class="editer editer_radio">
    <fieldset>
    <legend>Label des boutons radios</legend>
       <div class="choix choix_choix1">
          <input type="radio" name="radio_1" class="radio" id="champ_radio_1_1" value="choix1">
          <label for="champ_radio_1_1">Un</label>
       </div>
       <div class="choix choix_choix2">
          <input type="radio" name="radio_1" class="radio" id="champ_radio_1_2" value="choix2">
          <label for="champ_radio_1_2">Deux</label>
       </div>
        <div class="choix choix_choix3">
          <input type="radio" name="radio_1" class="radio" id="champ_radio_1_3" value="choix3">
          <label for="champ_radio_1_3">Trois</label>
       </div>
    </fieldset>
  </div>
  ...
</div>

Il faut une classe dédiée pour ces fieldsets là, qui regroupent des boutons ou case, et une autre, pour les fieldsets qui regroupent des champs divers.

Ticket lié à celui ouvert sur le plugin saisies : https://git.spip.net/spip-contrib-extensions/saisies/issues/27 ---- Les boutons radios et checkboxes devraient être regroupés dans un fieldset avec une légende. Exemple à obtenir : ``` <div class="editer-groupe"> ... <div class="editer editer_radio"> <fieldset> <legend>Label des boutons radios</legend> <div class="choix choix_choix1"> <input type="radio" name="radio_1" class="radio" id="champ_radio_1_1" value="choix1"> <label for="champ_radio_1_1">Un</label> </div> <div class="choix choix_choix2"> <input type="radio" name="radio_1" class="radio" id="champ_radio_1_2" value="choix2"> <label for="champ_radio_1_2">Deux</label> </div> <div class="choix choix_choix3"> <input type="radio" name="radio_1" class="radio" id="champ_radio_1_3" value="choix3"> <label for="champ_radio_1_3">Trois</label> </div> </fieldset> </div> ... </div> ``` Il faut une classe dédiée pour ces fieldsets là, qui regroupent des boutons ou case, et une autre, pour les fieldsets qui regroupent des champs divers.
b_b commented 2 years ago
Owner

Version cible mise à 4.0

**Version cible mise à 4.0**

Cela devra faire partie de la normalisation du HTML et CSS des formulaires, documenté ici : https://www.spip.net/fr_article3791.html

L'admin de SPIP fournie devra utiliser cette structuration partout où il y a ces listes de choix, et devra avoir les styles CSS pour les afficher correctement. Pareil pour les styles des squelettes-dist publics fournis.

Une fois ajouté à la documentation, les squelettes/thèmes contribués devraient aussi les prévoir.
Version cible mise à 4.0

Cela devra faire partie de la normalisation du HTML et CSS des formulaires, documenté ici : https://www.spip.net/fr_article3791.html L'admin de SPIP fournie devra utiliser cette structuration partout où il y a ces listes de choix, et devra avoir les styles CSS pour les afficher correctement. Pareil pour les styles des squelettes-dist publics fournis. Une fois ajouté à la documentation, les squelettes/thèmes contribués devraient aussi les prévoir. **Version cible mise à 4.0**

youps :)
Version cible mise à 4.0

youps :) **Version cible mise à 4.0**
Poster
Owner

La première chose à faire serait de définir le markup et la ou les classes css et de mettre à jour la doc officielle (https://www.spip.net/fr_article3791.html), pour pouvoir démarrer les modifications sur le core et sur le plugin saisies en même temps.

L'exemple que j'ai posté me parait suffisant en terme de html, je propose d'utiliser simplement une classe fieldset_choix, qui permet de les cibler :

<div class="editer-groupe">
  ...
  <div class="editer editer_radio">
    <fieldset class="fieldset_choix">
    <legend>Label des boutons radios</legend>
       <div class="choix choix_choix1">
La première chose à faire serait de définir le markup et la ou les classes css et de mettre à jour la doc officielle (https://www.spip.net/fr_article3791.html), pour pouvoir démarrer les modifications sur le core et sur le plugin saisies en même temps. L'exemple que j'ai posté me parait suffisant en terme de html, je propose d'utiliser simplement une classe *fieldset_choix*, qui permet de les cibler : ``` <div class="editer-groupe"> ... <div class="editer editer_radio"> <fieldset class="fieldset_choix"> <legend>Label des boutons radios</legend> <div class="choix choix_choix1"> ```
Owner

on peut faire plus simple, comme proposé par
spip/dev#3 -> 3d4f3f40fd
et avec juste un peu de complement de styles
#121 -> d18ea58144
Statut changé à En cours

on peut faire plus simple, comme proposé par https://git.spip.net/spip/dev/pulls/3 -> https://git.spip.net/spip/dev/commit/3d4f3f40fd9afe2b60bcf7898a149c5df6e0c1e4 et avec juste un peu de complement de styles https://git.spip.net/spip/spip/pulls/121 -> https://git.spip.net/spip/spip/commit/d18ea58144abfdae66b5072754dc818559e6b490 **Statut changé à En cours**
Poster
Owner

Ça me parait parfait, je vote pour !

Mais du coup il y aurait sûrement un paquet de formulaires à reprendre, dans spip et les plugins dist...
Je peux m'en charger.

Ça me parait parfait, je vote pour ! Mais du coup il y aurait sûrement un paquet de formulaires à reprendre, dans spip et les plugins dist... Je peux m'en charger.
Owner

Simple et efficace.

Par précaution, est-ce qu'il faudrait pas quand même une classe supplémentaire pour différencier les fieldsets « lambdas » des fieldsets .editer ? Pour avoir à se reposer sur la balise elle-même ?

<fieldset class="editer fieldset_editer …">

Et pour les fieldsets lambdas :

<fieldset class="fieldset">
Simple et efficace. Par précaution, est-ce qu'il faudrait pas quand même une classe supplémentaire pour différencier les fieldsets « lambdas » des fieldsets .editer ? Pour avoir à se reposer sur la balise elle-même ? ``` <fieldset class="editer fieldset_editer …"> ``` Et pour les fieldsets lambdas : ``` <fieldset class="fieldset"> ```
Poster
Owner

Bonne remarque, +1

Bonne remarque, +1

"fieldset:not(.editer)" pour styler spécifiquement les gros groupes classiques.

Pour la classe en plus, je sais pas si c'est utile pour une balise sémantique, qui peut jamais être remplacée par une autre (comme quand on style les "pre" ou "ul" par défaut, on style bien la balise directe).

"fieldset:not(.editer)" pour styler spécifiquement les gros groupes classiques. Pour la classe en plus, je sais pas si c'est utile pour une balise sémantique, qui peut jamais être remplacée par une autre (comme quand on style les "pre" ou "ul" par défaut, on style bien la balise directe).
Owner

fieldset:not(.editer) ça fait un sélecteur super spécifique plus fort que fieldset.editer, c'est la galère après ces histoires.

Dans l'autre sens alors, une classe variante de .editer pour dire « c'est un .editer sous forme de fieldset ».

<fieldset class="editer editer_fieldset …">
`fieldset:not(.editer)` ça fait un sélecteur super spécifique plus fort que `fieldset.editer`, c'est la galère après ces histoires. Dans l'autre sens alors, une classe variante de .editer pour dire « c'est un .editer sous forme de fieldset ». ``` <fieldset class="editer editer_fieldset …"> ```

oui effectivement, faut faire gaffe à la force des sélecteurs, et permettre de styler l'un et l'autre séparément (car sémantiquement c'est vraiment différent un fieldset groupe de plusieurs champs, et un fieldset groupe d'un même name uniquement) sans obliger à des contorsions de plus en plus fortes

oui effectivement, faut faire gaffe à la force des sélecteurs, et permettre de styler l'un et l'autre séparément (car sémantiquement c'est vraiment différent un fieldset groupe de plusieurs champs, et un fieldset groupe d'un même name uniquement) sans obliger à des contorsions de plus en plus fortes
Owner

je vois même pas le problème dont on parle :

  • le style générique des fieldset s'applique au selecteur fieldset et le style pour le cas specifique des choix s'applique à fieldset.editer voire même simplement à .editer qui est toujours plus fort que fieldset et qui s'applique pas aux fieldset normaux

Il y a aucun problème de priorité, ajouter une classe sur les fieldset normaux apporte vraiment pas grand chose et par contre ça veut dire que tes styles seront pas compatibles de tous les formulaires qui sont déjà dans la nature.

Alors que là on ne fait qu'ajouter une possibilité en plus, et tout ce qui existait continue à être rendu exactement pareil, c'est beaucoup plus souple comme transition.

je vois même pas le problème dont on parle : - le style générique des fieldset s'applique au selecteur `fieldset` et le style pour le cas specifique des choix s'applique à `fieldset.editer` voire même simplement à `.editer` qui est toujours plus fort que `fieldset` et qui s'applique pas aux `fieldset` normaux Il y a aucun problème de priorité, ajouter une classe sur les fieldset normaux apporte vraiment pas grand chose et par contre ça veut dire que tes styles seront pas compatibles de tous les formulaires qui sont déjà dans la nature. Alors que là on ne fait qu'ajouter une possibilité en plus, et tout ce qui existait continue à être rendu exactement pareil, c'est beaucoup plus souple comme transition.
Owner

Hum, il y a un malentendu là, j'ai jamais parlé de faire autre chose que ce tu proposes.
Je suggère juste d'ajouter une classe en plus, au cas-où, même si pas utilisée tout de suite. Si esoin ça permettrait de cibler plus facilement plus tard.

Hum, il y a un malentendu là, j'ai jamais parlé de faire autre chose que ce tu proposes. Je suggère juste d'ajouter une classe en plus, au cas-où, même si pas utilisée tout de suite. Si esoin ça permettrait de cibler plus facilement plus tard.
Owner

Les styles supplémentaires sont intégrés et le formulaire charte de référence mis à jour.
A noter :

  • l'ajout d'une classe sur les fieldset standard est possible, mais pas backward compatible : aucun formulaire dans la nature ne dispose de cette classe et se reposer dessus veux dire qu'on aura une apparence cassée, sauf à forcer de reprendre le html partout
  • il reste à corriger le html des formulaire du core donc pour se mettre en conformité
Les styles supplémentaires sont intégrés et le formulaire charte de référence mis à jour. A noter : - l'ajout d'une classe sur les fieldset standard est possible, mais pas backward compatible : aucun formulaire dans la nature ne dispose de cette classe et se reposer dessus veux dire qu'on aura une apparence cassée, sauf à forcer de reprendre le html partout - il reste à corriger le html des formulaire du core donc pour se mettre en conformité
Poster
Owner

Et dans la fabrique et dans saisies, pour mémoire :)
Je me mets ça en todo list.

Et dans la fabrique et dans saisies, pour mémoire :) Je me mets ça en todo list.
Poster
Owner
Je reviens là dessus : pourquoi tu n'as mis à jour que https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L140 et pas les autres div, comme https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L107 et https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L125 ?
Owner

c'est un oubli, il faut en effet généraliser le pattern y compris dans le formulaire charter

c'est un oubli, il faut en effet généraliser le pattern y compris dans le formulaire charter
Poster
Owner

Ok on est donc bien d'accord, je pensais qu'il y avait une raison qui m'échappait :)

Ok on est donc bien d'accord, je pensais qu'il y avait une raison qui m'échappait :)
Poster
Owner

Mis à jour : 6f59c5f384

Mis à jour : https://git.spip.net/spip/dev/commit/6f59c5f384741fd81efab94fab6a7ce75720bbc8

Je reviens un peu là dessus pour cette modif dans Saisies spip-contrib-extensions/saisies#172

Ce dernier générait déjà une classe dédiée aux "vrais" fieldsets (vrais groupes), du coup yen avait déjà dans la nature aussi (et donc d'autres sans).

Moi ce que je vois comme avantage principal, c'est de pouvoir styler uniquement les vrais fieldsets directement, sans utiliser un sélecteur hyper fort et donc hyper galère à surcharger ensuite.

En effet, si on style TOUS les "fieldset" tout court (sans classe dédiée), PUIS les "fieldset.editer", alors que ça signifie qu'il faut possiblement ANNULER des styles aux "fieldset.editer" qu'on voulait pas du tout. Alors que ces derniers, ces fieldsets "liste de choix", c'est utilisation totalement différente de "vrai groupe de champs", et donc ça peut possiblement avoir des styles parfaitement différents.

Certes les styles des ".editer" prendront le pas sur "fieldset", mais seulement donc pour les attributs qui sont en communs ! S'il y a des attributs définis dans "fieldset" qui ne sont PAS définis dans ".editer", alors ça gardera alors qu'on en voulait pas.

Ça me parait donc quand même pas mal sur le long terme (petit à petit les anciens forms à l'ancienne norme disparaitront) de pouvoir styler spéficiquement les "vrais groupes" seuls, sans ":not" etc.

Je reviens un peu là dessus pour cette modif dans Saisies https://git.spip.net/spip-contrib-extensions/saisies/pulls/172 Ce dernier générait *déjà* une classe dédiée aux "vrais" fieldsets (vrais groupes), du coup yen avait déjà dans la nature aussi (et donc d'autres sans). Moi ce que je vois comme avantage principal, c'est de pouvoir styler *uniquement* les vrais fieldsets directement, sans utiliser un sélecteur hyper fort et donc hyper galère à surcharger ensuite. En effet, si on style TOUS les "fieldset" tout court (sans classe dédiée), PUIS les "fieldset.editer", alors que ça signifie qu'il faut possiblement ANNULER des styles aux "fieldset.editer" qu'on voulait pas du tout. Alors que ces derniers, ces fieldsets "liste de choix", c'est utilisation totalement différente de "vrai groupe de champs", et donc ça peut possiblement avoir des styles parfaitement différents. Certes les styles des ".editer" prendront le pas sur "fieldset", mais seulement donc pour les attributs qui sont en communs ! S'il y a des attributs définis dans "fieldset" qui ne sont PAS définis dans ".editer", alors ça gardera alors qu'on en voulait pas. Ça me parait donc quand même pas mal sur le long terme (petit à petit les anciens forms à l'ancienne norme disparaitront) de pouvoir styler spéficiquement les "vrais groupes" seuls, sans ":not" etc.
Sign in to join this conversation.
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.