Quand est-il approprié d'utiliser des entrées désactivées?
Il semble préférable d'éviter complètement les contrôles désactivés, même si je me rends compte qu'il y a parfois des raisons techniques pour lesquelles les gens sont obligés de styliser certains contrôles désactivés au lieu de supprimer les champs ou d'afficher des informations en lecture seule à la place. Outre ces situations peu idéales, est-il jamais préférable d'utiliser une entrée désactivée?
Existe-t-il également des normes documentées de l'industrie pour les traitements visuels des commandes désactivées? L'accessibilité doit être prise en compte par toute tentative de travail "faisant autorité". J'ai du mal à trouver une justification de conception approfondie pour les États handicapés. Les interactions sont assez bien discutées (car c'est principalement de cela que parlent les états désactivés), mais pas les visuels.
Les raisons contre les composants désactivés sont profondes et traversent tous les domaines. Par exemple, les composants désactivés ont une charge cognitive dépendante du contexte. Les utilisateurs doivent savoir comment activer les composants désactivés. Découvrir le composant est désactivé et déterminer comment l'activer est une charge cognitive. Toutes les actions que l'utilisateur doit effectuer pour activer le bouton ont aggravé la charge cognitive. Plus il y a d'actions et plus la solution est éloignée, plus la charge cognitive est multipliée.
Les interfaces utilisateur ne devraient pas avoir besoin de composants désactivés. C'est une impasse. Peu importe combien il est facile de les activer, les utilisateurs se retournent et reviennent. À tout le moins, c'est visuel, mais généralement les utilisateurs doivent revenir cognitivement et physiquement.
Les composants désactivés ne doivent être utilisés que s'ils peuvent être facilement activés sur le même écran dans la même tâche.
Existe-t-il également des normes documentées de l'industrie pour les traitements visuels des commandes désactivées?
Material Design comporte une section à ce sujet dans Interaction> États> Désactivé
https://material.io/design/interaction/states.html#disabled
Notez que Material Design n'utilise pas vraiment de composants désactivés. Ils sont définis mais pas utilisés. Si vous regardez les directives et leurs exemples, vous verrez qu'elles ne sont utilisées que pour les steppers, ce qui provient des anciennes directives MD.
Je pense que la distinction entre les types d'entrée aide les utilisateurs à comprendre la façon dont le système interagit, que ce soit le résultat de leurs actions ou un état défini par la conception du système lui-même.
Une entrée en lecture seule peut être cliquée et interagie avec, même si la modification de sa valeur n'est pas autorisée. Cette valeur peut être le résultat d'un calcul entre les valeurs saisies sur d'autres entrées de formulaire et l'utilisateur peut vouloir la copier. Dans ce cas, la lecture seule est plus logique que désactivée.
Une entrée désactivée est inutilisable et non cliquable, et l'ensemble de valeurs est généralement généré par le système et un moyen pour le système d'indiquer que la modification d'une certaine valeur n'est pas autorisée, que ce soit parce que l'utilisateur n'a pas le privilège ou parce que c'est le seul valeur possible pour un contexte donné.