Commandes personnalisées

Conception de contrôles personnalisés

Cette section donne un aperçu de haut niveau des éléments à prendre en considération lors de l’élaboration de commandes de formulaire personnalisées. La Spécification ARIA et les Pratiques de rédaction ARIA expliquent comment utiliser ARIA (Accessible Rich Internet Applications) pour créer des widgets personnalisés. Les pratiques de rédaction décrivent le comportement attendu des widgets du clavier et de la cible, ainsi que des exemples et le code.

Voir le module 12 pour une discussion sur les widgets JavaScript personnalisé.

Suivez les pratiques exemplaires suivantes pour les commandes personnalisées :

• Dans la mesure du possible, utiliser des éléments de formulaire HTML natifs plutôt que des commandes personnalisées.
• Modéliser le comportement d’après les éléments de formulaire HTML natifs.
• Ajouter un nom, un rôle et des valeurs ARIA appropriés.
• Communiquer des mises à jour et des changements d’état par l’entremise de messages en direct sur ARIA lorsqu’ils ne peuvent pas être communiqués par l’entremise de méthodes HTML ou ARIA

Dans la mesure du possible, utiliser un élément de formulaire HTML natif plutôt qu’une commande personnalisée.

Les liens HTML standard et les commandes de formulaire n’ont pas besoin de JavaScript personnalisé pour fonctionner. Ils fonctionnent immédiatement, recevant la cible et répondant aux frappes du clavier. Les utilisateurs comprennent déjà ces éléments; il n’est donc pas nécessaire de fournir des instructions.

Modéliser le comportement d’après les éléments de formulaire HTML natifs.

Si vous créez une version personnalisée d’un élément de formulaire natif, modélisez-le d’après l’élément original, y compris la duplication du comportement attendu du clavier (p. ex., les commandes reçoivent la cible, les boutons sont activés avec la touche d’espacement ou d’entrée, les cases à cocher sont cochées ou décochées à l’aide de la touche d’espacement, les boutons radio sont sélectionnés avec la touche fléchée).

Si votre élément de formulaire doit être différent des éléments de formulaire natifs, les éléments de formulaire HTML natifs sont encore un modèle de comportement souhaitable au clavier. Assurez-vous que tous les boutons fonctionnent avec la touche Entrée et la barre d’espacement. Mettez en place des touches fléchées que les utilisateurs pourraient s’attendre à utiliser. Voir les interactions au clavier des modèles de widgets et des rôles ARIA dans les Pratiques de rédaction ARIA.

Réfléchissez à deux fois avant de créer une commande personnalisée. Il peut s’agir d’un travail considérable, comme le décrit le tutoriel du Mozilla Developer Network How to build custom form controls (Comment construire des widgets de formulaires personnalisés), qui consiste à créer un élément personnalisé <select>.

Ajouter le bon ARIA name, role, and values

Les utilisateurs de lecteurs d’écran se fient à quelques éléments d’information clés pour comprendre une interface. Critère de succès 4.1.2 des WCAG : Nom, rôle, valeur expliquez-les en détail :

Pour tous les composants d’interface utilisateur (y compris, sans s’y limiter, les éléments de formulaire, les liens et les composants générés par les scripts), le nom et le rôle peuvent être déterminés par un programme; les états, les propriétés et les valeurs pouvant être définies par l’utilisateur peuvent être définies par un programme; et les avis de modification touchant ces éléments sont mis à la disposition des agents utilisateurs, y compris des technologies d’assistance.

Name

Le nom définit l’étiquette de l’élément (p. ex., « précédent », ou « suivant » ou « enregistrer » ou « soumettre »). Une commande personnalisée définit souvent le nom au moyen de l’attribut aria-label ou aria-labelledby.

Role

Le rôle définit ce qu’est ou fait le widget. La spécification ARIA définit une liste de rôles parmi lesquels choisir, comme « case à cocher », « groupe radio » ou « barre de défilement » ou « tabulateur ».

Value

La valeur, parfois plusieurs valeurs, définit les « états » dynamiques et les « propriétés » statiques de la commande :

States

Les « états » sont des attributs ARIA avec des valeurs que le script met à jour en réaction à l’utilisateur. Par exemple, aria-selected="true", aria-expanded="false" et la valeur en pourcentage d’une barre de défilement.

Properties

Les « propriétés » sont des attributs ARIA dont les valeurs ont tendance à ne pas changer. Par exemple, aria-labelledby ou aria-describedby ou aria-required.

Communiquer des mises à jour et des changements d’état par l’entremise de messages en direct sur ARIA lorsqu’ils ne peuvent pas être communiqués par l’entremise de méthodes HTML ou ARIA

Lorsque les états HTML et ARIA disponibles ne sont pas suffisamment descriptifs, ajouter une zone live ARIA pour décrire aux utilisateurs d’un lecteur d’écran ce qui se passe. Une zone live ARIA peut annoncer une modification personnalisée de la valeur comme « Tableau trié par titre, croissant » ou « Résultats filtrés par zone », etc.

<form action="path/to/submit">
   <button type="submit" id="share-btn" class="btn-primary">
      <span class="count">3</span> 
      <span class="text">Partages</span>
   </button> 
</form>

document.getElementById('share-btn').addEventListener('click', function(event){ 
   event.preventDefault();    
   event.stopImmediatePropagation();
   var count = this.querySelector('.count');
   var text = this.querySelector('.text');
   count.textContent = parseInt(count.textContent) + 1;
   text.textContent = "Partagés ✓"; 
   this.setAttribute("disabled", "true"); 
});

Adapté de « Custom Form Inputs » dans le module « Form Labels, Instructions, and Validation ». Deque University. 2021 Deque Systems Inc.

Bon exemple de code tiré du document de l’Initiative d’accessibilité du Web (IAT) : Commandes personnalisées (IAT) (en anglais seulement), dans Concepts de formulaires. Eric Eggert et Shadi Abou-Zahra, éd. Copyright © 2019 W3C® (MIT, ERCIM, Keio, Beihang). État d’avancement : Ébauche mise à jour le 27 juillet 2019.

Ressources WCAG connexes