Test d’accessibilité

Objectifs de formation

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

Expliquer pourquoi il est essentiel d’effectuer des tests d’accessibilité manuels en plus des tests automatisés
Résumer les étapes à suivre pour effectuer des tests relatifs au clavier et à la gestion du focus sur MacOS
Identifier les vérifications à effectuer lors de la réalisation de tests de lecture d’écran avec VoiceOver
Reconnaître les éléments à inclure dans vos plans de test d’accessibilité
Décrire les stratégies pour réaliser efficacement des tests manuels de l’accessibilité

Importance des tests manuels

Bien que les tests d’accessibilité automatisés permettent de détecter de nombreux problèmes, ils ne tiennent pas compte du contexte et n’identifient pas les problèmes d’accessibilité plus nuancés. Parfois, ils passent même à côté de problèmes importants. C’est pourquoi il est essentiel de procéder également à des tests manuels pour repérer les obstacles que les tests automatisés n’ont pas permis d’identifier. Les tests manuels vous permettent également de confirmer la véracité des problèmes que vous avez découverts lors des tests automatisés et d’identifier les faux positifs.

Un développeur qui effectue des tests manuels d’accessibilité.

Contrairement aux tests d’accessibilité automatisés, les tests manuels évaluent le parcours utilisateur dans son ensemble afin de simuler l’expérience d’un utilisateur étant en situation de handicap ou utilisant une technologie d’assistance. Par exemple, les tests manuels relatifs au clavier simulent la manière dont un utilisateur navigue dans votre logiciel en utilisant uniquement un clavier, tandis que les tests manuels avec un lecteur d’écran simulent l’expérience utilisateur d’une personne malvoyante se servant de votre logiciel.

Examinons de plus près les tests manuels d’accessibilité, en commençant par ceux relatifs au clavier et à la gestion du focus.

Réalisation de tests relatifs au clavier et à la gestion du focus

Les tests relatifs au clavier et à la gestion du focus sont d’excellents moyens de s’assurer que les utilisateurs peuvent naviguer et interagir avec l’interface utilisateur de manière simple et attendue.

Lors des tests relatifs au clavier, posez-vous notamment les questions suivantes :

Le contenu est-il accessible par le biais d’entrées diverses ? Les utilisateurs doivent pouvoir naviguer dans le contenu à l’aide de divers périphériques d’entrée, tels que les commandes vocales, les écrans tactiles et les commandes de commutation. Si certains contenus ne sont disponibles qu’en survolant un élément avec la souris, les utilisateurs d’écrans tactiles, de dispositifs de dictée vocale et de claviers ne pourront pas les consulter.
L’ordre du focus est-il logique ? La notion d’ordre du focus fait référence à l’ordre dans lequel les éléments interactifs, tels que les liens, les boutons et les champs de formulaire, reçoivent le focus. Un ordre de focus illogique peut rendre la navigation difficile.
L’utilisateur peut-il naviguer dans le contenu avec efficacité et cohérence ? Des changements inattendus dans la navigation, tels que le recours à des saisies ou des commandes différentes, complexifient l’expérience de l’utilisateur final, en particulier s’il utilise des technologies d’assistance.
Tous les utilisateurs peuvent-ils naviguer dans ce contenu ? Tenez compte des personnes souffrant de troubles de la motricité, de la dextérité et de la vision.

Lors d’un test sur un Mac, vous devez activer l’accès complet au clavier dans les préférences système du clavier. Suivez ces étapes.

Activation de la navigation au clavier sur macOS

Ouvrez les paramètres Keyboard (Clavier) dans System Preferences (Préférences Système).
Sélectionnez l’onglet Shortcuts (Raccourcis).
Sous Full Keyboard Access (Accès complet au clavier), sélectionnez All controls (Toutes les commandes).

L’onglet Shortcuts (Raccourcis) de l’écran Keyboard Settings (Paramètres du clavier) dans MacOS avec le champ Full Keyboard Access (Accès complet au clavier) mis en évidence et l’option All controls (Toutes les commandes) sélectionnée.

Activation de l’accès au clavier pour Safari

Ouvrez la section Preferences (Préférences) de Safari.
Sélectionnez l’onglet Advanced (Avancé).
Sous Accessibility (Accessibilité), cochez la case Press Tab to highlight each item on a webpage (Appuyer sur Tab pour mettre en surbrillance chaque élément d’une page Web).

Les touches suivantes permettent de naviguer sur une page Web.

Utilisation :	Situation d’arrivée :
Tab et Maj + Tab	Naviguer à travers les liens, les champs de saisie et d’autres commandes interactives. En appuyant sur la touche Tab, vous vous déplacez en avant dans l’interface utilisateur et, en appuyant sur les touches Maj + Tab, vous vous déplacez en arrière. Ne vous inquiétez pas si vous ne pouvez pas tabuler chaque élément de la page, mais uniquement des éléments interactifs.
Ctrl + Tab	Naviguer dans les cadres.
Saisissez	Activer les liens.
Entrée et espace	Activer les boutons.
Lieu	Cocher les cases des champs de saisie et sélectionner les menus déroulants.
Flèche vers le haut et flèche vers le bas	Naviguer dans les menus, les listes de sélection et les menus déroulants de saisie automatique.
Flèche vers la gauche et flèche vers la droite	Naviguer dans les onglets d’un ensemble d’onglets ou d’un carrousel.
Esc	Fermer les menus, les boîtes de dialogue modales et les panneaux.

