Fermer

juin 14, 2021

Exigences JavaScript pour les composants accessibles —15 minutes de lecture



Alerte spoiler : les info-bulles, les modaux, les onglets, les carrousels et les menus déroulants sont quelques-uns des composants de l'interface utilisateur qui nécessitent plus que CSS. Pour garantir l'accessibilité de votre interface, JavaScript est un ajout nécessaire pour effectuer la gestion du focus, répondre aux événements du clavier et basculer les attributs ARIA.

En tant qu'auteur de ModernCSS.devje suis un grand partisan de solutions CSS. Et j'adore voir les façons intelligentes dont les gens utilisent CSS pour des conceptions et une interactivité vraiment prêtes à l'emploi ! Cependant, j'ai remarqué une tendance à la promotion de composants "CSS uniquement" à l'aide de méthodes telles que "checkbox hack". Malheureusement, des hacks comme ceux-ci laissent un nombre important d'utilisateurs incapables d'utiliser votre interface.

Cet article couvre plusieurs composants courants et explique pourquoi CSS n'est pas suffisant pour couvrir l'accessibilité en détaillant les exigences JavaScript. Ces exigences sont basées sur les Web Content Accessibility Guidelines (WCAG) et sur des recherches supplémentaires menées par des experts en accessibilité. Je ne vais pas prescrire de solutions JavaScript ou de démo CSS, mais plutôt examiner ce qui doit être pris en compte lors de la création de chaque composant. Un framework JavaScript peut certainement être utilisé, mais n'est pas nécessaire pour ajouter les événements et fonctionnalités discutés.

Les exigences répertoriées ne sont généralement pas facultatives – elles sont nécessaires pour garantir l'accessibilité de vos composants.

Si vous utilisez un framework ou une bibliothèque de composants, vous pouvez utiliser cet article pour évaluer si les composants fournis satisfont aux exigences d'accessibilité . Il est important de savoir que bon nombre des éléments notés ne seront pas entièrement couverts par des outils de test d'accessibilité automatisés comme aXe, et nécessitent donc des tests manuels. Vous pouvez également utiliser un framework de test tel que Cypress pour créer des tests pour les fonctionnalités requises.

Gardez à l'esprit que cet article vise à vous informer des considérations JavaScript pour chaque composant d'interface. Ce n'est pas une ressource complète pour tous les détails d'implémentation pour créer des composants entièrement accessibles, tels que l'aria nécessaire ou même le balisage. Des ressources sont incluses pour chaque type pour vous aider à en savoir plus sur les considérations plus larges pour chaque composant.

Déterminer si CSS uniquement est une solution appropriée

Voici quelques questions à poser avant de continuer avec une solution CSS uniquement. Nous couvrirons certains des termes présentés ici dans un contexte plus détaillé, ainsi que leurs composants connexes.

  • Est-ce pour votre propre plaisir ?
    Ensuite, lancez-vous absolument sur CSS, repoussez les limites et apprenez ce que le langage peut faire ! 🎉
  • La fonctionnalité inclut-elle l'affichage et le masquage du contenu ?
    Ensuite, vous avez besoin que JS bascule au minimum l'aria et active la fermeture sur Esc. Pour certains types de composants qui changent également d'état, vous devrez peut-être également communiquer les changements en déclenchant des mises à jour dans une région en direct ARIA.
  • L'ordre naturel de mise au point est-il le plus idéal ?
    Si l'ordre naturel perd la relation entre un déclencheur et l'élément qu'il a déclenché, ou un utilisateur du clavier ne peut même pas accéder au contenu via l'ordre de tabulation naturel, alors vous avez besoin de JS pour aider à la gestion du focus.
  • Le contrôle stylisé offre-t-il les informations correctes sur la fonctionnalité ?[19659011]Les utilisateurs de technologies d'assistance comme les lecteurs d'écran reçoivent des informations basées sur la sémantique et l'ARIA qui les aident à déterminer ce que fait un contrôle. De plus, les utilisateurs de la reconnaissance vocale doivent être en mesure d'identifier l'étiquette ou le type du composant pour déterminer la phrase à utiliser pour actionner les commandes. Par exemple, si votre composant est conçu comme des onglets mais utilise des boutons radio pour « fonctionner » comme des onglets, un lecteur d'écran peut entendre « bouton radio » et un utilisateur vocal peut essayer d'utiliser le mot « onglet » pour les faire fonctionner. Dans ces cas, vous aurez besoin de JS pour activer l'utilisation des commandes et de la sémantique appropriées pour obtenir la fonctionnalité souhaitée.
  • L'effet repose-t-il sur le survol et/ou la mise au point ?
    Ensuite, vous aurez peut-être besoin de JS pour vous aider dans une alternative solution pour fournir un accès égal ou un accès permanent au contenu, en particulier pour les utilisateurs d'écrans tactiles et ceux qui utilisent un zoom de bureau de 200%+ ou un logiciel de grossissement.

