Rendre les boutons désactivés plus inclusifs

Parlons de boutons désactivés. Plus précisément, expliquons pourquoi nous les utilisons et comment nous pouvons faire mieux que l'attribut désactivé traditionnel dans HTML (par exemple, le bouton désactivé>) pour marquer un bouton comme désactivé.

Il y a beaucoup de cas d'utilisation où un bouton désactivé a beaucoup de sens, et nous allons arriver à ces raisons dans un instant. Mais tout au long de cet article, nous examinerons un formulaire qui nous permet d'ajouter un certain nombre de billets à un panier.

Il s'agit d'un bon exemple de base car il y a une situation claire pour désactiver le bouton «Ajouter au panier»: lorsqu'il n'y a pas de billets à ajouter au panier.

Mais d'abord, pourquoi les boutons désactivés?

Empêcher les gens de faire une action invalide ou indisponible est la raison la plus courante pour laquelle nous pourrions atteindre un bouton désactivé. Dans la démo ci-dessous, nous ne pouvons ajouter des billets que si le nombre de billets ajoutés au panier est supérieur à zéro. Essayez-le:

Permettez-moi de sauter l'explication du code dans cette démo et de concentrer notre attention sur ce qui est important: le bouton «Ajouter au panier».

 <button type="soumi" d>
  Ajouter au panier
 bouton></button>

Ce bouton est désactivé par l'attribut désactivé. (Notez qu'il s'agit d'un attribut booléen, ce qui signifie qu'il peut être écrit comme désactivé ou désactivé = "Disabled".)

Tout semble bien… alors qu'est-ce qui ne va pas avec?

Eh bien, pour être honnête, je pourrais mettre fin à l'article ici en vous demandant de ne pas utiliser de boutons désactivés car ils sont nuls et utilisent plutôt de meilleurs modèles. Mais soyons réalistes: il est parfois désactivé un bouton qui est le plus logique.