Pouvez-vous atteindre chaque élément interactif et déclencher son action ?

Certains composants complexes avec plusieurs éléments interactifs ont des interactions clavier plus spécifiques que les interactions de base, notamment les listes déroulantes, les menus, les grilles de données, les boîtes de dialogue non modales et modales, et les ensembles d’onglets. Ces interactions clavier suivent certaines attentes définies par les pratiques de création ARIA du World Wide Web Consortium (W3C).

Salesforce conçoit ses directives relatives au clavier selon ces attentes, et ces directives sont utilisées dans les bibliothèques de composants React de Lightning et Lightning Design System. Nous avons compilé des ressources utiles sur le site Lightning Design System 2 pour vous aider à créer et à tester ces composants.

Consignes d’accessibilité pour les interactions au clavier : une liste de contrôle des tests manuels du clavier
Recommandations générales d’accessibilité relatives au focus : conseils sur le comportement attendu pour la gestion du focus
Accessibilité : spécifications HTML et d’interaction pour les widgets/modèles courants

Test de la navigation au clavier

Lorsque vous testez la navigation au clavier, vérifiez que les points suivants sont respectés :

L’ordre de tabulation est logique. Utilisez le clavier pour naviguer dans votre application. L’ordre de navigation par défaut doit être logique et naturel.
Le focus du clavier est visible. Utilisez le clavier pour naviguer dans une page et confirmez qu’un indicateur visuel affiche l’élément qui a le focus clavier.

Les éléments exploitables reçoivent le focus. Utilisez le clavier pour naviguer dans une page. Vérifiez que tous les boutons, liens, champs de formulaire, onglets et autres éléments interactifs peuvent accepter le focus du clavier. Si un utilisateur peut cliquer sur un élément pour effectuer une action ou le survoler pour révéler des informations, cet élément doit accepter le focus du clavier.

Les éléments interactifs peuvent être parcourus. Vérifiez que vous pouvez naviguer dans tous les éléments interactifs tels que les menus, les boîtes de dialogue, les éléments fonctionnant par glisser-déposer, les ensembles d’onglets, les panneaux et les listes déroulantes de saisie automatique. Vérifiez que vous pouvez utiliser le clavier pour sélectionner et activer des éléments.

Les boîtes de dialogue contextuelles peuvent être parcourues. Utilisez le clavier pour ouvrir et naviguer dans une boîte de dialogue modale et utiliser toutes les commandes qu’elle contient. Vérifiez que vous ne pouvez interagir qu’avec la fenêtre modale actuelle, et non avec la page qui se trouve derrière. Lorsqu’une boîte de dialogue modale est ouverte, le focus doit se trouver exclusivement à l’intérieur. Assurez-vous que lorsque la boîte de dialogue modale est fermée, le focus revient au bon endroit sur la page.

Gardez à l’esprit que les tests relatifs au clavier et ceux réalisés avec des lecteurs d’écran ne sont pas une seule et même chose. Effectuer des tests relatifs au clavier avant de réaliser des tests avec un lecteur d’écran permet de mettre en évidence de nombreux problèmes qu’un lecteur d’écran pourrait ne pas déceler.

Nous vous recommandons de tester les lecteurs d’écrans à la fois sur macOS et Windows. MacOS dispose d’un lecteur d’écran intégré appelé VoiceOver, qui énonce à haute voix l’élément sélectionné et lit son étiquette ou son texte alternatif. Lorsque vous effectuez un test avec un lecteur d’écran, vérifiez si votre texte alternatif est exact, puis procédez aux ajustements nécessaires.

Voici quelques vérifications simples que vous pouvez effectuer avec VoiceOver sur MacOS.

Utilisez Cmd + F5 pour activer ou désactiver VoiceOver.
Utilisez Cmd + u pour ouvrir le rotor Web.
Utilisez le rotor Web pour vérifier ce qui suit :
- Les liens et les boutons ont des étiquettes concises et pertinentes.
- Les titres sont dans le bon ordre.
- La page comporte des repères adéquats.
Parcourez l’interface utilisateur avec la touche Tab pour vérifier ce qui suit :
- Les champs modifiables énoncent leur étiquette, le type d’entrée et le mot modifier.
- Les ensembles d’onglets indiquent quel onglet est sélectionné et peuvent être parcourus avec les flèches du clavier.
- Les cases à cocher annoncent leur état de manière audible lorsqu’elles sont activées avec la barre d’espace.

Ne vous inquiétez pas si vous ne pouvez pas accéder à chaque élément de contenu en parcourant une interface utilisateur à l’aide d’un lecteur d’écran. Comme les utilisateurs de lecteurs d’écran disposent de raccourcis clavier spécifiques pour naviguer d’un élément à l’autre dans la page (cela inclut les éléments non interactifs), la touche Tab n’est pas censée (et ne devrait pas) tout atteindre. Avec VoiceOver, vous pouvez utiliser Ctrl + Option + Flèche vers la gauche ou Ctrl + Option + Flèche vers la droite pour lire le contenu de la page linéairement en arrière ou en avant, respectivement.