Astuce rapide : Une autre référence lorsque vous créez n'importe quel type de contrôle personnalisé est la Liste de contrôle de développement accessible pour le contrôle personnalisé du guide W3 « Using ARIA ». Cela mentionne plusieurs points ci-dessus, avec quelques considérations supplémentaires sur la conception et la sémantique.

Info-bulles

Réduire la définition d'une info-bulle est un peu délicat, mais pour cette section, nous parlons de petites étiquettes de texte qui apparaissent au survol de la souris près d'un élément déclencheur. Ils se superposent à d'autres contenus, ne nécessitent aucune interaction et disparaissent lorsqu'un utilisateur supprime le survol ou le focus.

Exemples d'info-bulles de GitHub, Whimsical et Notion
Exemples d'info-bulles de GitHub, Whimsical et Notion. ( Grand aperçu)

La solution CSS uniquement ici peut sembler tout à fait correcte et peut être accomplie avec quelque chose comme :


Info-bulle

.info-bulle {
affichage : aucun ;
}

.tooltip-trigger:hover + .tooltip,
.tooltip-trigger:focus + .tooltip {
bloc de visualisation;
}

Cependant, cela ignore toute une liste de problèmes d'accessibilité et empêche de nombreux utilisateurs d'accéder au contenu de l'info-bulle.

Un grand groupe d'utilisateurs exclus sont ceux qui utilisent des écrans tactiles où :hover ne sera peut-être pas déclenché car sur les écrans tactiles, un événement :hover se déclenche en synchronisation avec un événement :focus. Cela signifie que toute action connexe connectée à l'élément déclencheur, comme un bouton ou un lien, se déclenchera en même temps que l'info-bulle révélée. Cela signifie que l'utilisateur peut manquer l'info-bulle ou ne pas avoir le temps de lire son contenu.

Dans le cas où l'info-bulle est attachée à un élément interactif sans événement, l'info-bulle peut s'afficher mais ne pas être ignorée jusqu'à ce qu'un autre élément obtienne le focus , et dans l'intervalle peut bloquer le contenu et empêcher un utilisateur d'effectuer une tâche.

De plus, les utilisateurs qui ont besoin d'utiliser un logiciel de zoom ou d'agrandissement pour naviguer rencontrent également un obstacle à l'utilisation des info-bulles. Étant donné que les info-bulles sont révélées au survol, si ces utilisateurs doivent modifier leur champ de vision en déplaçant l'écran pour lire l'info-bulle, cela peut la faire disparaître. Les info-bulles suppriment également le contrôle de l'utilisateur car il n'y a souvent rien pour indiquer à l'utilisateur qu'une info-bulle apparaîtra à l'avance. La superposition de contenu peut les empêcher d'effectuer une tâche. Dans certaines circonstances, comme une info-bulle liée à un champ de formulaire, les claviers mobiles ou autres à l'écran peuvent masquer le contenu de l'info-bulle. Et, s'ils ne sont pas correctement connectés à l'élément déclencheur, certains utilisateurs de technologies d'assistance peuvent même ne pas savoir qu'une info-bulle est apparue.

