5 étapes pour concevoir des applications avec l'accessibilité du clavier à l'esprit

Quand on pense à l'utilisateur « moyen », on a tendance à l'imaginer utilisant une souris ou un trackpad lorsqu'il est sur son ordinateur. Mais que se passerait-il si leur option préférée ou unique était d'utiliser un clavier ? Avez-vous pensé à concevoir vos applications en gardant à l'esprit l'accessibilité du clavier ?

Il existe de nombreuses raisons pour lesquelles une personne peut ne pas vouloir ou ne pas pouvoir utiliser une souris ou un trackpad pour utiliser son ordinateur. Ils peuvent avoir des conditions permanentes, chroniques ou temporaires qui limitent leur dextérité ou leur contrôle musculaire, provoquant une sensibilité des poignets ou des mains, ou rendant difficile le suivi du curseur de la souris sur un écran. Ils peuvent également être des "utilisateurs expérimentés" à la recherche de plus de raccourcis pour rationaliser leurs flux de travail. Dans tous ces cas, les claviers peuvent être le moyen préféré ou nécessaire d'un individu pour interagir avec la technologie.

Dans cet article, vous découvrirez les directives d'accessibilité du clavier, ainsi que cinq étapes à garder à l'esprit lors de la conception d'applications pour vous assurer qu'elles sont accessibles au clavier.

Comment fonctionne l'accessibilité au clavier ?

Si une application est accessible au clavier, cela signifie que les utilisateurs ont la possibilité d'utiliser uniquement un clavier pour faire fonctionner les éléments de contrôle . Les éléments de contrôle sont tous les composants interactifs de la page, tels que les boutons, les liens, les entrées de formulaire, les vidéos et tout autre contenu interactif.

Principes de base de la navigation au clavier

Voici quelques touches de base utilisées pour la navigation au clavier :

• Naviguer vers l'élément de contrôle suivant : Tabulation (ou la touche fléchée vers la droite ou vers le bas pour les boutons radio associés et sélectionner les options)
• Naviguer vers l'élément de contrôle précédent : Maj + Tabulation (ou la touche fléchée vers la gauche ou vers le haut pour les boutons radio associés et sélectionner les options)
• Clic sur un élément de contrôle : Entrée et/ou barre d'espace
• Naviguer entre les boutons radio associés ou sélectionner des options : Touches fléchées

Ordre de mise au point

La séquence dans laquelle les éléments de contrôle peuvent répondre aux événements du clavier est connue sous le nom d' ordre de mise au point . Lorsqu'un élément est ciblé, vous pouvez interagir avec lui à l'aide de certaines commandes du clavier. Lorsqu'un élément perd le focus, il devient flou. Les navigateurs affichent les états de focus par défaut pour aider les utilisateurs à savoir quel élément est actuellement en focus.

Vous aimerez peut-être aussi : Conception universelle : 11 conseils pratiques pour rendre vos sites et applications plus accessibles.

Accessibilité au clavier et directives pour l'accessibilité des contenus Web (WCAG)

Les Web Content Accessibility Guidelines (WCAG) définissent trois niveaux de conformité (niveau A, niveau AA et niveau AAA) qui ont été adoptés comme normes pour les lois régionales ou nationales sur l'accessibilité du Web dans le monde entier.

L'accessibilité du clavier est l'un des critères de réussite pour la conformité au niveau A. Les critères de niveau A décrivent les fonctionnalités indispensables pour tout contenu Web. Ils sont également considérés comme les plus faciles à mettre en œuvre.

"L'accessibilité du clavier est également facile à se tromper si nous ne faisons pas attention."

Cela dit, l'accessibilité du clavier est également facile à se tromper si nous ne faisons pas attention. Voici des exemples de problèmes courants d'accessibilité au clavier rencontrés sur le Web :

• États de mise au point imperceptibles
• Ordre de mise au point incorrect
• Éléments interactifs qui ne peuvent pas recevoir le focus
• Composants complexes qui ne captent pas les interactions du clavier

