Codage de composants accessibles

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

• Identifier les ensembles de composants inclus dans l’infrastructure de composants Lightning
• Répertorier les étapes de création de composants accessibles
• Répertorier les étapes de création de composants Web personnalisés

Introduction

L’infrastructure des composants Lightning met à votre disposition un ensemble de composants entièrement fonctionnels. Ils reposent tous sur les plans de composants SLDS les plus récents, qui suivent les recommandations appropriées sur l’accessibilité. Dans la mesure du possible, utilisez ces composants existants. Ils ont été approuvés pour l’accessibilité et vous feront gagner du temps. Pour en savoir plus sur ces composants, consultez la référence des composants. 

Utilisation de composants

La référence des composants comprend des informations au sujet de deux ensembles différents de composants, les composants Aura et les composants Web Lightning. Les composants Aura qui y sont répertoriés appartiennent à de nombreux espaces de noms différents. Les composants des espaces de noms ui et force ont été développés pour répondre à une spécification ARIA plus ancienne, et ne sont désormais plus les composants les plus accessibles. 

Les composants Web Lightning (LWC) constituent le meilleur moyen de créer une interface utilisateur avec Salesforce. Consultez le module Migration de composants Aura vers des composants Web Lightning pour apprendre à utiliser les LWC et à vous conformer aux normes Web actuelles. Si vous souhaitez en savoir plus sur Aura, consultez le guide du développeur de composants Aura Lightning ou la documentation sur les composants Aura. 

Les composants Web Lightning débutant par le préfixe lightning- sont écrits selon la norme ARIA la plus récente et suivent les derniers plans de composants SLDS. Dans la mesure du possible, utilisez ces composants plutôt que des équivalents plus anciens. 

Lorsque vous utilisez des composants Lightning, tenez toujours compte de l’accessibilité. Par exemple, lorsque vous placez une icône d’information en utilisant <lightning-icon>, il vous faudra spécifier une valeur alternative-text appropriée pour décrire le but de l’icône à l’utilisateur. Lorsque vous utilisez <lightning-input>, il vous faudra spécifier une valeur label pour associer par programmation le résultat de l’élément <input> à l’élément <label>. L’instruction required="true" rend l’entrée obligatoire de manière accessible.

De nombreux composants Lightning disposent également d’attributs pour définir les propriétés ARIA. Bien que ceux-ci ne soient pas obligatoires pour l’accessibilité, nous les incluons au cas où vous auriez besoin de définir ces valeurs. 

Création de composants

Si vous ne trouvez pas le composant dont vous avez besoin dans notre référence des composants, vous devrez peut-être créer votre propre composant Lightning. Pour ce faire, réalisez les étapes suivantes pour vous assurer qu’il est accessible.

1. Commencez toujours par les plans de composants SLDS. Examinez attentivement le balisage ainsi que les rôles, états et propriétés ARIA. Prenez note des attributs requis et des attributs qui changent lorsque l’utilisateur interagit avec votre composant.
2. Implémentez des interactions clavier. N’oubliez pas que les rôles ARIA représentent une promesse pour vos utilisateurs. Cette promesse consiste notamment à fournir la fonctionnalité de saisie clavier attendue par les utilisateurs compte tenu du rôle que vous avez spécifié. Nos plans de composants incluent des instructions de navigation au clavier.

Conseil : ne prêtez pas attention aux événements d’appui sur la touche de tabulation. Prenez plutôt le focus en considération. Les utilisateurs de lecteurs d’écran utilisent rarement la touche de tabulation pour parcourir une page.

• Gérez le focus de l’utilisateur. Suivez nos recommandations générales sur le focus pour vous assurer que les éléments interactifs sont adaptés au focus.
• Écrivez l’automatisation et testez manuellement vos composants. 
  1. Rédigez des tests d’intégration pour les interactions clavier. Le seul moyen fiable de tester les interactions clavier est d’utiliser un navigateur réel. Ne comptez pas sur l’inspection manuelle du DOM pour détecter les régressions. Rédigez des tests afin de garantir l’exactitude du balisage, notamment pour :
     • corriger la sémantique sur le bon nœud ;
     • corriger les attributs définis sur le bon nœud ;
     • corriger les valeurs d’attribut mises à jour au cours du cycle de vie des composants.
  2. Effectuez un test de bout en bout manuel des fonctionnalités en utilisant uniquement votre clavier et en suivant les spécifications SLDS. Veillez à ce que tout puisse être fait avec un clavier.

Composants Web

Les composants Web constituent une fonctionnalité de navigateur qui fournit un modèle de composant standard pour le Web, formé de plusieurs éléments gérés à différents endroits : les DOM fantômes, les éléments personnalisés, les modèles HTML et les modifications CSS (source). En pratique, la racine des composants Web est un élément personnalisé. Ces éléments personnalisés n’ont aucune valeur sémantique, mais peuvent entraîner des problèmes de descendance directe pour les technologies d’assistance. 

Problèmes de descendance directe

