Project

General

Profile

Anomalie #4540

Accessibilité des boutons radios et checkboxes

Added by nicod _ 8 months ago. Updated 20 days ago.

Status:
En cours
Priority:
Normal
Assignee:
-
Category:
accessibilité
Target version:
Start date:
08/31/2020
Due date:
% Done:

0%

Resolution:
Navigateur:

Description

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.

History

#1 Updated by b b 8 months ago

  • Target version set to 3.3

#2 Updated by RastaPopoulos ♥ 8 months ago

  • Target version deleted (3.3)

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.

#3 Updated by RastaPopoulos ♥ 8 months ago

  • Target version set to 3.3

youps :)

#4 Updated by nicod _ 8 months ago

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">

#6 Updated by nicod _ about 2 months ago

Ç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.

#7 Updated by tcharlss 🐽 about 2 months ago

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">

#8 Updated by nicod _ about 2 months ago

Bonne remarque, +1

#9 Updated by RastaPopoulos ♥ about 2 months ago

"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).

#10 Updated by tcharlss 🐽 about 2 months ago

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 …">

#11 Updated by RastaPopoulos ♥ about 2 months ago

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

#12 Updated by cedric - about 2 months ago

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.

#13 Updated by tcharlss 🐽 about 2 months ago

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.

#14 Updated by cedric - about 1 month ago

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é

#15 Updated by nicod _ about 1 month ago

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

#17 Updated by cedric - 23 days ago

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

#18 Updated by nicod _ 22 days ago

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

Also available in: Atom PDF