Beaucoup d'entre nous apprennent à nous assurer que nos sites peuvent être utilisés via le clavier. Pourquoi est-ce, et à quoi cela ressemble-t-il en pratique? Chris Ashton a fait une expérience pour le savoir.

Cet article fait partie d'une série dans laquelle j'essaie d'utiliser le web sous diverses contraintes, représentant une démographie donnée de l'utilisateur. J'espère faire ressortir les difficultés rencontrées par de vraies personnes, qui sont évitables si nous concevons et développons d'une manière qui soit favorable à leurs besoins. La dernière fois, J'ai utilisé le web pendant une journée sans JavaScript . Aujourd'hui, je me suis forcé à naviguer sur le web en utilisant seulement mon clavier

Qui utilise le clavier pour naviguer?

De manière générale, il existe trois types d'utilisateurs de clavier:

• ,
• Les utilisateurs ayant une déficience visuelle qui ne peuvent pas voir les éléments cliquables dans la page,
• Les utilisateurs avancés qui peuvent utiliser une souris mais qui trouvent plus rapide d'utiliser un clavier

Combien d'utilisateurs parlons-nous?

J'ai parcouru le web pour trouver des statistiques sur l'utilisation du clavier, et je n'ai rien trouvé. Sérieusement. Not one study.

La plupart des sites de guidage d'accessibilité au clavier tiennent simplement pour acquis que «beaucoup d'utilisateurs» se fient aux claviers pour se déplacer. Quiconque essaie d'obtenir un nombre approximatif est généralement rejeté avec "les statistiques n'ont pas d'importance – votre site devrait être accessible, période."

Oui, est vrai que l'échelle d'utilisation non-souris est un point discutable. Si vous pouvez apporter un changement qui habilite même un utilisateur, c'est un changement qui vaut la peine d'être fait. Mais il ya beaucoup de statistiques disponibles sur des choses comme les daltoniens, l'utilisation du navigateur, les vitesses de connexion et ainsi de suite – pourquoi la cagosité autour des statistiques du clavier? Si les chiffres sont aussi répandus que les sites semblent le suggérer, les avoir sûrement permettrait de faire une meilleure analyse de rentabilisation et de faciliter l'accès au clavier à vos parties prenantes.

Le plus proche d'un chiffre que je peux trouver est un article sur PowerMapper qui suggère que 7% des adultes en âge de travailler Les États-Unis, le Royaume-Uni et le Canada ont de «graves problèmes de dextérité». Cela les rendrait «peu susceptibles d'utiliser une souris et dépendrait plutôt du clavier».

Les utilisateurs ayant une déficience visuelle grave utilisent un lecteur d'écran qui est un logiciel qui lit le contenu sur l'écran en tant que discours synthétisé. Tout comme les utilisateurs voyants, les utilisateurs non voyants veulent pouvoir balayer les pages pour trouver des informations intéressantes, de sorte que le lecteur d'écran dispose de raccourcis clavier pour naviguer dans les en-têtes et les liens, et s'appuie sur des éléments focalisables pour interagir avec le clavier. besoin d'un accès complet au clavier. Période. "

– David Macdonald, co-éditeur de WAI ARIA en HTML5

Ces mêmes utilisateurs ont également des lecteurs d'écran sur leurs appareils mobiles, où ils utilisent des gestes de glissement au lieu d'appuyer sur le clavier. Ainsi, bien qu'ils n'utilisent pas littéralement un clavier, ils exigent que le site soit accessible au clavier, car la technologie du lecteur d'écran se connecte au même contrôleur de tabulation et aux mêmes écouteurs d'événements que s'ils utilisaient un clavier. Il convient de noter que seuls environ les deux tiers à trois quarts des utilisateurs de lecteurs d'écran sont aveugles ce qui signifie que le reste pourrait utiliser une combinaison de techniques de lecture d'écran et de grossissement.

Les Américains (de tous âges) ont une déficience visuelle qui ne justifie pas nécessairement l'utilisation d'un lecteur d'écran. En 2016, Addy Osmani a estimé que l'utilisation actuelle des lecteurs d'écran était de de l'ordre de 1 à 2% . Si nous prenons en compte ces utilisateurs avec nos utilisateurs à mobilité réduite et nos utilisateurs expérimentés, l'utilisation du clavier représente un pourcentage important de l'audience mondiale. Par conséquent, se soucier de l'accessibilité du clavier n'est pas seulement faire la bonne chose moralement (et juridiquement – de nombreux pays exigent que les sites Web soient accessibles par la loi ), mais cela a aussi un bon sens commercial. en tête, quel est l'état du web aujourd'hui? Il est temps de le découvrir!