Les conseils pour le comportement des info-bulles proviennent du Critère de succès WCAG 1.4.13 — Contenu au survol. ou Focus. Ce critère est destiné à aider les utilisateurs malvoyants et ceux qui utilisent des logiciels de zoom et de grossissement. Les principes directeurs de l'info-bulle (et d'autres contenus apparaissant sur le survol et la mise au point) incluent :

  • Ignorable
    L'info-bulle peut être ignorée sans déplacer le survol ou le focus
  • Hoverable
    Le contenu de l'info-bulle révélé peut être survolé sans elle disparition
  • Persistant
    Le contenu supplémentaire ne disparaît pas en fonction d'un délai d'attente, mais attend qu'un utilisateur supprime le survol ou le focus ou le rejette d'une autre manière

Pour répondre pleinement à ces directives, il faut une assistance JavaScript, en particulier pour permettre rejetant le contenu.

  • Les utilisateurs de technologies d'assistance supposeront que le comportement de rejet est lié à la touche Escqui nécessite un écouteur JavaScript.
  • Selon les recherches de Sarah Higley décrites dans la section suivante, l'ajout un bouton « fermer » visible dans l'info-bulle nécessiterait également que JavaScript gère son événement de fermeture.
  • Il est possible que JavaScript doive augmenter votre solution de style pour assurer un l'utilisateur peut survoler le contenu de l'info-bulle sans qu'elle ne s'efface pendant que l'utilisateur déplace sa souris.

Alternatives aux info-bulles

Les info-bulles doivent être un dernier recours. Sarah Higley — une experte en accessibilité qui a une passion particulière pour dissuader l'utilisation des info-bulles — propose ce test simple :

« Pourquoi est-ce que j'ajoute ce texte à l'interface utilisateur ? Où d'autre pourrait-il aller ? »

— Sarah Higley de la présentation «  Info-bulles : enquête sur quatre parties »

Sur la base des recherches auxquelles Sarah a participé pour son rôle chez Microsoft, un une solution alternative est un « toggletip » dédié. Essentiellement, cela signifie fournir un élément supplémentaire pour permettre à un utilisateur de déclencher intentionnellement l'affichage et le masquage de contenu supplémentaire. Contrairement aux infobulles, les infobulles peuvent conserver la sémantique des éléments dans le contenu révélé. Ils redonnent également à l'utilisateur le contrôle de les basculer, et conservent la possibilité de découvrir et d'exploiter par plus d'utilisateurs et en particulier les utilisateurs d'écran tactile.

Si vous vous souvenez que l'attribut title existe, sachez simplement qu'il souffre des mêmes problèmes que nous avons notés avec notre solution CSS uniquement. En d'autres termes, n'utilisez pas title en supposant qu'il s'agit d'une solution d'info-bulle acceptable.

Pour plus d'informations, consultez la présentation de Sarah sur YouTube ainsi que son article détaillé sur les info-bulles . Pour en savoir plus sur les infobulles par rapport aux infobulles et un peu plus d'informations sur pourquoi ne pas utiliser titleconsultez l'article de Heydon Pickering dans Inclusive Components : Tooltips and Toggletips.

Modals

Les modaux – alias lightboxes ou boîtes de dialogue – sont des fenêtres dans la page qui apparaissent après une action de déclenchement. Ils recouvrent d'autres contenus de page, peuvent contenir des informations structurées, y compris des actions supplémentaires, et ont souvent un arrière-plan semi-transparent pour aider à distinguer la fenêtre modale du reste de la page.

Exemple de modaux de GitHub et Material Design
Exemple de modaux de GitHub et Material Design. ( Grand aperçu)