Si vous créez une liste non numérotée <ul> comportant des éléments de liste de composants Web <lightning-example-list-item>, votre balisage se présente comme suit :

<ul>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
</ul>

Il n’est cependant pas accessible, car chaque enfant d’un élément <ul> doit être un élément <li>. Les lecteurs d’écran ne peuvent pas reconnaître qu’il s’agit d’une liste de trois éléments. Il est préférable dans ce cas de s’appuyer sur des rôles ARIA plutôt que sur des éléments sémantiques.

À la place d’un élément <ul>, nous pouvons utiliser un autre composant Web avec role="list". Nos composants Web d’élément de liste auraient alors besoin de role="listitem", et nous n’utiliserions pas d’éléments <li>. Le code ci-dessous permet aux lecteurs d’écran d’identifier correctement une liste de trois éléments.

<lightning-example-list>
<div role="list">
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item”>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
</div>
</lightning-example-list>

Attributs HTML généraux

N’utilisez pas d’attributs HTML généraux pour définir des attributs sur les éléments internes. Lorsque vous définissez un attribut HTML général sur l’hôte avec les composants Web Lightning, notre infrastructure suppose que vous souhaitez qu’il se trouve sur l’hôte, même si vous le transmettez également en aval. Si vous utilisez par exemple l’attribut aria-describedby sur un composant Web d’entrée en tant qu’API pour définir l’attribut sur l’enfant, vous le définissez par inadvertance deux fois.

<lightning-example-input aria-describedby="foo">

Le code ci-dessus est restitué ainsi :

<lightning-example-input aria-describedby="foo">
  <input aria-describedby="foo" />
</lightning-example-input>

Au lieu de cela, appliquez une casse mixte au nom d’API de votre composant Web, comme dans l’exemple suivant :

<lightning-example-input ariaDescribedby="foo">

Le code est ainsi restitué de manière appropriée :

<lightning-example-input>
  <input aria-describedby="foo" />
</lightning-example-input>

Pour en savoir plus sur les noms de propriété et d’attribut, notamment sur l’utilisation de la casse mixte, reportez-vous à la section Ressources.

DOM fantôme

Lorsque le DOM fantôme est activé, les composants Web présentent des problèmes d’accessibilité supplémentaires. De nombreux aspects de l’accessibilité Web reposent sur des références d’ID de composant reliant différents éléments de la page. L’étiquetage des entrées de formulaire en est un exemple simple.

<label for="foo">First Name</label>
<input type="text" id="foo" />

Dans l’exemple de code ci-dessus, l’ID "foo" associe l’étiquette « First Name » (prénom) à la saisie de texte. Si l’étiquette et l’entrée étaient ensuite placées dans des composants Web distincts à cause du DOM fantôme, cette relation n’existerait plus dans l’arbre d’accessibilité du navigateur.

<lightning-example-label>
     <label for="foo">First Name</label>
</lightning-example-label>
<lightning-example-input>
     <input type="text" id="foo" />
</lightning-example-input>

Dans ce scénario, l’étiquette et l’entrée ne sont plus associées et le formulaire n’est plus accessible. La solution consiste à ne pas séparer les éléments en différents éléments personnalisés lorsqu’une relation de référence d’ID est requise.

<lightning-example-input>
     <label for="foo">First Name</label>
     <input type="text" id="foo">
</lightning-example-input>

Lorsque vous créez vos propres composants Web personnalisés, étudiez les plans SLDS et les spécifications de conception ARIA. Identifiez les propriétés HTML et ARIA qui reposent sur des références d’ID, et ne séparez jamais ces éléments en racines fantômes distinctes.

Un groupe du W3C développe actuellement le Accessibility Object Model, ou modèle d’objet d’accessibilité. Il s’agit d’une approche qui propose des méthodes pour attribuer des rôles et des propriétés, mettre à jour des états et créer des relations sans s’appuyer sur des attributs HTML et des références d’ID. Bien que ce modèle soit encore en cours d’élaboration, il offrira un meilleur contrôle sur l’accessibilité des composants Web une fois qu’il sera adopté par les navigateurs, les technologies d’assistance et la communauté de développement.

Que le spectacle continue !

Vous avez maintenant découvert les concepts de base de la création d’interfaces utilisateur accessibles. Consultez également les ressources Trailhead une fois que vous vous sentez prêt à concevoir et à tester l’accessibilité. Rejoignez aussi notre vaste communauté d’administrateurs et de développeurs sur la Trailblazer Community de Salesforce pour partager des idées, rejoindre des groupes, lire des témoignages de réussite, et plus encore. 

Ressources

• Documentation : W3C – Normes et projets
• Référence des développeurs Salesforce : Composants Web Lightning
• Référence des développeurs Salesforce : Noms de propriété et d’attribut
• Documentation : Accessibility Object Model (modèle d’objet d’accessibilité)
• Aide Salesforce : Plans de composants
• Documentation : W3C – Spécifications sur les composants Web