The Experiment

Qu'est-ce que tout le monde fait quand il a devant lui une journée d'intimidation? Tergiverser! Je me suis dirigé vers youtube.com . J'avais une vidéo spécifique en tête et j'étais reconnaissant de trouver que je n'aurais pas besoin de tabulation dans le champ de recherche principal, car il est focalisé sur le chargement de la page par défaut.

L'autofocus Attribut

J'ai supposé que cela serait focalisé sur JavaScript sur le chargement de la fenêtre, mais il est en fait géré par le navigateur avec un attribut autofocus sur l'élément d'entrée . trouvé cela extrêmement utile. En tant qu'utilisateur aveugle de lecteur d'écran, je ne suis pas sûr que je le veuille ou non. Le consensus semble être que l'utilisation judicieuse de autofocus est OK dans les cas où le seul but de la page est d'interagir avec un formulaire (par exemple Google landing page, ou un site de contact

Styles de mise au point par défaut

Je cherchais quelque chose Quelle ligne est-ce que c'est? bonté, et ne pouvait s'empêcher de remarquer que YouTube n'avait défini aucune coutume : focus en se basant sur le style natif du navigateur pour indiquer visuellement les éléments sur lesquels je feuilletais.

J'ai toujours eu l'impression que tous les navigateurs ne définissaient pas leur propre état : focus donc avait pour définir votre propre style personnalisé. J'ai décidé de mettre cela à l'épreuve et de voir quels navigateurs négligent d'implémenter un style par défaut, mais à ma grande surprise, je n'en ai pas trouvé un. Tous les navigateurs que j'ai testés ont leur propre implémentation native de : focus bien que chacun ait un style différent.

Je suis même allé très loin dans le temps:

Si vous souhaitez en voir plus, il existe une collection complète de captures d'écran de différents éléments dans les états natifs du navigateur .

Ce que cela signifie, c'est que vous pouvez raisonnablement supposer chaque navigateur est livré avec un certain style de base : focus . C'est OK de laisser le navigateur faire le travail. Ce que vous risquez est une incohérence: tous les navigateurs ont des styles subtilement différents et certains sont si subtils qu'ils ne sont pas particulièrement visuellement accessibles.

Il est possible de désactiver les styles de focus du navigateur par défaut en définissant le contour : none sur votre élément – mais vous devriez le faire seulement si vous implémentez votre propre style . Heydon Pickering recommande cette approche en citant les défauts non clairs ou laids utilisés par certains navigateurs. Si vous décidez de déployer vos propres styles, assurez-vous d'utiliser plus que la couleur comme modificateur: Ajoutez un contour ou un soulignement ou un autre indicateur visuel pour prendre en charge les utilisateurs ayant un daltonisme.

styles mais ne parviennent pas à fournir des styles personnalisés, conduisant à des expériences inaccessibles. Si votre site utilise CSS reset d'Eric Meyer il pourrait être inaccessible; ce fichier couramment utilisé réinitialise les styles par défaut : focus mais demande au développeur d'écrire le sien, et beaucoup échouent à repérer les instructions.

Certaines personnes soutiennent que cela peut être source de confusion pour l'utilisateur si vous le désactivez le navigateur par défaut, car ils perdent l'accessibilité visuelle de l'état de mise au point auquel ils sont habitués et doivent plutôt apprendre à quoi ressemble l'état de mise au point de votre site. D'un autre côté, certains affirment que les paramètres par défaut du navigateur sont laids, voire confus pour l'utilisateur non-clavier.

Pourquoi être déroutant? Eh bien, regardez ce format de manège animé sur la BBC . Il y a deux boutons de navigation – suivant et précédent – et il est utile pour l'utilisateur du clavier que l'accent reste sur eux tout au long du récit. Mais pour l'utilisateur de la souris, il peut être assez déroutant que le bouton cliqué soit encore 'focalisé' après avoir déplacé le curseur.

Le : focus-visible CSS Selector

Si vous voulez le meilleur des deux mondes, vous pouvez explorer le CSS4 : focus-visible pseudo-classe qui vous permettra de fournir différents styles de mise au point en fonction du contexte. : le style focus-visible ne cible que les éléments qui ont été focalisés avec le clavier, pas avec un clic de souris. C'est super cool, bien qu'il ne soit actuellement supporté que nativement dans Firefox. Il peut être activé dans Chrome en activant le drapeau 'Fonctionnalités de la plate-forme Web expérimentale'

YouTube Vidéos et Accessibilité au clavier

YouTube fait un excellent travail avec son lecteur vidéo – chaque partie du lecteur est navigable au clavier. J'aime la façon dont les commandes de volume glissent lorsque vous vous détachez de l'icône de sourdine, contrairement à l'icône de sourdine

Je n'aimais pas que les étiquettes utiles, telles que le texte 'Mute' qui apparaît en survolant l'icône de mise en sourdine, ne s'affichent pas au point.

YouTube supprime également certains styles de mise au point. Ici, j'essayais d'appuyer sur le bouton "Afficher plus".

J'ai tabulé par inadvertance le bouton 'Afficher plus' car je ne voyais aucun style : focus appliqué, qu'il soit personnalisé ou natif. J'ai découvert que le style natif était remplacé par outline-width :

Accessibilité au clavier GitHub

OK, temps de travail. Où est-il préférable de travailler qu'à la maison du code, github.com ?

J'ai remarqué trois choses à propos de GitHub: une grande, une raisonnable, et une mauvaise.

D'abord, le bien. 19659079] Lien 'Skip To Content'

GitHub propose un lien Skip to Content qui passe au-dessus du menu principal

Si vous cliquez sur ENTRER alors que vous vous concentrez sur le lien «Passer au contenu», vous passez tous les éléments de menu en haut de la page et vous pouvez commencer à tabuler dans la zone principale du contenu. l'heure de la navigation. Ceci est un modèle d'accessibilité commun qui est super utile à la fois pour les utilisateurs de lecteurs de claviers et d'écrans. Environ 30% des utilisateurs de lecteurs d'écran utiliseront un lien de saut si vous en fournissez un.

Alternativement, certains sites choisissent de placer le contenu principal en premier dans l'ordre de lecture au-dessus du la navigation. Cette approche est tombée en désuétude car elle enfreint le principe de rendre votre contenu DOM conforme à l'ordre visuel (sauf si votre navigation apparaît visuellement en bas). Et bien que cette approche signifie que nous n'avons pas du tout besoin d'un lien 'Sauter la navigation', nous voudrions probablement un lien 'Sauter vers à sa place.

Tab Voir le contenu

Une fonctionnalité que j'ai remarquée fonctionnant différemment de la version 'non-clavier' était l'indicateur de panne de code.

En utilisant la souris, vous pouvez cliquer sur la barre colorée sous n'importe quel référentiel pour afficher une répartition proportionnelle des différents langages de programmation utilisés. repo. En utilisant le clavier, vous ne pouvez pas accéder à la barre de couleur, mais les langues apparaissent automatiquement lorsque vous passez la fin des méta-informations.

Cela ne me semble pas vraiment nécessaire – j'accepterais volontiers la barre colorée et je taperai ENTRER à ce sujet – mais ce comportement différent ne cause aucun

Liens Invisibles

Une chose problématique que j'ai rencontrée était qu'il y avait un lien "invisible" après tabulation passé ma photo de profil en haut à droite. Mon ordre de tabulation serait tabulation à l'image, puis à ce lien invisible, puis au bouton "Watch" sur le repo (voir gif ci-dessous). Je n'avais aucune idée de ce que le lien invisible faisait, donc quand j'ai reconnu que j'étais dessus, j'ai appuyé sur ENTER et j'ai été rapidement déconnecté!

Grand aperçu )

En y regardant de plus près, on dirait que j'ai navigué vers un formulaire "screenreader only" ( sr-only est un nom de classe de lecteur d'écran commun) a la fonction «Se déconnecter».

Ce lien de déconnexion est en plus vers le lien de déconnexion de votre menu déroulant de profil:

Je ne suis pas sûr que deux liens de déconnexion HTML distincts soient nécessaires, car un utilisateur de lecteur d'écran devrait être en mesure de déclencher la liste déroulante et de naviguer vers le lien de déconnexion principal. Et si nous voulions conserver le lien séparé, je recommanderais d'appliquer un style : focus au contenu du lecteur d'écran afin que les utilisateurs voyants ne déclenchent pas accidentellement la déconnexion [!19659104] Exemple de style de mise au point de texte de lecteur d'écran. « />

Comment créer un raccourci 'Skip To Content'

Alors, comment pouvons-nous recréer ce raccourci 'Skip to content'? C'est assez simple à implémenter, mais il peut être trompeusement compliqué d'être parfait – alors voici ce que je considère comme le Saint Graal des solutions de liens de sauts

'Skip link' est aussi appelé 'Sauter la navigation', 'Sauter la navigation principale ',' Ignorer les liens de navigation 'ou' Passer au contenu principal '. "Passer au contenu principal" est probablement le plus clair car il vous indique où vous naviguez, plutôt que ce que vous sautez.

Le lien de raccourci devrait idéalement apparaître juste après l'ouverture marque. Il pourrait apparaître plus tard dans le DOM, même après le pied de page, pourvu que vous ayez un attribut tabindex = "1" pour le forcer à devenir le premier élément interactif dans l'ordre des onglets. Toutefois, l'utilisation de tabindex avec un nombre supérieur à zéro est généralement une mauvaise pratique et entraînera souvent un avertissement lors de l'utilisation d'outils de validation tels que Lighthouse

tabindex ]car vous pouvez avoir plus d'un lien avec tabindex = "1" . Dans ces cas, c'est le premier lien qui obtiendrait le focus de l'onglet en premier, pas de liens plus tard. En savoir plus sur l'utilisation de l'attribut tabindex ici mais rappelez-vous qu'il est toujours préférable de déplacer physiquement votre lien vers le début du DOM pour être sûr.

   Aller au contenu principal

Le lien "Passer au contenu principal" a une utilité limitée pour les utilisateurs voyants, qui peuvent déjà ignorer la navigation en utilisant leurs yeux. Ainsi, alors que certains sites gardent le lien de saut visible à tout moment, la convention est de garder le lien caché jusqu'à ce que vous le tabuliez, à quel point il est net et gagne le style appliqué par le : focus ] Pseudo-sélecteur.

 .screen-reader-shortcut {
  position: absolue;
  en haut: -1000em;
}

.screen-reader-shortcut: focus {
  position: fixe;
  en haut: 0;
  gauche: 0;
  indice z: 999;
  / * ... et maintenant tout style sympa que vous voulez appliquer ... * /
  rembourrage: 1em;
  couleur de fond: RGB (114, 105, 105);
  Couleur blanche;
  text-decoration: aucun;
}

Alors, à quoi allons-nous vraiment? Qu'est-ce que # main-content ? Il peut vraiment être n'importe quoi:

1. Contenu en ligne
   c.-à-d. l'identifiant de votre h1 tag:
   
   .
2. Conteneur
   par exemple. l'identifiant du conteneur autour de votre contenu principal tel que
   .
3. Ancre de frères et soeurs
   Vous pouvez créer un lien vers une balise nommée juste au-dessus de votre contenu principal, par ex. . Cette approche est généralement décrite dans des tutoriels plus anciens – je ne le recommanderais pas ces jours-ci.

Pour une compatibilité maximale entre tous les lecteurs d'écran, je recommande de lier la balise h1 . Ceci permet de s'assurer que le contenu est lu dès que vous avez utilisé le lien de saut. La liaison aux conteneurs peut conduire à un comportement amusant, par ex. le lecteur d'écran commençant à lire tout le le contenu à l'intérieur du conteneur.

Votre # contenu principal devrait aussi avoir un tabindex de - 1 pour s'assurer qu'il est focalisable par programme. Il se peut que certains lecteurs d'écran n'obéissent pas au lien de saut.

 Ceci est le titre de la page 

Une dernière considération: le support du navigateur hérité. Si vous avez suffisamment d'utilisateurs sur IE9 ou moins, vous devrez peut-être appliquer une petite correction JavaScript à vos liens de saut pour vous assurer que le focus change comme prévu et que vos utilisateurs passent votre navigation.

Pourquoi est-ce que nous réinventons la roue?

En tant que développeurs web, il nous semble dingue de devoir implémenter ce hack de navigation sur tous nos sites. On pourrait penser que nous pourrions laisser les normes faire le travail.

Depuis HTML5, nous avons eu des éléments sémantiques tels que