J'ai vu quelques variantes d'un modal CSS uniquement (et je suis coupable d'en avoir créé un pour une ancienne version de mon portfolio). Ils peuvent utiliser le "piratage de case à cocher", utiliser le comportement de :targetou essayer de le façonner à partir de :focus (qui est probablement vraiment une info-bulle trop grande déguisée) .

En ce qui concerne l'élément HTML dialogsachez qu'il n'est pas considéré comme entièrement accessible. Ainsi, bien que j'encourage absolument les gens à utiliser le HTML natif avant les solutions personnalisées, malheureusement, celle-ci casse cette idée. Vous pouvez en savoir plus sur pourquoi la boîte de dialogue HTML n'est pas accessible.

Contrairement aux info-bulles, les modaux sont destinés à autoriser un contenu structuré. Cela signifie potentiellement un titre, du contenu de paragraphe et des éléments interactifs tels que des liens, des boutons ou même des formulaires. Pour que la plupart des utilisateurs puissent accéder à ce contenu, ils doivent pouvoir utiliser les événements de clavieren particulier la tabulation. Pour un contenu modal plus long, les touches fléchées doivent également conserver la possibilité de faire défiler. Et comme les info-bulles, elles devraient être ignorées avec la touche Esc – et il n'y a aucun moyen de l'activer avec CSS uniquement.

JavaScript est requis pour la gestion du focus dans les modaux. Les modaux devraient piéger le focus, ce qui signifie qu'une fois que le focus est dans le modal, un utilisateur ne devrait pas pouvoir en sortir dans le contenu de la page derrière lui. Mais d'abord, le focus doit obtenir à l'intérieur du modal, ce qui nécessite également JavaScript pour une solution modale entièrement accessible.

Voici la séquence d'événements liés au mode qui doivent être gérés avec JavaScript :

  1. L'écouteur d'événement sur un bouton ouvre le modal
  2. Le focus est placé dans le modal ; quel élément varie en fonction du contenu modal (voir arbre de décision)
  3. Le focus est piégé dans le modal jusqu'à ce qu'il soit rejeté
  4. De préférence, un utilisateur peut fermer un modal avec la touche Esc en plus à un bouton de fermeture dédié ou une action de bouton destructrice telle que « Annuler » si la reconnaissance du contenu modal est requise
    1. Si Esc est autorisé, les clics sur le fond modal doivent également ignorer le modal
  5. En cas de rejet, si aucune navigation n'a eu lieu, le focus est remis sur l'élément déclencheur de bouton

Basé sur le WAI-ARIA Authoring Practices Modal Exemple de boîte de dialogue voici un arbre de décision simplifié pour savoir où placer le focus une fois qu'un modal est ouvert. Le contexte dictera toujours le choix ici, et idéalement, la focalisation est gérée au-delà du simple « premier élément focalisable ». En fait, il est parfois nécessaire de sélectionner des éléments non focalisables.

  • Le sujet principal du modal est un formulaire.
    Concentrez le premier champ de formulaire.
  • Le contenu modal a une longueur importante et repousse les actions modales hors de vue.
    Concentrez-vous sur un titre si présent, ou sur le premier paragraphe.
  • Le but du modal est procédural (exemple : confirmation de l'action) avec plusieurs actions disponibles.
    Concentrez-vous sur l'action « la moins destructrice » en fonction du contexte ( exemple : « OK »).
  • Le but du modal est procédural avec une seule action.
    Concentrez-vous sur le premier élément focalisable

Astuce rapide : Dans le cas où vous devez focaliser un non -élément focalisable, tel qu'un titre ou un paragraphe, ajoutez tabindex="-1" qui permet à l'élément de devenir focalisable par programmation avec JS mais ne l'ajoute pas à l'ordre de tabulation DOM.[19659003]Reportez-vous à la Démo modale WAI-ARIA pour plus d'informations sur les autres exigences de configuration u p ARIA et des détails supplémentaires sur la façon de sélectionner l'élément auquel ajouter le focus. La démo inclut également JavaScript pour illustrer comment gérer la mise au point.

Pour une solution prête à l'emploi, Kitty Giraudel a créé a11y-dialog qui inclut les exigences de fonctionnalités dont nous avons discuté. Adrian Roselli a également recherché la gestion du focus des dialogues modaux et créé une démo et compilé des informations sur la façon dont différentes combinaisons de navigateurs et de lecteurs d'écran communiqueront l'élément focalisé.

Tabs

Les interfaces à onglets impliquent une série de déclencheurs qui affichent les panneaux de contenu correspondants un par un. Les "hacks" CSS que vous pouvez trouver pour ceux-ci impliquent l'utilisation de boutons radio stylisés, ou :targetqui ne permettent tous deux de révéler qu'un seul panneau à la fois.

Grand aperçu)

Voici les fonctionnalités des onglets qui nécessitent JavaScript :

  1. Basculer l'attribut aria-selected sur true pour l'onglet actuel et false pour les onglets non sélectionnés[19659041]Créer un tabindex itinérant pour distinguer la sélection d'onglet du focus
  2. Déplacer le focus entre les onglets en répondant aux événements de touches fléchées (et éventuellement Home et End)[19659085]En option, vous pouvez faire en sorte que la sélection d'onglets suive le focus – ce qui signifie qu'un onglet est également sélectionné et affiche son panneau d'onglets associé. Les pratiques de création WAI-ARIA proposent ce guide pour choisir si la sélection doit suivre le focus.

    Que vous choisissiez ou non que la sélection suive le focus, vous utiliserez également JavaScript pour écouter la touche fléchée. événements pour déplacer le focus entre les éléments de l'onglet. Il s'agit d'un modèle alternatif pour permettre la navigation des options de tabulation puisque l'utilisation d'un tabindex itinérant (décrit ci-après) modifie l'ordre naturel de mise au point des tabulations du clavier.

    À propos de l'itinérance tabindex

    ]Le concept d'un tabindex itinérant est que la valeur de tabindex est contrôlée par programmation pour gérer l'ordre de mise au point des éléments. En ce qui concerne les onglets, cela signifie que seul l'onglet sélectionné fait partie de l'ordre de mise au point en définissant tabindex="0"et les onglets non sélectionnés sont définis sur tabindex="-1" qui les supprime de l'ordre naturel du focus du clavier.

    La raison en est que lorsqu'un onglet est sélectionné, l'onglet suivant attirera le focus d'un utilisateur dans le panneau d'onglets associé. Vous pouvez choisir de rendre l'élément qui est le panneau à onglets focalisable en lui attribuant tabindex="0"ou cela peut ne pas être nécessaire s'il y a une garantie d'un élément focalisable dans le panneau à onglets. Si le contenu de votre panneau d'onglets est plus variable ou complexe, vous pouvez envisager de gérer le focus en fonction de l'arbre de décision que nous avons examiné pour les modaux.

    Exemple de modèles d'onglets

    Voici quelques modèles de référence pour la création d'onglets :

    Carrousels[19659009]Aussi appelés diaporamas ou curseurs, les carrousels impliquent une série de panneaux de contenu rotatifs (alias « diapositives ») qui incluent des mécanismes de contrôle. Vous les trouverez dans de nombreuses configurations avec un large éventail de contenus. Ils sont quelque peu notoirement considérés un mauvais modèle de conception.

    Un exemple de démo de carrousel créé avec bxSlider
    Un exemple de démo de carrousel créé avec bxSlider. ( Grand aperçu)

    La partie délicate des carrousels CSS uniquement est qu'ils peuvent ne pas offrir de contrôles, ou qu'ils peuvent utiliser des contrôles inattendus pour manipuler le mouvement du carrousel. Par exemple, vous pouvez à nouveau utiliser le « piratage de la case à cocher » pour provoquer la transition du carrousel, mais les cases à cocher transmettent le mauvais type d'informations sur l'interaction aux utilisateurs de la technologie d'assistance. De plus, si vous stylisez les étiquettes des cases à cocher pour qu'elles apparaissent visuellement sous forme de flèches vers l'avant et vers l'arrière, vous risquez de donner aux utilisateurs de logiciels de reconnaissance vocale une mauvaise impression de ce qu'ils doivent dire pour contrôler le carrousel.

    Plus récemment, natif La prise en charge CSS de l'accrochage au défilement est arrivée. Au début, cela semble être la solution parfaite uniquement en CSS. Mais, même la vérification d'accessibilité automatisée les signalera comme non navigables par les utilisateurs de clavier au cas où il n'y aurait aucun moyen de les parcourir via des éléments interactifs. Il y a d'autres problèmes d'accessibilité et d'expérience utilisateur avec le comportement par défaut de cette fonctionnalité, dont certains que j'ai inclus dans ma démo de défilement instantané sur SmolCSS.

    Malgré la large gamme d'apparence des carrousels, il y a sont des traits communs. Une option consiste à créer un carrousel à l'aide du balisage de tabulation puisqu'il s'agit effectivement de la même interface sous-jacente avec une présentation visuelle modifiée. Par rapport aux onglets, les carrousels peuvent offrir des contrôles supplémentaires pour le précédent et le suivant, ainsi qu'une pause si le carrousel est en cours de lecture automatique.

    Les éléments suivants sont des considérations JavaScript en fonction des fonctionnalités de votre carrousel :

    • Utilisation des contrôles paginés
      Dès la sélection d'un élément numéroté, concentrez par programmation la diapositive de carrousel associée. Cela impliquera la configuration de conteneurs de diapositives à l'aide de tabindex itinérants afin que vous puissiez vous concentrer sur la diapositive actuelle, mais empêcher l'accès aux diapositives hors écran.
    • Utilisation de la lecture automatique
      Inclure un contrôle de pause et également activer la pause lorsque la diapositive est survolé ou qu'un élément interactif qu'il contient est focalisé. De plus, vous pouvez vérifier préfère-mouvement réduit dans JavaScript pour charger le diaporama en pause afin de respecter les préférences de l'utilisateur.
    • À l'aide des commandes précédentes/suivantes
      Inclure un élément visuellement caché marqué comme aria-live="polite" et lors de l'activation de ces commandes, remplissez la région en direct avec une indication de la position actuelle, telle que "Diapositive 2 sur 4".

    Ressources pour la création de carrousels accessibles

    Il s'agit d'un composant dans lequel un bouton permet d'ouvrir une liste de liens, généralement utilisés pour les menus de navigation. Les implémentations CSS qui s'arrêtent à afficher le menu sur :hover ou :focus ne manquent que quelques détails importants.

    Exemple de menus déroulants de Dribbble, recherche Google et GitHub
    Exemple menus déroulants de Dribbble, de la recherche Google et de GitHub. ( Grand aperçu)

    J'admets que j'ai même pensé qu'en utilisant la nouvelle propriété :focus-withinnous pourrions implémenter en toute sécurité une solution CSS uniquement. Vous verrez que mon article sur les menus déroulants CSS a été modifié pour inclure des notes et des ressources sur le JavaScript nécessaire (j'ai conservé le titre afin que les autres personnes à la recherche de cette solution complètent également l'implémentation JS). Plus précisément, s'appuyer uniquement sur CSS signifie enfreindre le Critère de succès WCAG 1.4.13 : Contenu au survol ou à la mise au point que nous avons appris avec les info-bulles.

    Nous devons ajouter JavaScript pour certaines techniques qui devraient vous sembler familières à ce point :

    • Basculer aria-expanded sur le bouton de menu entre true et false en écoutant les événements click
    • Fermeture d'un menu ouvert lors de l'utilisation de la touche Esc et retour du focus au bouton bascule de menu
    • De préférence, fermeture des menus ouverts lorsque le focus est déplacé en dehors du menu
    • Facultatif : implémentez les touches fléchées ainsi que les touches Accueil et End pour la navigation au clavier entre les boutons de basculement de menu et les liens dans les listes déroulantes

    Astuce rapide : Assurez-vous que bonne mise en œuvre du menu déroulant en associant l'affichage du menu à la sélection tor de .dropdown-toggle[aria-expanded="true"] + .dropdown plutôt que de baser l'affichage du menu sur la présence d'un JS- supplémentaire classe ajoutée comme active. Cela supprime également une certaine complexité de votre solution JS !

    Ceci est également appelé « modèle de divulgation » et vous pouvez trouver plus de détails dans Example Disclosure Navigation Menu WAI-ARIA Authoring Practices. ].

    Ressources supplémentaires sur la création de composants accessibles

    Smashing Editorial" width="35" height="46" loading="lazy" decoding="async(vf, il)




Source link

0 Partages