Cela étant dit, à cette démo, nous prétendons que la désactivation du bouton «Ajouter au panier» est la meilleure solution ( alerte spoiler: ce n'est pas le cas). Nous pouvons toujours l'utiliser pour savoir comment cela fonctionne et améliorer sa convivialité en cours de route.

Types d'interactions

Je voudrais clarifier ce que j'entends par les boutons handicapés utilisables. Vous pouvez penser que si le bouton est désactivé, il ne devrait pas être utilisable, alors… qu'est-ce que la capture? Supporter avec moi.

Sur le Web, il existe plusieurs façons d'interagir avec une page. L'utilisation d'une souris est l'une des plus courantes, mais il y en a d'autres, comme des personnes voyantes qui utilisent le clavier pour naviguer en raison d'une altération du moteur.

Essayez de naviguer dans la démo ci-dessus en utilisant uniquement la touche de tabulation pour aller de l'avant et le décalage de l'onglet pour revenir en arrière. Vous remarquerez comment le bouton désactivé est ignoré. L'accent va directement de l'entrée du ticket dans le lien «Termes factice».

Arrêtons une seconde et récapitulons la raison qui nous a conduits à désactiver le bouton en premier lieu par rapport à ce que nous avions réellement accompli.

Il est courant d'associer «l'interaction» à «cliquer» mais ce sont deux concepts différents. Oui, C Lick est un type d'interaction, mais ce n'est qu'un entre autres, comme Hover et Focus.

Autrement dit…

Tous les clics sont des interactions, mais toutes les interactions ne sont pas des clics.

Notre objectif est d'éviter le clic, mais en utilisant les handicapés, nous empêchons non seulement le clic, mais aussi l'objectif, ce qui signifie que nous pourrions faire autant de mal que de bien. Bien sûr, ce comportement peut sembler inoffensif, mais il provoque une confusion. Les personnes handicapées cognitives peuvent avoir du mal à comprendre pourquoi ils ne sont pas en mesure de concentrer le bouton.

Dans la démo suivante, nous avons un peu modifié la disposition. Si vous utilisez une souris et survolez le bouton Soumettre, une info-bulle est affichée expliquant pourquoi le bouton est désactivé. C'est super!

Mais si vous n'utilisez que le clavier, il n'y a aucun moyen de voir cette infraction car le bouton ne peut pas être concentré avec les désactivés. La même chose se produit également dans les appareils tactiles. Aie!

Permettez-moi de passer à nouveau au-delà de l'explication du code. Je recommande fortement de lire les «Installations inclusives» de Haydon Pickering et «Info Tools in the Time of WCAG 2.1» de Sarah Higley pour bien comprendre le modèle d'info-bulle.

Aria à la rescousse

L'attribut désactivé dans un fait plus que nécessaire. C'est l'un des rares cas que je connaisse où un attribut HTML natif peut faire plus de mal que de bien. L'utilisation d'un attribut ARIA peut faire un meilleur travail, ce qui nous permet de demander aux lecteurs d'écran comment interpréter le bouton, mais faites-le de manière cohérente pour créer une expérience inclusive pour plus de personnes et d'utilisation des cas.

L'attribut désactivé est en corrélation avec aria-disabled = "true". Essayez la démo suivante, encore une fois, en utilisant uniquement le clavier. Remarquez comment le bouton, bien que marqué handicapé, est toujours accessible par la mise au point et déclenche l'influence!

Cool, hein? Un si petit ajustement pour une grande amélioration!

Mais nous n'avons pas encore fini. La mise en garde ici est que nous devons encore empêcher le clic par programme, en utilisant JavaScript.

 elform.addeventListener ('soumi', fonction (événement) {
  event.PreventDefault (); / * empêcher le formulaire natif soumettre * /

  const isdisabled = elbuttonsubmit.getAttribute («aria-disabled») === «true»;

  if (isDisabled || issumitting) {
    // revient tôt pour empêcher le billet d'être ajouté
    retour;
  }

  issumitting = true;
  // ... code à ajouter au panier ...
  issumitting = false;
})

Vous connaissez peut-être ce modèle comme un moyen d'empêcher les doubles clics de soumettre deux fois un formulaire. Si vous utilisiez l'attribut désactivé pour cette raison, je préférerais ne pas le faire car cela provoque la perte temporaire de la mise au point du clavier pendant la soumission du formulaire.

La différence entre les handicapés et la détention aria

Vous pourriez demander: si Aria-Hisabled n'empêche pas le clic par défaut, quel est l'intérêt de l'utiliser? Pour répondre à cela, nous devons comprendre la différence entre les deux attributs:

Le seul chevauchement entre les deux est la sémantique. Les deux attributs annonceront que le bouton est en effet désactivé, et c'est une bonne chose.

Contrairement à l'attribut handicapé, ARIA-Hissabled est une question de sémantique. Les attributs ARIA ne modifient jamais le comportement ou les styles de l'application par défaut. Leur seul objectif est d'aider les technologies d'assistance (par exemple, les lecteurs d'écran) pour annoncer le contenu de la page d'une manière plus significative et robuste.

Jusqu'à présent, nous avons parlé de deux types de personnes, de ceux qui cliquent et de ceux qui s'adaptent. Parlons maintenant d'un autre type: ceux qui ont des déficiences visuelles (par exemple la cécité, la basse vision) qui utilisent des lecteurs d'écran pour naviguer sur le Web.

Les personnes qui utilisent des lecteurs d'écran préfèrent souvent naviguer dans les champs de formulaire à l'aide de la touche Tab . Maintenant, regardez comment la voix off sur macOS saute complètement le bouton désactivé.

Encore une fois, c'est une forme très minimale. Dans une plus longue, la recherche d'un bouton de soumission qui n'est pas là peut être ennuyeux. Imaginez un formulaire où le bouton Soumettre est masqué et visible uniquement lorsque vous remplissez complètement le formulaire. C'est ce que certaines personnes ressentent lorsque l'attribut handicapé est utilisé.

Heureusement, les boutons avec handicapés ne sont pas totalement inaccessibles par les lecteurs d'écran. Vous pouvez toujours naviguer chaque élément individuellement, un par un, et finalement vous trouverez le bouton.

Bien que possible, c'est une expérience ennuyeuse. D'un autre côté, avec ARIA-Hissabled, le lecteur d'écran concentrera le bouton normalement et annoncera correctement son état. Notez que l'annonce est légèrement différente entre les lecteurs d'écran. Par exemple, NVDA et JWAS disent «bouton, indisponible», mais VoiceOver dit «bouton, tamisé».

J'ai cartographié comment les deux attributs créent différentes expériences utilisateur en fonction des outils que nous venons d'utiliser:

Ainsi, les principales différences entre les deux attributs sont:

• Les désactivés peuvent ignorer le bouton lors de l'utilisation de la touche de tabulation, conduisant à la confusion.
• Aria-hisabled concentrera toujours le bouton et annoncera qu'il existe, mais qu'il n'est pas encore activé; De la même manière que vous pourriez le percevoir visuellement.

C'est le cas où il est important de reconnaître la différence subtile entre l'accessibilité et la convivialité. L'accessibilité est une mesure de quelqu'un qui peut utiliser quelque chose. La convivialité est une mesure de la facilité d'utilisation de quelque chose.

Étant donné cela, les désactivés sont-ils accessibles? Oui . Cela a-t-il une bonne convivialité? Je ne pense pas .

Pouvons-nous faire mieux?

Je ne me sentirais pas bien avec moi-même si je terminais cet article sans vous montrer la véritable solution inclusive pour notre exemple de formulaire de billets. Dans la mesure du possible, n'utilisez pas de boutons désactivés . Laissez les gens cliquer dessus à tout moment et, si nécessaire, afficher un message d'erreur comme rétroaction. Cette approche résout également d'autres problèmes:

• Moins de friction cognitive: permettez aux gens de soumettre le formulaire à tout moment. Cela supprime l'incertitude de savoir si le bouton est même désactivé en premier lieu.
• Contraste des couleurs: Bien qu'un bouton désactivé n'ait pas besoin de répondre au contraste de couleur WCAG 1.4.3, je pense que nous devons garantir qu'un élément est toujours correctement visible quel que soit son état. Mais c'est quelque chose dont nous n'avons pas à nous soucier maintenant parce que le bouton n'est plus désactivé.

Réflexions finales

L'attribut handicapé dans est un cas particulier où, bien que très connu de la communauté, ce n'est peut-être pas la meilleure approche pour résoudre un problème particulier. Ne vous méprenez pas parce que je ne dis pas que les handicapés sont toujours mauvais. Il y a encore des cas où il est toujours logique de l'utiliser (par exemple, pagination).

Pour être honnête, je ne vois pas l'attribut handicapé exactement comme un problème d'accessibilité. Ce qui me concerne est davantage un problème d'utilisation. En échangeant l'attribut handicapé avec Aria-Hissabled, nous pouvons rendre l'expérience de quelqu'un beaucoup plus agréable.

C'est encore une étape de plus dans mon parcours sur l'accessibilité du Web. Au fil des ans, j'ai découvert que l'accessibilité est bien plus que de respecter les normes Web. Faire face aux expériences des utilisateurs est délicat et la plupart des situations nécessitent des compromis et des compromis dans la façon dont nous abordons une solution. Il n'y a pas de solution miracle pour une accessibilité parfaite.

Notre devoir en tant que créateurs Web est de rechercher et de comprendre les différentes solutions disponibles. Ce n'est qu'alors que nous pouvons faire le meilleur choix possible. Il n'y a aucun sens à prétendre que les problèmes n'existent pas.

En fin de compte, n'oubliez pas qu'il n'y a rien qui vous empêche de faire du Web un endroit plus inclusif.

Prime

Toujours là? Permettez-moi de mentionner deux dernières choses sur cette démo qui, je pense, sont dignes:

1. Les régions en direct annonceront le contenu dynamique

Dans la démo, deux parties du contenu ont changé dynamiquement: le bouton de soumission de formulaire et la confirmation de succès ("Ajout de billets [x]!").

Ces changements sont perçus visuellement, cependant, pour les personnes atteintes de déficiences de vision utilisant des lecteurs d'écran, ce n'est pas la réalité. Pour le résoudre, nous devons transformer ces messages en régions en direct. Ceux-ci permettent aux technologies d'assistance d'écouter les modifications et d'annoncer les messages mis à jour lorsqu'ils se produisent.

Il y a une classe .sr uniquement dans la démo qui cache un contenant un message de chargement, mais permet d'être annoncée par les lecteurs d'écran. Dans ce cas, Aria-live = "Assertive" est appliqué au et il détient un message significatif après la soumission du formulaire et est en cours de chargement. De cette façon, nous pouvons annoncer à l'utilisateur que le formulaire fonctionne et être patient tel qu'il se charge. De plus, nous faisons de même pour l'élément de rétroaction de formulaire.

 <bouton type="soumettre" aria-disabled="true">
  Ajouter au panier
  <span aria-live="assertive">
     
  </span>
 bouton>

<p aria-live="assertive">
  
</p></bouton>

Notez que l'attribut Aria-Live doit être présent dans le DOM dès le début, même si l'élément ne retient aucun message, sinon, les technologies d'assistance peuvent ne pas fonctionner correctement.

Il y a beaucoup plus à vous parler de ce petit attribut Aria-Live et des grandes choses qu'elle fait. Il y a aussi des gotchas. Par exemple, s'il est appliqué de manière incorrecte, l'attribut peut faire plus de mal que de bien. Il vaut la peine de lire «Utiliser Aria-Live» par Ire Aderinokun et les «Squelettes de chargement» d'Adrian Roselli pour mieux comprendre comment cela fonctionne et comment l'utiliser.

2. N'utilisez pas d'événements de pointeur pour éviter le clic

Il s'agit d'une implémentation alternative (et incorrecte) que j'ai vue sur le Web. Cela utilise des événements de pointeur: aucun; dans CSS pour éviter le clic (sans aucun attribut HTML). S'il vous plaît, ne faites pas cela. Voici un stylo laid qui, espérons-le, montrera pourquoi. Je le répète, ne fais pas ça.

Bien que CSS empêche en effet un clic de souris, n'oubliez pas qu'il n'empêchera pas la navigation de mise au point et du clavier, ce qui peut entraîner des résultats inattendus ou, pire encore, des bugs.

En d'autres termes, l'utilisation de cette règle CSS comme stratégie pour empêcher un clic est inutile (obtenez-le?). ;)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!