L'équipe Axe a pris position en faveur de l'accessibilité. Nous n'allons pas fermer les yeux sur les lacunes en matière de prise en charge dans les navigateurs et les technologies d'assistance, et vous ne devriez pas non plus. Dans cet article, nous allons vous présenter les efforts déployés par l'équipe Axe pour garantir une prise en charge étendue des tests d'accessibilité.
Au sein de l'équipe axe-core , on nous pose souvent des questions pour savoir pourquoi Axe signale (ou ne signale pas) certaines choses, ou encore quand certaines techniques de développement seront prises en charge. De ARIA 1.1 à WCAG 2.1 et au-delà, l’équipe de Deque applique un critère particulier pour décider d’inclure une nouvelle fonctionnalité : celle-ci doit être prise en charge par un ensemble minimal raisonnable de navigateurs et de technologies d’assistance (AT). Ce critère, appelé« accessibilité prise en charge »dans les Directives pour l’accessibilité des contenus Web (WCAG), est au cœur de la manière dont nous développons et maintenons la axe-core bibliothèque de tests d’accessibilité.
De nouvelles normes technologiques apparaissent sans cesse dans le domaine du développement web. Les technologies d’assistance (TA) et les navigateurs – également appelés « agents utilisateurs » – doivent être repensés ou modifiés pour prendre en charge ces nouvelles technologies, telles que les rôles, états et propriétés de pointe d’ARIA 1.1 ; le Shadow DOM et les composants web ; ou encore les fonctionnalités d’accessibilité du format SVG. Le recours à des technologies web qui ne sont pas entièrement prises en charge signifie que, parfois, certaines fonctionnalités ne fonctionneront pas comme prévu dans les navigateurs ou les technologies d’assistance de nos utilisateurs. Les utilisateurs en situation de handicap peuvent se retrouver laissés pour compte malgré tous nos efforts pour rendre les contenus accessibles (« J’utilise cette nouvelle fonctionnalité ARIA pour l’accessibilité, mais je ne l’ai testée que dans un seul navigateur ! »).
Selon le W3C, il n'existe pas de nombre fixe de navigateurs ou de technologies d'assistance requis pour garantir l'accessibilité, car toute norme en la matière constituerait une cible complexe et mouvante, vouée à devenir rapidement obsolète. Les auteurs de sites Web devraient plutôt utiliser des techniques de développement respectueuses de l'accessibilité pour tous les principaux navigateurs qu'ils prennent en charge et effectuer des tests avec les technologies d'assistance les plus répandues.
Comment évaluons-nous le soutien à l'accessibilité pour Axe ?
Dans axe-core, nous prenons en charge un ensemble commun de navigateurs modernes et de technologies d'assistance afin que toute technique recommandée par l'API fonctionne dans divers scénarios d'utilisation. Si une technique échoue sur ne serait-ce qu’une seule plateforme importante en matière d’accessibilité (telle que Safari avec VoiceOver ou Firefox avec NVDA, toutes deux couramment utilisées par les personnes en situation de handicap), cela signifie pour nous qu’elle n’est pas prise en charge en termes d’accessibilité et qu’elle n’est donc pas prise en charge dans axe. Nos décisions concernant la prise en charge de l’accessibilité se reflètent principalement dans le code axe-core pour les règles et les vérifications : le résultat pour une technique non prise en charge est généralement une violation ou un élément à examiner.
En nous limitant exclusivement au soutien à l’accessibilité – que l’équipe évalue pour chaque modification pertinente apportée à axe-core –, nous pouvons réduire le besoin de nos clients et de nos collègues de procéder à des tests manuels sur chaque navigateur et chaque outil d’assistance, ce qui représente un gain de temps et une économie considérables. L’inconvénient est que cela peut parfois retarder l’adoption de nouvelles fonctionnalités, même si celles-ci sont décrites dans la spécification ARIA, car les navigateurs ou les outils d’assistance ne les prennent tout simplement pas encore en charge.
Dans les règles d'axe-core , il est possible de contourner certaines limitations de prise en charge si une nouvelle technologie est ignorée de manière transparente (c'est-à-dire si le système revient au comportement par défaut) ou si elle n'a pas d'impact négatif sur les utilisateurs (comme par exemple aria-errormessage avec un peu d'aide de la part de aria-describedby). Ce n'est pas toujours le cas ; c'est pourquoi nous testons et évaluons manuellement chaque nouvelle fonctionnalité en fonction de la prise en charge actuelle, des solutions de contournement disponibles et (parfois) des informations historiques concernant les bogues des navigateurs ou des technologies d'assistance signalés il y a plusieurs années et toujours en attente de résolution.
En tant qu’outil de test largement adopté, axe-core impose un ensemble assez vaste d’exigences en matière d’accessibilité. Au sein de l’équipe Axe, nous nous posons souvent la question suivante : « Ces techniques fonctionnent-elles dans le plus grand nombre de cas possible ? » Nous évaluons chaque modification apportée à une règle ou à un contrôle afin de vérifier son fonctionnement dans les principales combinaisons d’aides techniques et de navigateurs, et nous avons malheureusement dû rejeter des soumissions de code pour des techniques qui échouaient dans au moins l’une d’entre elles.
Votre politique d'accessibilité ne correspond pas à 100 % à celle décrite sur axe-core – que faire maintenant ?
Compte tenu de la diversité des méthodes permettant de créer des sites web accessibles, il n’est pas rare que les politiques en matière de prise en charge de l’accessibilité varient. Certaines organisations imposent leurs propres restrictions, comme l’interdiction de la propriété `aria-label` à l’échelle de l’entreprise ou l’autorisation des nouvelles fonctionnalités ARIA 1.1 indépendamment de leur prise en charge. Une application web peut être limitée à certains navigateurs ou à des environnements fermés, rendant ainsi caduques les questions relatives à une prise en charge plus large de l'accessibilité. Dans ces nombreux cas de figure, il est à la fois normal et prévisible que les résultats par défaut d'axe diffèrent des directives internes d'une entreprise en matière d'accessibilité.
Lorsque vous effectuez des tests d'accessibilité avec Axe et que vous constatez des divergences au niveau des règles, plusieurs options s'offrent à vous pour y remédier :
- Modifiez l'ensemble de règles par défaut d'axe-core à l'aide de l'API `axe.configure`.
- Créez un ticket sur GitHub pour discuter de la prise en charge d'axe-core (après avoir d'abord recherché les tickets existants sur le sujet !)
- Passez à WorldSpace Attest et déployez des configurations de règles personnalisées auprès de tous les membres de votre équipe.
Le choix de la voie à suivre dépend des besoins et de la situation de votre équipe. Plutôt que de tout reprendre ici, je vous invite à lire mon dernier article, « Moving Beyond axe to WorldSpace Attest », pour en savoir beaucoup plus sur le choix entre axe et Attest .
Soutenir ou ne pas soutenir… voilà une bonne question
Pour les organisations disposant de leurs propres politiques internes en matière d'accessibilité, décider s'il convient de prendre en charge des techniques présentant des limites connues – comme celles qui ne fonctionnent pas sur Safari sous iOS et VoiceOver – relève à la fois d'un choix difficile et d'une situation en constante évolution.
Parfois, les politiques en matière d’accessibilité reposent sur un ensemble limité de combinaisons de navigateurs et de technologies d’assistance (par exemple : « pas d’IE ! »). D’autres fois, les exigences découlent de normes d’entreprise convenues. Des restrictions acceptables peuvent commencer à s’immiscer dans le contenu des intranets privés, où il est recommandé aux utilisateurs d’utiliser des versions spécifiques de navigateurs ou de technologies d’assistance (par exemple, le cas d’Edge). Pour les sites accessibles à tous, vous devez vous efforcer de prendre en charge autant de navigateurs et de technologies d'assistance que possible dans un délai raisonnable.
Lorsque les équipes doivent prendre des décisions concernant l’accessibilité, leur première question est souvent : « Combien d’utilisateurs de technologies d’assistance consultent réellement notre site ? » Bien qu’il soit possible de recueillir des informations sur les navigateurs utilisés par les visiteurs et de savoir s’ils utilisent des appareils mobiles ou des ordinateurs de bureau, pour des raisons de confidentialité, il n’existe pas de statistiques spécifiques aux technologies d’assistance. Il existe toutefois plusieurs éléments que vous pouvez exploiter pour élaborer une politique d’accessibilité qui réponde aux besoins de vos utilisateurs :
- Consultez les statistiques de votre site pour identifier les versions les plus anciennes des navigateurs (IE 9 ? 10 ? 11 ?)
- Consultez la dernière enquête de WebAIM sur les lecteurs d'écran pour découvrir les technologies d'assistance les plus populaires.
- Déterminez à quel moment cesser la prise en charge des anciennes versions de navigateurs ou d'outils d'accessibilité, et consignez ces décisions dans votre déclaration d'accessibilité. (Vous disposez bien d'une déclaration d'accessibilité, n'est-ce pas ?)
Vous devrez faire des choix quant aux navigateurs et aux technologies d'assistance à prendre en charge, car tout inclure demanderait un temps et une attention infinis, alors que nous nous battons encore pour mettre en place les fonctionnalités de base.
Même s’il est tentant de ne prendre en charge que les navigateurs et les technologies d’assistance les plus récents et les plus performants, il faut garder à l’esprit que certains utilisateurs en situation de handicap ne disposent pas des ressources nécessaires pour effectuer une mise à jour rapidement, que ce soit en raison d’une aide financière de l’État ou parce qu’ils utilisent du matériel informatique obsolète. Il peut être difficile de trouver le juste équilibre, c’est pourquoi les équipes prennent souvent en charge les combinaisons les plus courantes pour la version la plus récente et celle qui la précède :
- NVDA et Firefox sous Windows
- JAWS et IE11
- VoiceOver et Safari (OS X et appareils mobiles)
- TalkBack d'Android et navigateur d'origine
- Dragon NaturallySpeaking et Chrome ou IE11
Souvent, l’accessibilité est inégale selon les navigateurs et les technologies d’assistance, ce qui signifie que certaines fonctionnalités sont bien prises en charge tandis que d’autres présentent des lacunes. Par exemple, VoiceOver est un lecteur d’écran de premier plan à certains égards, comme pour la requête média `prefers-reduced-motion` ; mais il manque de prise en charge de base pour d’autres éléments : le calcul des noms accessibles SVG et les en-têtes de tableaux, pour n’en citer que quelques-uns. Tous les lecteurs d’écran présentent des lacunes, ce qui nous amène généralement à signaler des bogues et à demander aux responsables de la maintenance : « Quand cette fonctionnalité sera-t-elle prise en charge ? » Ce que nous devrions tous faire… tout en apportant notre soutien aux signalements existants concernant des problèmes d’accessibilité rencontrés dans la pratique.
Comment et où signaler les bugs liés à l'accessibilité ? http://whoseline.a11yideas.com/bugs.html
Nouvelles technologies et dégradation gracieuse
Dans axe-core, nous ajoutons la prise en charge d’éléments tels que les nouveaux rôles, états et propriétés ARIA 1.1, à condition qu’ils ne posent pas de problèmes dans les navigateurs ou outils d’assistance plus anciens. Mais comment savoir si un élément est « pris en charge en matière d’accessibilité » ? Nous testons les techniques concernées dans notre matrice de prise en charge commune et rendons compte des résultats afin de pouvoir décider de la marche à suivre. Nous posons de nombreuses questions, telles que : cela fonctionne-t-il comme prévu ? La fonctionnalité se dégrade-t-elle de manière gracieuse, c’est-à-dire peut-elle être ignorée en toute sécurité si elle n’est pas prise en charge ? Si axe-core détecte une barrière de sécurité déterminée par programmation, comme un attribut `aria-describedby`, peut-on faire abstraction de l’absence de prise en charge de l’accessibilité ?
Malheureusement, il arrive parfois que l’absence de prise en charge dans une technologie d’assistance majeure nous empêche d’adopter une technique standard, comme l’utilisation de plusieurs rôles sur un même élément (ce que l’on appelle les « rôles de secours » dans ARIA 1.1, qui ont pour conséquence qu’aucun rôle n’est annoncé dans JAWS). Tant que la prise en charge ne s’améliore pas dans une combinaison navigateur/technologie d’assistance sur laquelle comptent de nombreux utilisateurs en situation de handicap, nous ne nous sentons pas à l’aise de recommander aux développeurs d’utiliser cette technique.
Le meilleur moyen de suivre l'évolution de la prise en charge de l'accessibilité dans axe-core est de consulter nos tickets ouverts ou notre document sur la prise en charge d'ARIA sur GitHub, ou encore de nous poser la question sur Gitter. Il y a de fortes chances que quelqu'un ait déjà posé la même question que vous, et il se peut qu'il existe un fil de discussion complet sur ce sujet précis, détaillant les recherches antérieures et les discussions relatives à la prise en charge. Après un délai indéterminé, il peut être judicieux de réexaminer une fonctionnalité qui n'était pas encore prête à être intégrée à axe, mais qui mérite d'être remise sur le tapis.
Aller de l'avant
Au sein de l'équipe Axe, nous faisons de notre mieux pour proposer des règles et des techniques adaptées à tous, mais les divergences d'opinion sont normales (et inévitables) en matière d'accessibilité. D'ailleurs, c'est vrai pour une grande partie du secteur du développement web : demandez à n'importe qui quel est son outil de build préféré ou ses paramètres de linter. Ce qui compte, c'est la façon dont nos sites web et nos applications fonctionnent pour nos utilisateurs finaux. Une personne en situation de handicap pourra-t-elle postuler à un emploi via la plateforme que vous développez ou exceller dans son travail actuel ?
Notre secteur dispose d’un immense pouvoir pour faire bouger les choses en faveur des personnes en situation de handicap. Quelle que soit la manière dont nous nous y prenons, c’est notre élan inébranlable qui fera la différence à long terme. Nous espérons que vous trouverez utile l’écosystème « axe » d’outils de test d’accessibilité. Si vous constatez une divergence au niveau des politiques ou si vous avez besoin d’une assistance supplémentaire, n’hésitez pas à nous en faire part via l’un de nos canaux d’assistance disponibles.
