Une bonne pratique HTML consiste à utiliser l’attribut disabled lorsque l’action n’est pas disponible.

Prenons un peu de recul et demandons-nous si cette option est vraiment la meilleure pour offrir un bon service, et une bonne expérience, à nos utilisateurs.

Qu’est-ce qui ne va pas lorsqu’on utilise l’attribut “disabled” pour indiquer qu’une action n’est pas disponible, et en bloquer son utilisation ?

<button type="button" disabled="disabled">
  Une action
</button>

Après tout, il semble que désactivere un bouton soit la meilleure façon de procéder. C’est le comportement standard d’HTML et qui il existe dans tous les systèmes d’interfaces utilisateur.

Alors pourquoi ne pas l’utiliser systématiquement dans une application web ? Voyons cela de plus près.

Quelle raisons pour utiliser ‘disabled’?

Cet attribut permet d’obtenir gratuitement un comportement prêt à l’emploi :

  • l’action est bloquée lorsque l’utilisateur essaie de cliquer.
  • Le style visuel indique clairement que le bouton n’est pas disponible.

Quelles raisons de ne pas utiliser ‘disabled’?

  • Les boutons désactivés ne recoivent pas le focus ou d’autres événements.
  • Ils ne participent pas non plus à la navigation avec la touche tabulation “Tab”.
  • Comme le bouton ne peut pas recevoir le focus, ou d’autres événements, cela vous empêche de fournir des indications supplémentaires aux utilisateurs lorsqu’ils atteignent l’action.

Pour ce faire, on utilise généralement une infobulle ou une fenêtre contextuelle qui s’affichera lorsque l’utilisateur clique ou se concentre sur le bouton.

Remarque: pour ce dernier point, il peut être important d’expliquer à l’utilisateur pourquoi une action n’est pas disponible :

  • il ne peut pas continuer tant que les conditions de vente n’ont pas été approuvées par l’utilisateur.
  • une confirmation d’achat est désactivée parce que les détails du paiement ne sont pas fournis.
  • etc.

Les boutons désactivés peuvent poser un problème d’accessibilité et de cohérence de l’expérience utilisateur :

Pourquoi certains boutons sont-ils utilisables alors que d’autres ne le sont pas ? L’utilisateur pourrait être dérouté.

Voir ci-dessous la courte démo :

  • La sortie vocale Nvda est affichée à gauche.
  • Dans un premier temps, je navigue avec les flèches en utilisant le curseur Nvda : les boutons sont correctement lus, mais pas l’infobulle.
  • Deuxièmement, j’utilise b et Shift+b pour naviguer sur les boutons : l’info-bulle n’est pas lue.
  • Enfin, j’utilise Tab et Shift+Tab pour naviguer avec lee focus sur les boutons : le bouton désactivé ne fait pas partie de la navigation par tabulation.
Comment Nvda interagi avec un bouton désactivé.

Quelle est l’alternative ?

Tout dépend de l’expérience voulue pour l’utilisateur, mais je pense qu’il est préférable de ne pas utiliser l’attribut HTML disabled et de se contenter d'aria-disabled.

<!--
  Ce bouton n'est pas désactivé.
  Il pourra afficher une infobulle Bootstrap lorsqu'il sera activé
  (l'infobulle est configurée grâce aux attributs `data-`.
  Consultez la documentation Bootstrap pour plus de détails.
-->
<button type="button" 
        aria-disabled='true'
        data-bs-toggle="tooltip"
        data-bs-title="Cette option n'est pas disponible">
  Action indisponible
</button>

Comment cette implémentation se compare-t-elle à l’implémentation précédente qui utilise un bouton désactivé ?

  • La sortie vocale Nvda est affichée à gauche
  • Je navigue d’abord avec les flèches en utilisant le curseur Nvda : Les boutons sont correctement lus, mais pas l’infobulle. Le bouton désactivé est correctement affiché comme désactivé.
  • Deuxièmement, j’utilise b et Shift+b pour naviguer sur le bouton : La bulle d’aide n’est pas lue.
  • Enfin, j’utilise Tab et Shift+Tab pour naviguer sur les boutons : le bouton désactivé fait maintenant partie de la navigation par tabulation et l’affichage de l’infobulle est maintenant correctement déclenché.
Comment Nvda interagi avec un bouton marqué par aria-disabled.

Le même comportement peut être observé lors de l’utilisation de VoiceOver et de Safari sur un Mac dans la vidéo ci dessous.

Conclusion

Le choix final vous appartient, et dépendra de ce que vous souhaitez pour votre interface utilisateur.

Gardez à l’esprit cette façon d’implémenter un bouton désactivé, surtout si vous avez besoin d’une interaction minimale sur celui-ci.

Vos premiers critères devraient être de réduire la confusion des utilisateurs et d’améliorer la cohérence de l’interface utilisateur.

Quelques liens :