Heureusement, il existe de nombreuses techniques que nous pouvons utiliser pour garder à l'esprit les utilisateurs de clavier et éviter de commettre ces erreurs dans nos propres applications.

5 étapes pour créer des applications accessibles au clavier

1. Concevoir des interactions intuitives

Lorsque nous rendons des éléments de contrôle simples sans comportements personnalisés, nous pouvons généralement tirer parti de leurs fonctionnalités d'accessibilité au clavier intégrées. Mais, si nous ne connaissons pas les comportements de clavier standard associés aux boutons, liens ou entrées, nous pouvons créer par inadvertance des expériences déroutantes pour les utilisateurs de clavier.

"Si nous ne connaissons pas les comportements de clavier standard associés aux boutons, liens ou entrées, nous pouvons créer par inadvertance des expériences déroutantes pour les utilisateurs de clavier."

Par exemple, les développeurs utilisent parfois CSS pour masquer les boutons radio HTML natifs au profit de visuels plus stylisés. Il n'est pas évident que les entrées soient des boutons radio dans les coulisses, de sorte que les utilisateurs du clavier peuvent ne pas se rendre compte qu'ils doivent utiliser les touches fléchées, et non la touche Tab, pour déplacer le focus entre les options associées.

Pour éviter ce problème, nous devrions afficher quelque chose qui ressemble au moins à l'élément HTML natif pour fournir des repères visuels à quiconque veut ou a besoin d'interagir avec lui à l'aide d'un clavier.

2. Créez votre application pour qu'un clavier puisse faire tout ce qu'une souris peut faire

Soyez conscient des éléments qui ne sont pas fournis avec les fonctionnalités d'accessibilité du clavier intégrées. Les éléments de mise en page, les listes, les tableaux, les en-têtes, les paragraphes et les balises HTML non sémantiques ne prennent pas en charge les raccourcis clavier par défaut. Et pourtant, ils sont fréquemment utilisés pour créer des composants plus complexes, comme des onglets, des listes de glisser-déposer ou des modaux.

JavaScript nous permet d'ajouter des écouteurs d'événements qui font que les éléments non contrôlés répondent aux clics ou aux gestes de la souris. Dans React, par exemple, nous pouvons utiliser la prop onClick pour ajouter de l'interactivité à un élément d'élément de liste.

Chaque fois que nous ajoutons de l'interactivité à des éléments non contrôlés, nous devons définir leur attribut tabIndex sur 0 . Cela permettra à l'élément de recevoir le focus dans le bon ordre de focus lorsque la touche Tab est enfoncée. Nous devons également implémenter des gestionnaires d'événements keypress ou keydown pour enregistrer les "clics" via la touche Entrée et/ou la barre d'espace (les liens peuvent être cliqués en utilisant les deux, tandis que les boutons ne prennent en charge que la touche Entrée).

Nous pouvons éviter une partie de ce travail supplémentaire en utilisant à la place des contrôles tels que des balises d'ancrage ou des éléments de bouton. Nous pouvons toujours utiliser CSS pour remplacer les styles de lien et de bouton par défaut et faire en sorte que l'élément interactif s'étende sur toute la largeur de son parent non interactif pour maximiser la zone cible.

Que nous utilisions ou non des éléments de contrôle pour les fonctionnalités non natives, nous devrons peut-être encore ajouter des écouteurs d'événements pour les touches fléchées (pour naviguer entre les onglets d'un composant d'onglet) ou la touche Échap (pour fermer une superposition) pour rendre notre composant 100 pour cent accessible au clavier.

Si nous implémentons des comportements de clavier non standard pour un composant plus complexe, il est utile de fournir des instructions visibles décrivant les commandes du clavier que les utilisateurs peuvent utiliser pour interagir avec le composant.

3. Faites le travail supplémentaire lorsque vous remplacez l'ordre de mise au point par défaut

L'ordre de mise au point est une autre exigence WCAG étroitement liée à l'accessibilité du clavier. Pour répondre aux critères de niveau A, l'ordre de mise au point doit être cohérent avec la séquence visuelle des éléments interactifs sur la page. Les utilisateurs de clavier doivent pouvoir naviguer dans les éléments de contrôle à l'écran de haut en bas et dans la même direction horizontale que votre contenu textuel (de gauche à droite ou de droite à gauche).

Le moyen le plus simple de répondre à ce critère est de laisser tel quel l'ordre de focus par défaut, qui est déterminé par l'ordre dans lequel les éléments sont disposés dans le balisage . Nous courons le risque de ne pas respecter ce critère lorsque nous introduisons des écarts entre l'ordre visuel des éléments de contrôle et la façon dont ils sont disposés dans le code source.

Vous aimerez peut-être aussi : Construire une navigation par fil d'Ariane accessible avec Liquid et Shopify.

Si nous utilisons la capture d'écran ci-dessus comme exemple, disons que nous voulions que la carte "Mettre à jour les balises" change de position avec la carte "Mettre à jour la description" lorsqu'elles s'empilent pour des fenêtres plus étroites. Si les cartes sont rendues sous forme d'éléments flexibles, nous pourrions envisager d'utiliser la propriété CSS order pour modifier leur séquence à un point d'arrêt spécifique.

Bien que la propriété order affecte la séquence visuelle des éléments flexibles, elle ne met pas à jour leur disposition dans le code source. Par conséquent, lorsqu'un utilisateur appuie sur la touche Tab pour naviguer entre chaque bouton, le bouton "Mettre à jour les balises" recevra toujours le focus avant "Mettre à jour la description", même s'ils sont affichés dans l'ordre inverse à l'écran. Cela provoque un déplacement inattendu de la mise au point vers le haut et vers le bas de la page, créant une expérience désorientante pour l'utilisateur.

Une façon d'éviter ce problème consiste à afficher deux versions des cartes dans le balisage : une dans l'ordre attendu pour les largeurs de fenêtre plus larges et une autre dans l'ordre souhaité pour les largeurs de fenêtre plus étroites. Nous pouvons utiliser la propriété display pour basculer entre eux à certains points d'arrêt.

Si nous ne voulons pas conserver deux versions dans le balisage, nous devrons utiliser JavaScript pour mettre à jour les attributs tabIndex des cartes lorsqu'elles s'empilent sur la page. Selon le nombre d'éléments de contrôle que nous rendons, cette approche peut être plus difficile à mettre en place que de maintenir différentes versions des cartes dans le balisage.

4. Lors de la personnalisation des états de focus, concevez pour les utilisateurs qui en ont le plus besoin

Les navigateurs utilisent la propriété CSS outline pour afficher une sorte d'indication visuelle qu'un élément est mis au point. Les états de focus sont destinés à aider les utilisateurs à identifier l'élément qui enregistrera les événements de clavier lorsqu'ils naviguent sur la page avec un clavier.

Il est très courant pour les concepteurs et les développeurs de remplacer les états de focus par défaut rendus par les navigateurs. Cela peut impliquer de mettre à jour le outline par défaut ou de le supprimer complètement et de le remplacer par une autre propriété CSS, telle que background , border , box-shadow , color ou transform .

Vous pourriez également aimer : Créer une pagination accessible avec Liquid.

Quelle que soit la manière dont nous décidons d'afficher des états de focus personnalisés dans nos applications, nous devons nous assurer qu'ils répondent aux exigences d'accessibilité suivantes :

