| <- [[W3Cx:itwa:2.2.2 Knowledge checks]]| [[W3Cx:itwa:2.3.2 Switch controls]] -> |

===== en résumé =====

Attention à l'interaction au clavier (les éléments doivent recevoir un focus visible, les éléments doivent être dans l'ordre et il faut basculer automatiquement le focus en cas de mise à jour pour éviter que l'utilisateur ne doivent rechercher l'élément mis à jour dans la page.

Permettre de sauter des listes de liens pour aller au contenu principal, avec un lien « aller au contenu principal » (genre sur un site, on a pas forcément envie de se taper tous les liens s'il y en a beaucoup, on veut peut-être lire directement le contenu.

Attention à la taille des boutons et envisager des alternatives à certaines modalités d'entrée d'information.

====== 2.3.1 Handicaps physiques ======

De nombreuses personnes souffrant de limitations physiques n'utilisent pas de souris et s'appuient sur d'autres mécanismes tels que le clavier, la commande vocale et d'autres dispositifs de pointage pour naviguer et interagir avec le Web.

Du point de vue de la conception et du code, il est important que les éléments tels que les boutons, les liens et les contrôles soient accessibles au clavier et pas seulement à l'aide d'une souris.

Cela signifie qu'ils peuvent être ciblés et actionnés à l'aide du clavier, qu'ils ont un état de focalisation visible et que l'ordre de focalisation est logique. Les liens de saut peuvent également s'avérer très utiles. ((//This means they are focusable and actionable using a keyboard, have a visible focus state, and focus order is logical. Skip links can also be enormously helpful.//))

===== Accessibilité au clavier =====

Il peut être très frustrant de voir un bouton à l'écran et de ne pas pouvoir le mettre en évidence ou l'activer.

Par défaut, des éléments HTML spécifiques (ancres, contrôles de formulaire, zones de carte d'image) reçoivent le focus clavier. Cependant, les contrôles complexes qui ne sont pas directement disponibles en HTML sont souvent construits à l'aide d'éléments HTML "génériques" tels que <span> ou <div>, associés à un comportement JavaScript supplémentaire pour les rendre interactifs. Ces éléments ne reçoivent pas la focalisation du clavier s'ils ne sont pas correctement codés, et sont donc impossibles à atteindre pour les utilisateurs utilisant uniquement le clavier.

Un autre problème courant est l'apparition de contenu lorsque l'utilisateur passe la souris sur un élément particulier (survol). Si elles ne sont pas codées correctement, ces informations peuvent être perdues pour les utilisateurs utilisant uniquement le clavier. Il peut s'agir, par exemple, d'infobulles utilisées pour l'aide contextuelle, ce qui signifie que les utilisateurs du clavier perdent des informations cruciales.

===== Manque de focus visible =====

Une difficulté bien trop fréquente pour les utilisateurs de clavier est de repérer visuellement où ils se trouvent dans une page. Les utilisateurs de souris peuvent déplacer la souris sur la page et constater que la flèche se transforme en main lorsqu'elle survole des éléments exploitables, pour indiquer qu'ils sont exploitables. Normalement, cela se produit en même temps que l'élément change d'état pour indiquer qu'il est actionnable. Par exemple, un soulignement apparaît sous un lien. C'est ce qu'on appelle un état de survol.

{{http://pix.leomartin.net/i/ec/7OkBq5Jnh.wai-nav-focus-2.png}}
//Menu de navigation avec un état d'accentuation clair présenté sur le lien « Design and Develop »//

Pour répondre aux besoins des utilisateurs voyants qui utilisent uniquement le clavier, il est important que, lorsque le curseur du clavier est placé sur un lien, par exemple, le lien change d'apparence pour que l'utilisateur sache où se trouve le curseur. C'est ce qu'on appelle l'état du focus. S'il n'y a pas d'état de focus, il peut être impossible de savoir où l'on se trouve sur une page ou ce qui est actionnable.

===== Ordre de focalisation =====

Lorsque l'on navigue dans le contenu, on s'attend généralement à ce que l'ordre du contenu suive l'ordre visuel de la lecture de la page. Par exemple, en anglais, de gauche à droite et de haut en bas. Sur une page Web typique, nous nous attendons à ce que l'ordre commence par l'en-tête, suivi de la navigation principale, de la navigation de la page, du contenu principal et enfin du pied de page. À l'intérieur de ces segments de la page, nous nous attendons à ce que les contenus connexes soient regroupés.

Par exemple, regardez la capture d'écran ci-dessous, tirée d'une page Web. Elle montre trois articles disposés en trois colonnes avec un lien en haut de chaque colonne. Quel serait l'ordre logique du contenu en suivant les liens horizontalement ligne par ligne ou verticalement colonne par colonne ?

{{http://pix.leomartin.net/i/3e/7OkBJyql3.BAD_demo_focus_order.png}}
//Page Web présentant trois articles en trois colonnes. Chaque article a deux liens, un en haut de la colonne et un en bas. La commande Focus parcourt correctement chaque article colonne par colonne, mais pas ligne par ligne.//

La réponse est que les liens doivent être lus verticalement, colonne par colonne, de sorte que les liens connexes soient regroupés. 

Un problème courant avec l'ordre de mise au point, que les utilisateurs de lecteurs d'écran rencontrent également, est qu'un bouton met à jour ou modifie le contenu de la page mais que la mise au point n'est pas gérée. Par exemple, un bouton peut être activé pour ouvrir une boîte de dialogue modale, mais le focus du clavier n'est pas déplacé vers la boîte de dialogue. Au lieu de cela, l'utilisateur doit parcourir tout le contenu de la page jusqu'à ce qu'il puisse finalement mettre le focus sur la boîte de dialogue.

===== Sauter des liens =====

La navigation longue peut être un défi pour les utilisateurs de clavier voyants, car ils doivent appuyer sur la touche de tabulation pour parcourir les éléments interactifs qui précèdent l'élément que l'utilisateur veut activer. Par exemple, il faut passer par la navigation principale et secondaire avant d'arriver à un lien qu'on souhaite activer dans le corps principal du contenu. Pour une meilleure expérience, il peut être utile d'ajouter un lien "Passer au contenu principal" au début d'une page. Cela devrait permettre à l'utilisateur de passer directement au début du contenu principal, sans avoir à parcourir tous les liens de navigation.

Pour voir comment cela fonctionne, rendez-vous sur le site Web de l'initiative pour l'accessibilité du Web, placez un onglet sur le lien « Passer au contenu principal », activez la touche Entrée, placez un autre onglet et voyez où vous mettez l'accent.

{{http://pix.leomartin.net/i/e4/7OkC4Jhat.w3c-nav-2.png}}
//Le lien "Passer au contenu" figurant dans le menu de navigation précédent.//

===== Taille et mouvement de la cible =====

En dehors des états de mise au point visibles, d'un ordre de mise au point logique et d'éléments pouvant être mis au point et actionnés par le clavier, il existe un certain nombre d'autres questions qui peuvent avoir une incidence négative ou positive sur les utilisateurs qui n'utilisent pas la souris.

{{http://pix.leomartin.net/i/35/7OkCdZpZ5.mobile-screen-keyboard.png}}

//Les claviers sur écran tactile peuvent être difficiles à utiliser en raison de la proximité des lettres et de la petite taille de leur cible tactile Proposer d'autres moyens d'entrer du texte peut aider les gens à accomplir leurs tâches//

Les difficultés ne se limitent pas à l'utilisation du clavier. Certains utilisateurs ayant une dextérité limitée peuvent utiliser une souris ou un doigt pour naviguer sur les écrans de bureau et les écrans tactiles. Les personnes dont les mains tremblent et qui ont du mal à cibler les liens peuvent avoir des difficultés avec les menus déroulants, par exemple.

Les petites cibles tactiles posent également problème, surtout lorsqu'elles sont présentées à côté d'autres éléments focalisables. Si une série de boutons sont petits et rapprochés, il devient difficile de toucher avec précision le bouton dont vous avez besoin. Les claviers à l'écran, où le texte des boutons est petit et adjacent à d'autres textes, en sont un exemple courant. 

Pour minimiser l'impact sur l'utilisateur final, envisagez de proposer des alternatives plus utilisables en plus de l'option permettant de remplir les champs du formulaire. Par exemple, la saisie vocale pour la recherche, les menus déroulants, les cases d'option ou les cases à cocher (plutôt que la saisie de texte libre), la prise en charge du texte prédictif et le préremplissage des données du formulaire lorsque cela est possible.

====== questions ======

  * À quoi faut-il faire attention avec l'interaction clavier ? (4 éléments)
    * à ce que les éléments aient un focus visible
    * à basculer le focus vers l'élément mis à jour en cas de mise à jour
    * à permettre de sauter les listes pour aller au contenu principal avec un lien « aller au contenu principal »
    * à la taille des boutons, et à proposer des alternatives à certains modes d'entrée de données
  * Que signifie l'accessibilité au clavier ?
    * Que les éléments peuvent être ciblés et actionnés à l'aide du clavier, qu'ils ont un état de focalisation visible et que l'ordre de focalisation est logique. Les liens de saut peuvent également s'avérer très utiles