Input radio pour les boutons Accepter / Refuser

[fchom]

Bonjour,

Est ce qu'il serait pertinent de proposer une option facultative dans la configuration pour utiliser des input radios plutôt que des boutons pour les boutons Accepter/Refuser ?

C'est une recommandation d'une agence spécialisée dans l'accessibilité numérique, et votre ressenti serait le bienvenu.

[nicozerr]

Bonjour,

Les boutons actuels possèdent des attributs (aria-pressed) permettant de d'indiquer s'ils sont enfoncés ou pas. Je considère cela comme totalement conforme au regard de l'accessibilité.
Cependant, des boutons radio comme sur ce Codepen, voire même 1 seule checkbox sous forme de switch comme sur cet article, seraient très bien aussi à condition que le tout soit correctement développé, robuste, compatible avec les aides techniques... accessible en somme.

À voir avec @AmauriC si cela devrait plutôt faire partie d'une prochaine V2 de TAC à cause de la retrocompatibilité...

[dleschiera]

Bonjour,

En effet, dans le code, l'information est transmise de façon claire. On sait quelle est l'option qui est activée.
Au niveau UX, cela me semble plus discutable, car en réalité la plupart du temps, l'information est donnée visuellement par le fait que l'option qui est activée est plus contrastée, tandis que celle qui ne l'est pas a une opacité moindre.
Personnellement, je trouve que ça manque un peu de clarté, et que des boutons radio / ou éventuellement un système de switch comme indiqué ci-dessus seraient plus pertinents (potentiellement avec des boutons radios derrière, techniquement).
D'une façon purement pragmatique, pour moi le bouton radio serait ce qui convient le mieux à la représentation de cette information : nous avons en effet un choix 1, un choix 2 et une version également où aucune option n'a encore été choisie, et ça me semblerait être la représentation la plus adéquate pour ce type d'information. A voir.

Une option facultative permettrait de conserver la rétrocompatibilité. Cela pourrait être envisageable ?

[nicozerr]

Il est tout à fait possible d'ajouter une feuille de style sur votre site pour surcharger le CSS de TAC et lui donner l'aspect souhaité, et même faire en sorte que cela ressemble à des radios ou des swicth. En exemple les 2 liens dans mon commentaire précédent.

Après vous êtes aussi libre de proposer à l'auteur @AmauriC une option supplémentaire qui change le HTML des boutons et utilise le CSS adéquate.

[dleschiera]

Bonjour,
J'avais proposé cette option à mon interlocuteur accessibilité, d'afficher les 2 boutons comme des input radio visuellement, mais sans toucher à la structure html, mais voici le retour que j'ai eu par rapport à cette idée :
Si visuellement vous faites des faux boutons radios, les personnes utilisant un clavier pourraient être perturbées dans leur navigation. En effet, avec des boutons radios la navigation à l'intérieur de ces éléments se fait via les flèches du clavier. Je ne vous recommande donc pas cette solution.
C'est pour ça que permettre l'utilisation d'input radio serait une meilleure solution pour l'accessibilité.

[nicozerr]

Ah oui en effet, je suis d'accord avec votre interlocuteur. Je ne vois pas donc pas d'inconvénient à l'ajout d'une option pour choisir entre des boutons radio ou les boutons actuels.

[dleschiera]

Merci pour votre retour !
On verra aussi le retour que fera @AmauriC, je suppose.

[AmauriC]

Hello : )

Si au niveau de l’accessibilité le fonctionnement actuel est ok, il pourrait être intéressant de proposer un système de thème pour pouvoir choisir les boutons, un switch, des boutons radio ou même des checkbox.

Le plus simple techniquement serait de créer des feuilles de style sans changer le rendu DOM mais il ne faut pas régresser au niveau de l’accessibilité et perturber les utilisateurs.

Je suis comme d’habitude ouvert à toute proposition et prêt à travailler dessus : )

[dleschiera]

Bonjour,

Désolée pour le délai de réponse, ça a été pas mal chargé de notre côté.

Au niveau de l'accessibilité, le markup actuel est perfectible, c'est pour cela que nous ouvrons ce sujet avec fchom.
Nous pouvons travailler sur une option permettant de sélectionner l'utilisation de boutons (fonctionnement actuel, valeur par défaut de cette option) ou input radio, dans un premier temps. A voir si cette liste d'options peut s'enrichir ensuite. Notre contact accessibilité nous a confirmé que l'utilisation d'input radio était optimal dans ce cas de figure.

De notre côté, ça ne pourra probablement pas avancer avant le mois de septembre. On se tient au courant ici.

Merci encore !