• Contraste de couleur suffisant : il doit y avoir suffisamment de contraste entre notre état de mise au point et les couleurs qui l'entourent afin que les utilisateurs malvoyants puissent facilement savoir quel élément est actuellement mis au point.
• Les changements de couleur sont associés à d'autres indicateurs visuels : la modification de la couleur de la bordure, de la police ou de l'arrière-plan d'un élément peut ne pas être perceptible par les utilisateurs daltoniens. Il doit être associé à d'autres changements visuels qui n'obligent pas les utilisateurs à distinguer les couleurs. Cela s'applique également aux états de survol et d'erreur qui impliquent des changements de couleur.
• Visible dans les thèmes à contraste élevé : certaines propriétés CSS, notamment background et box-shadow , sont ignorées lorsque le mode à contraste élevé est activé sur les appareils Windows. Les changements de couleur peuvent ne pas être enregistrés non plus, c'est pourquoi il est doublement important de s'appuyer sur des indicateurs supplémentaires perceptibles par les personnes qui ont besoin de plus de contraste entre les couleurs d'arrière-plan et de premier plan.

Bien qu'il soit acceptable de remplacer la propriété de outline par défaut, ne supprimez jamais les états de focus par défaut sans fournir un remplacement.

5. Fournir des raccourcis pour les utilisateurs de clavier

Si quelqu'un utilise une souris pour naviguer sur une page Web, il peut faire défiler le contenu d'en-tête superflu lors du chargement de la page pour accéder aux informations qu'il recherche. Le processus n'est pas aussi simplifié pour les utilisateurs de clavier, qui peuvent avoir besoin de parcourir plusieurs liens de navigation ou tout autre élément de contrôle qui précède le contenu principal de la page.

En tant que développeurs, nous pouvons fournir un "lien de saut" en haut de chaque page de notre application pour permettre aux utilisateurs de clavier de contourner les éléments de contrôle qui précèdent le contenu principal de la page. Le lien de saut est généralement masqué jusqu'à ce qu'il reçoive le focus. Il n'est pas visible pour les personnes utilisant une souris pour interagir avec votre application, mais ce sera le premier élément à recevoir le focus pour ceux qui utilisent un clavier.

Lorsque le lien est cliqué, le focus se déplace vers le conteneur de contenu principal et les utilisateurs du clavier peuvent immédiatement commencer à parcourir les principaux éléments de contrôle d'une page.

Les liens de saut sont plus que des raccourcis pratiques. Il s'agit d'un exemple de blocs de contournement, qui sont nécessaires pour répondre aux normes WCAG de niveau A.

Testez souvent votre application en devenant vous-même un utilisateur de clavier

Tester l'accessibilité du clavier a une courbe d'apprentissage relativement plus faible pour les personnes qui ne sont pas habituées à utiliser des technologies ou des appareils d'assistance. Tout ce dont vous avez besoin est l'accès à un clavier, la familiarité avec les comportements standard du clavier et l'accès au mode Windows à contraste élevé (soit en acquérant un appareil Windows, soit en installant une machine virtuelle).

Voici quelques questions à garder à l'esprit lorsque nous testons notre application pour l'accessibilité du clavier :

• Suis-je capable d'utiliser mon clavier pour interagir avec tout ce qui répond aux clics et aux gestes de la souris ?
• Quelqu'un saura-t-il comment interagir avec cet élément lorsqu'il recevra le focus ?
• L'ordre du focus correspond-il à la séquence visuelle des éléments interactifs sur la page ?
• Puis-je garder une trace de l'élément actuellement mis au point, même si j'ai besoin d'un contraste plus élevé entre les couleurs ?
• Puis-je accéder facilement au contenu principal de la page ?

Répondre « oui » à toutes ces questions ne demande pas beaucoup d'efforts et peut avoir des effets positifs pour les utilisateurs en toutes circonstances : qu'ils aient un handicap physique, qu'ils recherchent des moyens de gagner du temps ou qu'ils aient besoin d'utiliser leur ordinateur d'une seule main.

Les tests d'accessibilité sont un élément crucial du développement d'applications. Plus précisément, l'accessibilité du clavier est tout aussi importante que la fourniture d'un texte alternatif pour les personnes qui utilisent des lecteurs d'écran ou de sous-titres pour les personnes qui ne peuvent pas entendre le contenu audio. En fin de compte, la possibilité d'utiliser une souris ne devrait pas être nécessaire pour utiliser une application si vous souhaitez que votre application soit entièrement accessible.