Il y a beaucoup de buzz autour de l'accessibilité du Web, et Internet regorge d'informations sur ce sujet. Lorsque WebAIM a mené . Les efforts de test d'accessibilité se produisent à la fin du développement du produit dans de nombreuses entreprises, mais pas toutes. Par conséquent, en formant les développeurs et en donnant la priorité à l'accessibilité Web pendant le processus de développement, le nombre d'erreurs d'accessibilité peut être considérablement réduit. une étude sur les 1 000 000 de sites Web les plus importants, ils ont trouvé un total de 50 829 406 erreurs d'accessibilité distinctes, soit une moyenne de 50,8 erreurs par page Comprendre l'accessibilité Web En termes simples, l'accessibilité du Web signifie que le Web est accessible aux personnes handicapées. Voici un exemple pour aider à mieux comprendre : les utilisateurs aveugles naviguent généralement sur l'ordinateur à l'aide d'un lecteur d'écran, qui est un outil de synthèse vocale qui leur dicte des informations à l'écran. Lorsque vous rendez votre site Web accessible, le lecteur d'écran peut fournir avec succès ces informations à l'utilisateur. Si votre site Web est inaccessible, le lecteur d'écran fournit des informations inexactes ou incomplètes à l'utilisateur. En d'autres termes, l'utilisation de technologies d'assistance telles que les lecteurs d'écran ne fonctionne bien que si les sites Web avec lesquels ils interagissent sont conçus en tenant compte de l'accessibilité. Le mot « accessible » est différent de « utilisable ». Un site Web peut être accessible dans le sens où il répond au strict minimum pour qu'un site Web soit conforme à la loi, mais il se peut qu'il n'offre toujours pas l'expérience la plus conviviale pour les personnes handicapées. Par conséquent, il est important d'essayer au moins de faire un effort supplémentaire pour rendre votre site Web accessible et utilisable par les personnes handicapées. Nous verrons plus loin dans cet article comment procéder. Cinq façons d'intégrer l'accessibilité à votre site Web Configurez un pipeline d'accessibilité automatisé. L'un des moyens les plus simples et les plus rapides de commencer à intégrer l'accessibilité dans votre application est de suivre la philosophie du , ce qui signifie que les tests d'accessibilité doivent commencer le plus tôt possible dans le processus de développement et ne pas attendre le dernier moment. Il existe différents vérificateurs d'accessibilité qui peuvent vous aider à configurer des tests d'accessibilité automatisés pour votre site Web - allant de quelque chose que vous pouvez exécuter manuellement dans votre navigateur à des outils que vous pouvez intégrer dans votre pipeline CI/CD. décalage vers la gauche Les extensions de navigateur gratuites incluent des outils tels que et . Une fois installés, vous pouvez les exécuter à tout moment sur votre page Web, et ils vous montreront les erreurs d'accessibilité sur votre site Web, allant des étiquettes ARIA manquantes pour vos formulaires aux problèmes de contraste des couleurs. Ces outils sont un excellent moyen de commencer votre parcours d'accessibilité automatisé. Les développeurs peuvent également utiliser des linters de code tels que pour détecter les problèmes au fur et à mesure qu'ils codent dans votre IDE. Selon Deque, VAGUE Informations sur l'accessibilité hache Accessibilité Linter les outils automatisés détectent actuellement 57 % des problèmes d'accessibilité, contre 20 % pour l'industrie. Apprenez de vos résultats d'accessibilité automatisés. Vous avez mis en place des tests d'accessibilité automatisés pour votre site Web, c'est très bien. Cependant, apprenez-vous des erreurs d'accessibilité détectées ? Par exemple, si vous rencontrez de nombreuses erreurs liées à des étiquettes manquantes pour les formulaires ou à un texte alternatif manquant pour les images, il est important de vous assurer de ne pas répéter ces erreurs à l'avenir. Si vous rencontrez de nombreux problèmes de contraste sur votre site Web, il peut être judicieux de parler à votre équipe de conception pour évaluer les couleurs et les thèmes de votre site Web. Une autre façon de vous assurer que vous ne répétez pas de simples erreurs d'accessibilité consiste à effectuer des revues de code - assurez-vous de rechercher le code inaccessible lors des revues de code ! Certains éléments faciles à repérer sont les étiquettes ARIA manquantes pour les éléments qui n'ont pas d'étiquette visible claire, le texte alternatif manquant pour les images et les titres de page manquants. L'utilisation d'outils de test automatisés est excellente, mais son efficacité peut être encore améliorée si vous corrigez de manière préventive les problèmes qu'il détecte couramment. Navigation au clavier + test du lecteur d'écran Si vous souhaitez aller plus loin que les tests d'accessibilité automatisés, assurez-vous de tester votre site Web à l'aide d'un clavier. Tous les éléments interactifs doivent être accessibles via les touches de tabulation, et les éléments tels que les menus déroulants doivent être accessibles via les touches fléchées. Plus d'informations sur les frappes appropriées pour divers éléments de l'interface utilisateur peuvent être trouvées ici : https://webaim.org/techniques/keyboard/ Si vous constatez que quelque chose n'est pas accessible via le clavier, demandez-vous : est-ce censé être accessible ? Les éléments tels qu'une cellule de tableau statique n'ont pas besoin d'être accessibles via un clavier. S'il s'agit d'un élément interactif personnalisé qui doit être accessible via le clavier et qu'il ne l'est pas, vous devrez le rendre accessible par programmation. Cela peut être fait en ajoutant un tabindex de 0, qui ajoutera l'élément à l'ordre de tabulation de la page Web, puis en définissant des gestionnaires d'événements tels que "onKeyPress", qui invoquera l'action nécessaire sur une pression de touche. Par exemple, cet extrait de code ajoute un tabIndex de 0 à l'élément de bouton, ce qui le rend focalisable et accessible via le clavier. Le gestionnaire d'événements écoute l'événement "keydown" et déclenche un clic sur le bouton si la touche Entrée est enfoncée. <button id="myButton">Click me</button> const button = document.getElementById("myButton"); button.tabIndex = 0; button.addEventListener("keydown", function(event) { if (event.key === "Enter") { button.click(); } }); Si vous voulez aller plus loin, essayez d'utiliser un lecteur d'écran pour tester votre site Web. Cela peut être une bonne idée si votre site Web ne passe par aucun fournisseur tiers d'accessibilité finale pour les tests manuels. Vous n'avez pas besoin d'effectuer des tests détaillés de lecteur d'écran en tant que développeur, mais vous pouvez essayer de naviguer sur le site Web avec un lecteur d'écran. Vérifiez par exemple si les étiquettes appropriées pour les éléments de formulaire sont annoncées, si des informations redondantes sont transmises, si les informations d'un tableau sont accessibles, etc. Windows Narrator et Voiceover pour Mac sont de bonnes options pour les lecteurs d'écran gratuits. Les lecteurs d'écran se synchronisent avec les commandes de navigation habituelles au clavier, mais disposent en outre de commandes spécifiques pour naviguer dans divers éléments d'un site Web. Par exemple, pour VoiceOver, vous pouvez rechercher ces commandes ici : . https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts Familiarisez-vous avec certains outils de débogage d'accessibilité. Des outils tels que l'arborescence d'accessibilité du navigateur peuvent vous aider à examiner les états d'accessibilité et les propriétés des éléments de l'interface utilisateur sur votre site Web. Cet outil est particulièrement utile pour corriger les bogues d'accessibilité, car il peut vous montrer quelles propriétés d'accessibilité sont exposées aux technologies d'assistance telles qu'un lecteur d'écran. Pour voir l'arborescence d'accessibilité dans Google Chrome, ouvrez Devtools sur votre navigateur et cliquez sur le volet d'accessibilité. Cela devrait être à côté du volet de mise en page. En savoir plus sur l'arborescence d'accessibilité ici : https://developer.chrome.com/blog/full-accessibility-tree/#what-is-the-accessibility-tree Un autre outil utile que vous pouvez utiliser est qui mettent également en évidence les rôles, les états et les propriétés des éléments. Cela fonctionne également sur les téléphones portables. Les deux outils sont utiles pour savoir quelles informations sont transmises aux technologies d'assistance et sont donc extrêmement utiles pour corriger les bogues. les bookmarklets de Paul Tenir compte de divers autres handicaps En plus des tests de lecture d'écran et de clavier, qui peuvent aider les personnes aveugles ou ayant un handicap moteur, vous devriez également envisager de répondre aux besoins des personnes ayant d'autres handicaps. Si votre site Web contient des vidéos, assurez-vous d'y inclure des légendes précises. Pour les personnes ayant des troubles cognitifs, WCAG a un sur la façon de leur rendre le contenu accessible. Considérez également d'autres handicaps tels que le daltonisme. L'analyseur de contraste des couleurs de TPGi dispose d'un , qui peut être un excellent outil pour vous assurer que votre site Web utilise des couleurs et des thèmes accessibles. excellent guide simulateur de daltonisme Enfin, si votre site Web dispose d'une fonctionnalité de synthèse vocale personnalisée, assurez-vous qu'il est accessible à une personne ayant des troubles de la parole. Une façon de le faire peut être de donner un temps raisonnable aux personnes atteintes de troubles de la parole pour terminer ce qu'elles ont à dire. Conclusion L'accessibilité numérique est importante pour que le milliard de personnes handicapées de cette planète puisse avoir un accès équitable au Web. En regardant l'état actuel de l'accessibilité numérique, nous ne nous en sortons peut-être pas très bien. Selon un , "2022 a marqué une autre année de plus de 4 000 procès [d'accessibilité]." En utilisant certaines des stratégies décrites ci-dessus, les développeurs peuvent intégrer l'accessibilité dans le processus de développement et détecter et corriger autant d'erreurs que possible avant que quelqu'un ne subisse une expérience frustrante. rapport récent de UsableNet

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Making security fun one episode at a time

Construire un meilleur Web : un guide d'accessibilité pour les développeurs

Trop long; Pour lire

Meenakshi Das

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

Construire un meilleur Web : un guide d'accessibilité pour les développeurs

Trop long; Pour lire

Meenakshi Das

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES