J'ai utilisé le Web pendant une journée avec juste un clavier

Cet article fait partie d'une série dans laquelle j'essaie d'utiliser le Web sous diverses contraintes, représentant un groupe démographique d'utilisateurs donné. J'espère rehausser le profil des difficultés rencontrées par de vraies personnes, qui sont évitables si nous concevons et développons d'une manière qui est sensible à 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 uniquement mon clavier.

Qui utilise le clavier pour naviguer ?

En gros, il existe trois types d'utilisateurs de clavier :

• Les utilisateurs à mobilité réduite qui peinent à utiliser une souris,
• Les utilisateurs malvoyants qui ne voient pas les éléments cliquables dans la page,
• Utilisateurs expérimentés capables d'utiliser une souris mais trouvant plus rapide d'utiliser un clavier.

De combien d'utilisateurs parlons-nous ?

J'ai parcouru le Web pour obtenir des statistiques sur l'utilisation du clavier, et je n'ai rien trouvé. Sérieusement. Pas une seule étude.

La plupart des sites de conseils sur l'accessibilité du clavier tiennent simplement pour acquis que "de nombreux utilisateurs" comptent sur les claviers pour se déplacer. Quiconque essaie d'obtenir un nombre approximatif est généralement rejeté avec prédication avec "les statistiques n'ont pas d'importance - votre site doit être accessible, point final".

Oui, il est vrai que l'échelle d'utilisation sans souris est un point discutable. Si vous pouvez apporter un changement qui responsabilise ne serait-ce qu'un seul utilisateur, c'est un changement qui en vaut la peine. Mais il existe de nombreuses statistiques disponibles sur des sujets tels que le daltonisme, l'utilisation du navigateur, les vitesses de connexion, etc. Pourquoi la méfiance autour des statistiques du clavier ? Si les chiffres sont aussi répandus que les sites semblent le suggérer, les avoir permettrait sûrement une analyse de rentabilisation plus solide et faciliterait la défense de l'accessibilité du clavier à vos parties prenantes.

La chose la plus proche d'un chiffre que je puisse trouver est un article sur PowerMapper, qui suggère que 7 % des adultes en âge de travailler aux États-Unis, au Royaume-Uni et au Canada ont de « graves difficultés de dextérité ». Cela les rendrait "peu susceptibles d'utiliser une souris et de se fier plutôt au clavier".

Les utilisateurs souffrant de déficiences visuelles graves utilisent un logiciel appelé lecteur d'écran, qui lit le contenu à l'écran sous forme de parole synthétisée. À l'instar des utilisateurs voyants, les utilisateurs non voyants souhaitent pouvoir parcourir les pages à la recherche d'informations intéressantes. Le lecteur d'écran dispose donc de raccourcis clavier pour naviguer via les en-têtes et les liens, et s'appuie sur des éléments de mise au point du clavier pour l'interaction.

« Les personnes aveugles ont besoin d'un accès complet au clavier. Point final."

— David Macdonald, co-éditeur de Utilisation de WAI ARIA dans HTML5

Ces mêmes utilisateurs ont également des lecteurs d'écran sur leurs appareils mobiles, où ils utilisent des gestes de balayage au lieu d'appuyer sur le clavier pour "tabuler" le contenu. 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 s'accroche au même ordre de tabulation et aux mêmes écouteurs d'événements que s'ils utilisaient un clavier. Il convient de noter que seuls les deux tiers à trois quarts des utilisateurs de lecteurs d'écran sont aveugles, ce qui signifie que les autres peuvent utiliser une combinaison de techniques de lecteur d'écran et de grossissement.

2,3 % des Américains (de tous âges) ont un handicap visuel, qui ne justifierait pas nécessairement l'utilisation d'un lecteur d'écran. En 2016, Addy Osmani a estimé que l'utilisation réelle des lecteurs d'écran était d'environ 1 à 2 %. Si nous intégrons ces utilisateurs à 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 ce qu'il faut moralement (et légalement - de nombreux pays exigent que les sites Web soient accessibles par la loi), mais c'est aussi une bonne décision commerciale.

Avec tout cela à l'esprit, quel est l'état du Web aujourd'hui ? Il est temps de le découvrir !

L'expérience

Que fait tout le monde quand ils ont une journée de travail intimidante devant eux ? Remettre à plus tard! Je suis allé sur youtube.com. J'avais une vidéo spécifique en tête et j'étais reconnaissant de constater que je n'aurais pas besoin de tabuler dans le champ de recherche principal, car il se concentre par défaut sur le chargement de la page.

L'attribut autofocus

J'ai supposé que cela serait concentré avec JavaScript sur le chargement de la fenêtre, mais il est en fait géré par le navigateur avec un attribut de autofocus au point automatique sur l'élément d'entrée.

En tant qu'utilisateur de clavier voyant, j'ai trouvé cela extrêmement utile. En tant qu'utilisateur de lecteur d'écran aveugle, je ne sais pas si cela me plairait ou non. Le consensus semble être qu'une utilisation judicieuse de l' autofocus est acceptable, dans les cas où le seul but de la page est d'interagir avec un formulaire (par exemple, la page de destination de Google ou un formulaire de contact de site).

Styles de mise au point par défaut

J'ai cherché des Whose Line Is It Anyway? mon Dieu, et je n'ai pas pu m'empêcher de remarquer que YouTube n'avait défini aucun style personnalisé :focus , s'appuyant plutôt sur le style natif du navigateur pour indiquer visuellement les éléments sur lesquels je tabulais.

J'ai toujours eu l'impression que tous les navigateurs ne définissent pas leur propre état :focus , vous devez donc définir votre propre style personnalisé. J'ai décidé de tester cela 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é. Chaque navigateur que j'ai testé avait sa propre implémentation native de :focus , bien que chacun ait un style différent.

Je suis même remonté assez 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 me dit, c'est que vous pouvez raisonnablement supposer que chaque navigateur est livré avec un style de base :focus . Il est normal de laisser le navigateur faire le travail. Ce que vous risquez, c'est l'incohérence : tous les éléments de style des navigateurs sont subtilement différents, et certains sont si subtils qu'ils ne sont pas particulièrement accessibles visuellement.

Il est possible de désactiver les styles de focus du navigateur par défaut - en définissant outline: none sur votre élément - mais vous ne devez le faire que si vous implémentez votre propre alternative stylée. Heydon Pickering recommande cette approche, citant les défauts peu 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, un soulignement ou un autre indicateur visuel pour aider les utilisateurs daltoniens.

De nombreux sites suppriment les styles de focus par défaut mais ne fournissent pas de styles personnalisés, ce qui conduit à des expériences inaccessibles. Si votre site utilise la réinitialisation CSS d'Eric Meyer, il pourrait être inaccessible ; ce fichier couramment utilisé réinitialise les styles :focus par défaut mais demande au développeur d'écrire le sien, et beaucoup ne parviennent pas à repérer les instructions.

Certaines personnes affirment que cela peut être déroutant pour l'utilisateur si vous désactivez les paramètres par défaut du navigateur, car ils perdent l'offre 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 déroutants pour l'utilisateur qui n'utilise pas le clavier.

Pourquoi confondre ? Eh bien, découvrez ce format de carrousel 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 le focus 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 toujours "concentré" après avoir éloigné le curseur.

Le sélecteur CSS :focus-visible

Si vous voulez le meilleur des deux mondes, vous pouvez explorer la pseudo-classe CSS4 :focus-visible , qui vous permettra de fournir un style de focus différent selon le contexte. :focus-visible cible uniquement les éléments qui ont été mis en évidence avec le clavier, pas avec un clic de souris. C'est super cool, bien qu'il ne soit actuellement pris en charge nativement que dans Firefox. Il peut être activé dans Chrome en activant le drapeau "Fonctionnalités expérimentales de la plate-forme Web".

Vidéos YouTube 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 éloignez la mise au point de l'icône de sourdine, contrairement au glissement lorsque vous survolez l'icône de sourdine.

Ce que je n'ai pas aimé, c'est que les étiquettes utiles, telles que le texte « Muet » qui apparaît lorsque vous survolez l'icône de sourdine, ne sont pas affichées sur le focus.

Un autre domaine qui laisse tomber YouTube est qu'il supprime certains styles de mise au point. Ici, j'essayais de tabuler sur le bouton "Afficher plus".

J'ai accidentellement tabulé juste après le bouton "Afficher plus" car je ne pouvais voir aucun style :focus appliqué, qu'il soit personnalisé ou natif. J'ai compris que le style natif était remplacé par outline-width :

Accessibilité du clavier GitHub

OK, le temps de travail. Quel meilleur endroit pour travailler qu'à la maison du code, github.com ?

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

D'abord, le bien.

Lien "Passer au contenu"

GitHub propose un lien Skip to content , qui ignore le menu principal.

Si vous appuyez sur ENTRÉE alors que vous êtes concentré sur le lien "Passer au contenu", vous ignorez tous les éléments de menu en haut de la page et pouvez commencer à tabuler dans la zone principale de contenu, ce qui vous fait gagner du temps lors de la navigation. Il s'agit d'un modèle d'accessibilité courant qui est très utile pour les utilisateurs de clavier et de lecteur d'écran. 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 de la navigation. Cette approche est tombée en désuétude car elle enfreint la directive de faire correspondre votre contenu DOM à l'ordre visuel (à moins que votre navigation n'apparaisse visuellement en bas). Et bien que cette approche signifie que nous n'avons pas du tout besoin d'un lien "Passer à la navigation", nous voudrions probablement un lien "Passer à la navigation" à sa place.

Onglet pour voir le contenu

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

À l'aide de 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 dans le référentiel. À l'aide du clavier, vous ne pouvez pas accéder à la barre colorée, mais les langues s'affichent automatiquement lorsque vous passez la fin des méta-informations.

Cela ne semble pas vraiment nécessaire - je serais heureux de tabuler sur la barre colorée et d'appuyer sur ENTRÉE dessus - mais ce comportement différent ne cause aucun mal non plus.

Liens invisibles

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

En y regardant de plus près, il semble que j'ai navigué vers un formulaire "lecteur d'écran uniquement" ( sr-only est un nom de classe de lecteur d'écran courant) qui a la fonction "Déconnexion".

Ce lien de déconnexion s'ajoute au lien de déconnexion du menu déroulant de votre 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 pouvoir déclencher la liste déroulante et accéder au 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 leur déconnexion !

Comment créer un raccourci "Passer au contenu"

Alors, comment recréons-nous ce raccourci "Passer au contenu" ? C'est assez simple à mettre en œuvre, mais il peut être trompeur d'être parfait - voici donc ce que je considère comme le Saint Graal des solutions de liens de saut.

'Ignorer le lien' est également appelé 'Ignorer la navigation', 'Ignorer 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 la balise d'ouverture <body> . Il pourrait apparaître plus tard dans le DOM, même après le pied de page, à condition d'avoir un tabindex="1" pour le forcer à devenir le premier élément interactif dans l'ordre de tabulation. Cependant, 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.

Il n'est pas infaillible de compter sur 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 les liens ultérieurs. 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 plus de sécurité.

 <a class="screen-reader-shortcut" href="#main-content"> Skip to main content </a>

Le lien "Passer au contenu principal" a une utilisation limitée aux 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 actuelle est de garder le lien caché jusqu'à ce que vous y accédiez, auquel cas il est mis au point et obtient le style appliqué par le pseudo-sélecteur :focus .

 .screen-reader-shortcut { position: absolute; top: -1000em; } .screen-reader-shortcut:focus { position: fixed; top: 0; left: 0; z-index: 999; /* ...and now any nice styling you want to apply... */ padding: 1em; background-color: rgb(114, 105, 105); color: white; text-decoration: none; }

Alors, à quoi sautons-nous réellement? Qu'est-ce que #main-content ? Cela peut vraiment être n'importe quoi :

1. Contenu en ligne
   c'est à dire l'id de votre balise h1 : <h1 id="main-content"> .
2. Récipient
   par exemple l'identifiant du conteneur autour de votre contenu principal tel que <main id="main-content"> .
3. Ancre fraternelle
   Vous pouvez créer un lien vers une balise nommée juste au-dessus de votre contenu principal, par exemple <a name="main-content"></a> . Cette approche est généralement décrite dans des tutoriels plus anciens - je ne la recommanderais pas de nos jours.

Pour une compatibilité maximale sur tous les lecteurs d'écran, je vous recommande de créer un lien vers la balise h1 . Cela permet de s'assurer que le contenu est lu dès que vous avez utilisé le lien de saut. La liaison aux conteneurs peut entraîner un comportement amusant, par exemple le lecteur d'écran commençant à lire tout le contenu à l'intérieur du conteneur.

Votre #main-content doit également avoir un tabindex de -1 , pour s'assurer qu'il est focalisable par programme. Sinon, certains lecteurs d'écran pourraient ne pas respecter le lien de saut.

 <h1 tabindex="-1">This is the title of the page</h1>

Une dernière considération : la prise en charge des navigateurs hérités. Si vous avez suffisamment d'utilisateurs sur IE9 ou inférieur, vous devrez peut-être appliquer un petit correctif JavaScript à vos liens de saut pour vous assurer que le focus se déplace réellement comme prévu et que vos utilisateurs sautent avec succès votre navigation.

Pourquoi réinventons-nous la roue ?

Il semble fou qu'en tant que développeurs Web, nous devions implémenter ce hack "sauter la navigation" sur tous nos sites en règle générale. On pourrait penser que nous pourrions laisser les normes faire le travail.

Depuis HTML5, nous avons des éléments sémantiques tels que <main> , <nav> et <header> . Avant cela, nous avions des points de repère ARIA tels que role="main" , role="navigation" et role="banner" respectivement. Dans le paysage actuel du Web, les meilleures pratiques dictent que vous avez besoin des deux, c'est-à-dire <main role="main"> , ce qui est une horrible violation du principe DRY, mais c'est parti.

Avec toute cette richesse sémantique, vous espérez que les navigateurs commenceraient à prendre en charge nativement la navigation via ces zones de repère, par exemple en exposant un raccourci clavier permettant aux utilisateurs de tabuler directement dans la section <main> d'une page Web. Pas de chance - il n'y a pas de support natif pour le moment. Votre meilleur pari est d'utiliser l'extension Landmark Navigation via Keyboard pour Chrome, Opera ou Firefox.

Les utilisateurs de lecteurs d'écran, cependant, peuvent commencer à naviguer directement vers ces régions repères. Par exemple, sur VoiceOver sur Mac, vous pouvez appuyer sur CTRL + ALT + U pour afficher le menu Repères et accéder au repère « principal », qui est un raccourci rapide et cohérent pour accéder au contenu principal. Bien sûr, cela repose sur les sites qui balisent correctement leurs documents.

Voici un bon point de départ pour votre site si vous souhaitez qu'il soit navigable via des régions repères :

 <body> <header role="banner"> <!-- Logo and things can go here --> <nav role="navigation"> <!-- Site navigation links go here --> </nav> </header> <main role="main"> <!-- Main content lives here - including our h1 --> </main> <footer role="contentinfo"> <!-- Copyright statement, etc --> </footer> </body>

Tout ce balisage est un travail assoiffé. Le temps d'un café.

Café du Pacte

Je me souviens d'avoir vu un flyer pour pactcoffee.com… allons y jeter un œil !

Bannière de cookies

La bannière « Politique de cookies » est l'une des premières choses que vous remarquez ici, et la rejeter est presque un réflexe instinctif pour l'utilisateur de souris voyant. Certains utilisateurs de lecteurs d'écran peuvent ne pas s'en soucier (si vous êtes aveugle, vous ne saurez pas qu'il est là jusqu'à ce que vous l'atteigniez), mais en tant qu'utilisateur voyant, vous le voyez, vous voulez le tuer, et dans le cas de ce site, vous devez tabuler devant TOUS LES AUTRES LIENS avant de pouvoir le fermer.

J'ai utilisé l'extension d'accessibilité ChromeLens pour tracer l'ordre de tabulation de la page :

Cela peut être corrigé soit en déplaçant l'avis en haut du document (il peut toujours être ancré visuellement en bas avec CSS), soit en ajoutant un tabindex="1" au bouton OK. Je suggérerais d'appliquer ce correctif à tout contenu où l'on s'attend à ce que l'utilisateur veuille le rejeter.

Plus de liens invisibles

Comme sur GitHub, je me suis retrouvé à tabuler sur un élément hors écran dont le but n'était pas clair. Il s'est avéré qu'il s'agissait d'une bascule "Voir moins…" située derrière la carte "Voir plus…".

C'est parce que la zone "cachée" n'est pas vraiment cachée, elle est simplement tournée de 180 degrés, en utilisant :

 transform: rotateY(180deg);

… ce qui signifie que le bouton « Voir moins… » fait toujours partie de l'ordre des onglets. Cela peut être corrigé en appliquant un display: none jusqu'à ce que l'application soit prête à déclencher la rotation :

Café commandé. Il est maintenant temps de poursuivre mes recherches.

Monde informatique

Je faisais des recherches pour cet article et je suis tombé sur une expérience similaire à la mienne ; Kevin Purdy a navigué sur le Web pendant sept jours en utilisant uniquement son clavier. Je trouve ironique que je n'ai pas pu lire son article sous les mêmes contraintes !

Le problème était une bannière de cookie pleine page, m'obligeant à "Mettre à jour les paramètres de confidentialité" ou à accepter les paramètres de cookie par défaut. Peu importe combien de fois j'ai tabulé, je ne pouvais pas me concentrer sur la bannière de cookies et la rejeter.

J'ai creusé dans le code source pour savoir ce qui se passait. Pendant un moment, j'ai pensé qu'il pourrait s'agir de notre ennemi juré, la propriété CSS outline .

En inspectant le lien "Mettre à jour les paramètres de confidentialité", je peux voir un outline: 0 comme je le soupçonnais. Alors peut-être que je me concentre sur les boutons, mais il n'y a pas de retour visuel lorsque cela se produit ?

J'ai essayé de définir l'état sur :hover pour voir s'il me manquait un style en tant qu'utilisateur de clavier :

Effectivement, le lien a pris une belle couleur orange évidente au survol - quelque chose que je n'ai jamais vu au focus :

Hourra ! Craqué ! Je n'ai jamais vu l'état :focus car le style personnalisé n'était appliqué que sur :hover . J'ai dû sauter les boutons sans même m'en rendre compte, n'est-ce pas ?

Tort. Même lorsque je hackais le CSS localement, je ne pouvais voir aucun style de focus, ce qui signifie que je n'allais même pas jusqu'à tabuler dans le cookie modal. Puis j'ai réalisé… il manquait un attribut href au lien :

C'était le vrai coupable. Le outline: 0 n'était pas le problème - le navigateur n'allait jamais tabuler sur le lien car ce n'était pas un lien valide !

À partir de la spécification HTML 5.2 :

La destination du ou des liens est donnée par l'attribut href, qui doit être présent et doit contenir une URL valide non vide potentiellement entourée d'espaces. Si l'attribut href est absent, alors l'élément ne définit pas de lien.

Donner aux liens un attribut href - même s'il ne s'agit que de # - en ferait des liens valides et les ajouterait à l'ordre de tabulation de la page.

Curieusement, plus tard dans la journée, on m'a envoyé un article sur PC World à lire et j'ai rencontré exactement le même problème.

Il semble que les deux sites utilisaient la même plateforme de gestion du consentement (CMP). J'ai creusé un peu et j'en ai déduit que cela affectait un certain nombre de sites appartenant à la même société, et je les ai depuis contactés directement avec une suggestion de correctif.

Kinetico

Mon robinet de cuisine fuit et je voulais le faire remplacer. J'ai vu une annonce dans le journal local pour kinetico.co.uk, alors j'ai pensé jeter un coup d'œil.

Je n'ai pas pu accéder à la section "Kitchen Taps", car le lien était caché derrière un lien parent "Salt & Cartridges" qui ne montre que ses liens enfants au survol. Il est intéressant de noter que le site est suffisamment avant-gardiste pour fournir un lien "Passer au contenu" (vu brièvement dans le gif ci-dessus) mais n'a pas été en mesure de créer un menu accessible !

C'est ici que le menu se trompe - il n'affiche le sous-menu que lorsque l'élément de menu parent est survolé :

Le réparer est plus facile à dire qu'à faire. Dans la plupart des cas, vous pouvez simplement "doubler" votre sélecteur pour appliquer également le focus :

 li:hover .nav_sub_menu, li:focus .nav_sub_menu { }

Mais cela ne fonctionne pas dans ce cas car bien que l'élément <li> soit survolable, il n'est pas focalisable. C'est le lien à l'intérieur du <li> qui est focalisable. Mais le sous-menu n'est pas à l'intérieur du lien, il est à côté , nous devons donc appliquer le sélecteur frère pour afficher le sous-menu lorsque le lien est au point.

 li:hover .nav_sub_menu, a:focus + .nav_sub_menu { }

Ce réglage signifie que nous pouvons voir notre sous-menu lorsque nous tabulons sur l'élément de menu parent sur le clavier. Mais que se passe-t-il lorsque vous essayez d'accéder au sous-menu ?

Lorsque nous tabulons à partir de l'élément de menu parent, le focus passe au premier lien du menu enfant comme prévu. Mais cela éloigne le focus du lien du menu parent, ce qui signifie que le sous-menu est masqué et que les éléments du menu enfant sont à nouveau supprimés de l'ordre de tabulation !

C'est un problème qui peut être résolu avec :focus-within , qui vous permet d'appliquer un style à un élément parent si celui-ci ou l'un de ses éléments enfants a le focus. Donc, dans ce cas, nous devons tripler:

 li:hover .nav_sub_menu, /* hover over parent menu item, show child menu */ a:focus + .nav_sub_menu, /* focus onto parent menu item, show child menu */ .nav_sub_menu:focus-within { /* focus onto child menu item, keep showing child menu */ }

Notre menu est désormais entièrement accessible au clavier via CSS pur. J'adore les solutions CSS créatives, mais un mot d'avertissement ici : de nombreuses solutions "CSS uniquement" dans la nature tombent en panne lorsqu'il s'agit de la navigation au clavier. Éviter JavaScript ne rend pas nécessairement un site plus accessible.

En fait, un menu piloté par JS pourrait être un meilleur cri dans ce cas, car la prise en charge du navigateur pour cette solution est encore assez médiocre. :focus-within ne peut actuellement être utilisé que dans Chrome, Firefox et Safari. Même dans Chrome, je l'ai trouvé incompatible avec l' display: none logique utilisée pour afficher/masquer le menu enfant ; J'ai dû masquer mes éléments de menu en définissant l' opacity: 0 à la place.

OK, j'ai fini pour la journée. Il est maintenant temps de se détendre avec un peu de médias sociaux.

Facebook

Facebook fait un travail incroyable ici, offrant une masterclass sur l'accessibilité du clavier.

Lors de la toute première pression sur TAB , un menu caché s'ouvre, fournissant des raccourcis vers les sections les plus populaires de la page actuelle et des liens vers d'autres pages populaires.

Lorsque vous parcourez les sections de la page à l'aide des touches fléchées, ces sections sont mises en surbrillance visuellement afin que vous puissiez voir où vous seriez en train de tabuler.

La fonctionnalité la plus utile est que Facebook fournit un raccourci OPT + / (ou ALT + / ) pour revenir au menu à tout moment, en utilisant l'attribut aria-keyshortcuts.

 <div class="a11y-help"> Press opt + / to open this menu </div> <div aria-label="Navigation Assistant" aria-keyshortcuts="Alt+/" role="menubar"> <a class="screen-reader-shortcut" tabindex="1" href="#main-content"> Skip to main content </a> </div>

Contrairement au lien "passer au contenu principal", qui repose sur la technologie d'ancrage native et "fonctionne tout simplement", l'attribut aria-keyshortcuts oblige l'auteur à implémenter tout le comportement du clavier, vous allez donc devoir en écrire JavaScript personnalisé si vous souhaitez l'utiliser.

Voici quelques JS qui cachent et montrent la zone de la barre de menubar , ce qui est un point de départ utile :

 const a11yArea = document.querySelector('*[role="menubar"]'); document.addEventListener('keydown', (e) => { if (e.altKey && e.code === 'Slash') { a11yArea.style.display = a11yArea.style.display === 'block' ? 'none' : 'block'; } });

Sommaire

Cette expérience a été un mélange de bonnes expériences de clavier et de mauvaises. J'ai trois principaux plats à emporter.

Gardez-le élégant

Le problème d'accessibilité au clavier de loin le plus courant auquel j'ai été confronté aujourd'hui est le manque de style de mise au point pour les éléments tabulables. La suppression des styles de focus natifs sans définir de styles de focus personnalisés rend extrêmement difficile, voire impossible, de déterminer où vous vous trouvez sur la page. Supprimer le contour est un faux pas si courant qu'il existe même un site qui lui est dédié.

S'assurer que le style de mise au point natif ou personnalisé est visible est la chose la plus percutante que vous puissiez faire dans le domaine de l'accessibilité au clavier, et c'est souvent l'une des plus simples ; un cas simple de doubler les sélecteurs sur votre style :hover existant. Si vous ne faites qu'une seule chose après avoir lu cet article, ce devrait être de rechercher outline: 0 et outline: none dans votre CSS.

La sémantique est la clé

Combien de fois avez-vous essayé d'ouvrir un lien dans un nouvel onglet, uniquement pour que votre fenêtre actuelle soit redirigée ? Cela m'arrive de temps en temps, et aussi ennuyeux que cela puisse paraître, j'ai la chance que ce soit l'un des seuls problèmes d'utilisabilité auxquels j'ai tendance à être confronté lorsque j'utilise le Web. Ces problèmes découlent d'une mauvaise utilisation de la plate-forme.

Regardons ce code ici :

 <span>Click here</span>

Un utilisateur capable et voyant pourrait cliquer sur le <span> et être redirigé vers Google. Cependant, comme il s'agit d'un <span> et non d'un lien ou d'un bouton, il n'a pas automatiquement de possibilité de mise au point, de sorte qu'un clavier ou un lecteur d'écran n'aurait aucun moyen d'interagir avec lui.

Les utilisateurs de clavier sont des utilisateurs dépendants des normes, tandis que le groupe démographique capable et voyant est suffisamment privilégié pour pouvoir interagir avec l'élément malgré sa non-conformité.

Utilisez les fonctionnalités natives de la plateforme. Écrivez un bon code HTML et utilisez des validateurs tels que https://validator.w3.org pour détecter des éléments tels que les attributs href manquants sur vos ancres.

Le contenu est la clé

Vous pouvez être amené à afficher des avis de cookies, des formulaires d'abonnement, des publicités ou des avis de blocage de publicités.

Faites ce que vous pouvez pour rendre ces expériences discrètes. Si vous ne pouvez pas les rendre discrets, rendez-les au moins éliminables.

Les utilisateurs sont là pour voir votre contenu, pas vos bannières, alors placez ces éléments éliminables en premier dans votre DOM afin qu'ils puissent être rapidement exclu, ou utilisez tabindex="1" si vous ne pouvez pas les déplacer.

Enfin, aidez vos utilisateurs à accéder à votre contenu le plus rapidement possible, en implémentant le Saint Graal des liens "passer au contenu principal".

Restez à l'écoute pour le prochain article de la série, où je m'appuierai sur certaines de ces techniques lorsque j'utiliserai un lecteur d'écran pendant une journée.