Sous Windows, nous vous recommandons d’utiliser NVDA.

Effectuez des tests d’accessibilité avec plusieurs lecteurs d’écran. Si vous n’effectuez des tests qu’avec VoiceOver, vous risquez de passer à côté de problèmes spécifiques que d’autres lecteurs d’écran, tels que JAWS ou NVDA, détecteront.

Si vous effectuez des tests avec un lecteur d’écran alors que vous n’en utilisez pas régulièrement, vous allez être confronté régulièrement à des erreurs d’utilisation. Consultez les vidéos A11ycasts dans la section Ressources pour en savoir plus sur les subtilités de l’utilisation des lecteurs d’écran.

Création de plans de test d’accessibilité

Intégrez l’accessibilité à votre plan de test en l’incluant dans les spécifications des composants, les critères d’acceptation et les récits utilisateur.

Exemple : Lanceur d’application

Pour ouvrir le lanceur d’application, sélectionnez . Dans le lanceur d’application, les utilisateurs peuvent rechercher des applications, les ouvrir, lire leur description et les réorganiser.

Lanceur d’application avec la section All Apps (Toutes les applications) développée.

Quels cas de test pouvez-vous créer pour réorganiser les applications ?

Voici un exemple de plan de test relatif à différents cas d’utilisation associés au lanceur d’application.

Pour contextualiser, ici, le terme « fonctionnalité » fait référence à ce qu’un produit ou un système est capable de faire, c’est-à-dire ses fonctionnalités et ses actions. Le « résultat » est un élément de conception qui suggère comment un objet devrait être utilisé en fonction de son apparence ou de son comportement.

Type	Souris	Clavier	Lecteur d’écran
Fonctionnalité	Cliquer sur la vignette permet d’ouvrir l’application	Appuyer sur Entrée sur la vignette permet d’ouvrir l’application	Le clavier fonctionne selon le comportement attendu
Résultat	La vignette a un curseur de déplacement lorsqu’elle est survolée	Le bouton de déplacement de la vignette comporte un indicateur de focus visuel distinct	L’utilisateur est informé des interactions possibles
Fonctionnalité	Cliquer et maintenir la vignette permet d’amorcer le glissement	La touche espace permet de lancer le mode de glissement	État de saisie, position et instructions lues lorsque l’utilisateur passe en mode de glissement
Résultat	Le mode de glissement a un état visuel distinct (vignette à angle avec bordure bleue)	Le mode de glissement a un état visuel distinct (vignette à angle avec bordure bleue)
Fonctionnalité	Déplacer la souris lors du glissement de la vignette	Les flèches du clavier permettent de déplacer l’application vers la position suivante/précédente dans la liste
Résultat	L’utilisateur voit un aperçu de la position de l’application	L’utilisateur voit un aperçu de la position de l’application	La position de l’application est lue à haute voix quand elle change
Fonctionnalité	Le relâchement de la souris permet de mettre fin au glissement	La touche Entrée permet de quitter le mode de glissement	Lecture de la position finale et de l’état de saisie lorsque l’utilisateur quitte le mode de glissement

Quels autres cas de test pouvez-vous ajouter ? Comment feriez-vous pour les tester ? Bien que vous puissiez éventuellement écrire des tests automatisés relatifs aux attributs du lecteur d’écran et au comportement du clavier, il vous faudra toujours effectuer des tests manuels pour vous assurer que l’expérience est fluide.

Utilisation de stratégies de test manuel

Prêt à mettre en application tout ce que vous avez appris ? Voici quelques stratégies permettant d’effectuer des tests d’accessibilité manuels efficaces.

Création d’un plan de test

Vous pouvez inclure les points suivants :

Appel de $A.test.assertAccessible pour les états visuels clés (pour les tests de composants).
Vérification manuelle de l’enchaînement des actions au clavier.
Prise en compte d’autres facteurs propres à votre cas d’utilisation.

Tests précoces et fréquents

Lors de la création d’interfaces utilisateur :

effectuez des tests manuels ;
activez l’automatisation des tests ;
recherchez des opportunités de vous concentrer sur l’accessibilité via la réalisation de tests personnalisés.

Journal et correction des bugs

Chez Salesforce, nous donnons la priorité aux bogues d’accessibilité, quel que soit le nombre d’utilisateurs qu’ils concernent. Ces bogues peuvent constituer un obstacle fondamental à la réalisation du travail des utilisateurs concernés. Quelle que soit la priorité que votre organisation accorde aux bogues, préconisez de réduire au minimum les problèmes d’accessibilité non résolus.

En effectuant des tests d’accessibilité automatisés et manuels et en supprimant les obstacles à l’accessibilité, vous proposez une expérience numérique véritablement inclusive à laquelle tout le monde peut participer et dont tout le monde peut profiter !

Durée estimée

Thèmes