Et enfin bon, puisque ça a été subtilement suggéré je me sens obligé de répondre : je me garde bien d'ajouter des choses à la charte tout seul dans mon coin sans en parler avant, ou d'inventer des cas d'utilisation.
Les styles répondent aux choses qui étaient clairement définies dans la charte (celle de 3.2), et pour les cas moins clairs comme les .choix et bien oui, des fois il faut inférer une partie des règles en fonction de ce qu'on a devant les yeux, les formulaires de la dist en l'occurence. On peut se tromper mais merci de ne pas immédiatement me prêter des intentions que j'ai jamais eues.
Clairement ce « Oui Non » est un très mauvais pattern en terme d’accessibilité, et gagnerait à être remplacé par une case à cocher explicite
Absolument pas, ce sont deux choix d'UX totalement différents, il faut bien choisir en connaissance de cause et en fonction du contexte.
If questions are like this:
"Subscribe to newsletter?", then its definitely checkbox. If its missed, then, they don't miss something important
If questions are like this:
"Should we email you the order details for record?" then definitely go for radios.
Sorry, sorry, je sais que tu as fais pour le mieux avec les infos que tu avais, pardon de la formulation.
Et effectivement ta proposition de choix.choix_inline>.sous-choix (ou .choix-item ?) semble bien aussi pour gérer les cas où l’on veut mettre les choix en ligne dans un bloc .choix