Le terme «accessibilité» réfère au fait de rendre une application facile d’utilisation pour le plus grand nombre d’utilisateurs possible. Ce faisant, elle évoque souvent chez les gens la notion de handicap: l’accessibilité serait là pour aider les personnes ayant des limitations visuelles, auditives, avec leur mobilité, etc. Pour plusieurs, il s’agit dès lors de mesures assez nichées dont bénéficient généralement un petit nombre de personnes.
Mais ne vous méprenez pas! Ces pratiques ne bénéficient pas uniquement aux gens avec un handicap permanent. N’avez-vous jamais activé les sous-titres d’une vidéo parce que votre environnement était bruyant ou parce que vous appreniez la langue qui y était parlée? Effectivement, l’accessibilité est également là pour répondre aux besoins des personnes se retrouvant dans une situation handicapante ou étant temporairement gênées par une maladie ou une blessure, comme l’illustre l’image ci-dessous. Quand on tient compte de cela, on réalise rapidement que tout le monde peut bénéficier des mesures d’accessibilité.
La définition simple d’une application dite «accessible» est qu’elle est aisément utilisable par tous, y compris les gens ayant un trouble de la mobilité, de la vision, de l’audition, de la parole ou cognitif (ou bien ceux se trouvant dans une situation amenant des limitations similaires). Sachant cela, il existe plusieurs angles à attaquer pour rendre une ressource réellement accessible, par exemple :
Soyons réalistes, il ne s’agit dès lors pas d’un processus toujours simple. Il est toutefois possible, avec un minimum d’effort, de rendre une application considérablement plus accessible.
* pas du tout une statistique inventée de toute pièce, provenant du site www.croyezmoi.com
Avant de tomber dans le vif du sujet, faisons un petit interlude en parlant d’un sujet prévalent lorsqu’il est question d’accessibilité : la notion de «Accessible Rich Internet Applications», ARIA pour les intimes. Cet ensemble d’attributs peut être ajouté à des éléments HTML afin d’augmenter leur niveau d’accessibilité en modifiant l’arbre d’accessibilité (dont il sera question plus bas). Nombreux attribuent ainsi de facto la notion d’accessibilité à la présence d’ARIA dans le code.
Les attributs ARIA peuvent attribuer des rôles, c’est-à-dire définir un élément et ce qu’il fait. Dans cet exemple, on attribue le rôle button à un élément.
Ils peuvent également ajouter des propriétés, soit des caractéristiques, soit créer des relations entre objets. Ici, on indique que le second élément est un label qui définit ce que fait le premier élément.
Enfin, ils permettent aussi de régler des statuts, donc de préciser l’état courant d’un élément. Dans ce dernier cas, on confirme que le bouton n’est pas activé (toggled).
Pour la plupart des utilisateurs, ARIA est invisible, puisqu’il n’affecte en rien l’aspect visuel d’une application ni ses fonctionnalités. Seuls les membres de la communauté utilisant des technologies d’assistance remarquent la différence entre un produit avec ou sans ARIA.
Aux yeux d’un utilisateur «commun», la présence d’ARIA ne change rien
En effet, l’incorporation adéquate des attributs ARIA dans le code assure que les utilisateurs de technologies d’assistance recevront toutes les informations dont ils et elles ont besoin. Et je souhaite insister sur ce dernier terme: dont ils ont besoin. Certes, il est possible de combiner en une seule ligne tous les types d’attributs ARIA (rôles, propriétés et statuts), mais il n’est pas nécessaire, voire souhaitable, de le faire. Trop d’ARIA n’est pas mieux que pas du tout d’ARIA.
En 2014, le W3C — le World Wide Web Consortium — a publié la recommandation du HTML5, qui a amené de gros changements, incluant la création de «points de repère» (landmarks), tels que <main>, <header>, <footer>, <aside> ou <nav>, et des attributs comme hidden ou required. Ces éléments, couplés à de majeures améliorations au niveau du support apporté par les navigateurs modernes, ont fait en sorte que l’apport d’ARIA est maintenant moins essentiel qu’à une certaine époque.
En ayant cela en tête, il faut donc comprendre que la règle d’or, lorsqu’il est question d’utiliser ARIA, est de ne pas utiliser ARIA. En effet, l’ajout d’ARIA ne rend pas de facto une ressource accessible à cause du risque de mauvaise implémentation. Et bien qu’il existe bien sûr quelques exceptions à cette règle, elles sont rares.
Plutôt, faites bon usage du HTML sémantique.
Dans l’exemple ci-dessus, l’élément HTML sémantique <button> vient avec de nombreuses fonctionnalités que l’attribut ARIA role ne fournit pas sans que vous ayez à lever le petit doigt pour les implémenter :
Selon W3Schools, un élément HTML sémantique est un élément qui décrit sa définition aux développeurs et développeuses aussi bien qu’aux navigateurs. Analysons cette définition plus en profondeur.
Que veut dire cette partie de la définition offerte plus haut? Prenons l’exemple suivant. Essayez de visualiser l’apparence de cette page.
Y a-t-il un en-tête? Un menu latéral? Un pied de page? Comment savoir assurément? Maintenant, regardez le code suivant et tentez de nouveau de visualiser cette page.
Plus simple, n’est-ce pas? C’est ce qu’on veut dire par «le HTML sémantique décrit sa définition aux développeurs et développeuses». Il rend le code bien plus compréhensible, car chaque élément est mieux déterminé. En contrepartie, certains éléments HTML sont dits «non sémantiques», c’est-à-dire qu’ils jouent en quelque sorte le rôle de «simples contenants» ou se contentent de décrire l’effet visuel plutôt que la signification. C’est le cas des balises <div>, <span>, <b>, <i>, et <center>. Il est à noter qu’il n’est pas interdit d’utiliser ces éléments, il est simplement conseillé de les utiliser avec parcimonie et de s’assurer qu’il n’existe pas déjà un élément sémantique faisant mieux le travail.
Il existe au-delà de 100 éléments HTML sémantiques : <form>, <table>, <article>, <aside>, <header>, etc.
Qu’en est-il maintenant de la seconde partie de la définition offerte? Un élément HTML sémantique est un élément qui décrit sa définition aux développeurs et développeuses…
Il faut savoir que les balises HTML sémantiques aident les outils automatisés à déchiffrer la structure d’une page. Les navigateurs, lorsqu’ils parcourent le code qu’ils reçoivent, construisent le Document Object Model (DOM), de même que le CSS Object Model (CSSOM), c’est bien connu, mais ils construisent aussi un arbre d’accessibilité, dont font usage les technologies d’assistance.
Saviez-vous que vous pouvez facilement visualiser ce dernier via les DevTools de votre navigateur? Voici la démarche pour y parvenir sur Chrome.
Visitez votre site Web favori, par exemple ricardocuisine.com (miam).
Ouvrez les DevTools, soit en faisant un clic droit, puis en cliquant sur «Inspecter», soit en appuyant sur la touche F12 de votre clavier (ou fn + F12 si vous utilisez un ordinateur Mac).
Trouvez l’onglet «Accessibilité». Il est possible que vous ayez à cliquer sur les chevrons pour voir plus d’options et ainsi trouver l’onglet d’accessibilité (comme l’indique le cercle bleu dans l’image).
Si ça n’a jamais été fait auparavant, cochez la case «Enable full-page accessibility tree», puis fermez et réouvrez le DevTools.
Visitez l’onglet «Elements», puis cliquez sur le bouton d’accessibilité en haut à droite pour voir l’arbre d’accessibilité (voir la très subtile flèche rouge dans l’image ci-dessous).
Comme précédemment mentionné, le HTML sémantique permet la création de points de repère, qui deviennent visibles dans l’arbre d’accessibilité. Les technologies d’assistance peuvent ensuite les utiliser pour aisément sauter d’une section à l’autre lorsque l’utilisateur navigue sur la page. Voici un exemple de découpage des sections d’un site rendu visible grâce à l’outil Accessibility Insights.
Voici également deux exemples d’arbres d’accessibilité pour une page au rendu similaire. Dans celui de gauche, il y a eu un faible usage du HTML sémantique, tandis qu’il a été bien implémenté pour l’exemple de droite. On y remarque la présence marquée de points de repère.
Ce qu’il faut retenir est que l’un des éléments primordiaux de l’accessibilité numérique est la structure sous-jacente de vos pages. Lorsque vous construisez votre site ou votre application, ne vous fiez pas qu’au style CSS pour construire les éléments de votre page, utilisez également des éléments HTML sémantiques, puisque le CSS ne créera pas de points de repère dans l’arbre d’accessibilité. C’est simple et ça fait une grosse différence.
Si vous travaillez avec React, vous devriez aussi faire un usage assez fréquent de leur balise <Fragment>. Pour mieux comprendre, prenons un exemple concret qui vous est possiblement familier: la création d’une liste peuplée par des composants React. Veuillez noter que cet exemple est fortement inspiré (voire copié) de la documentation officielle de React.
Lorsque vous faites le composant enfant, <Item>, React vous indique par le biais d’une erreur qu’il ne peut y avoir qu’un seul composant parent.
La solution est assez simple, vous mettez un <div> à la racine, ce qui fait disparaître le problème.
Mais en agissant ainsi, vous «brisez» en quelque sorte la liste en y introduisant des balises HTML inutiles. Une meilleure solution, dans un cas similaire, est plutôt d’utiliser le composant <Fragment> (aussi abrégé <>...</>), qui permet d’envelopper un composant sans introduire de nouveaux nœuds dans le DOM.
À gauche, vous pouvez voir le résultat d’une liste dans le DOM lorsqu’on utilise la balise <div>, tandis qu’à droite, il s’agit du résultat lorsqu’on utilise le <Fragment>. Dans le premier cas, on brise le HTML sémantique, tandis qu’il est intact dans le second.
Un autre outil de la suite React qu’il vaut la peine d’avoir dans votre arsenal et d’utiliser convenablement pour faciliter la création d’applications accessibles est la librairie de tests React Testing Library.
Pour citer la documentation officielle, le principe directeur de la librairie est que plus vos tests ressemblent à la façon dont votre logiciel est utilisé, plus ils vous apportent de la confiance. Pour cette raison, React Testing Library fournit des fonctionnalités qui simulent les interactions des utilisateurs avec le DOM, similaires à leurs réelles interactions: trouver les éléments d’un formulaire via les labels, trouver des boutons et des liens à partir de leur texte, etc. En étant faite ainsi, la librairie vous encourage indirectement à faire en sorte que votre application soit accessible.
Voici un cas typique de test rédigé avec React Testing Library provenant de leur documentation. Vous avez une fonction de mise en place (render), des sélecteurs pour interagir avec le DOM (getByRole, findByText) et des fonctions pour l’assertion (expect, toBeVisible).
La clé d’une utilisation optimale de React Testing Library permettant de profiter de ses bienfaits sur l’accessibilité réside dans l’usage rusé des sélecteurs mis à votre disposition. Ils sont en effet divisés en trois catégories :
les sélecteurs vous indiquant que les éléments HTML ainsi sélectionnés sont accessibles par tous les utilisateurs, navigateurs et technologies, et qui reflètent ainsi le plus fidèlement l’expérience des utilisateurs, incluant ceux qui utilisent des technologies d’assistance (byRole, byLabelText, byText, byPlaceholderText, byDisplayValue);
les sélecteurs de requêtes sémantiques, qui sont compatibles avec HTML5 et ARIA, mais dont l’usage reflète moins le réel usage de tous les utilisateurs, puisque l’expérience peut varier selon les navigateurs et les technologies d’assistance utilisés (byAltText, byTitle);
les sélecteurs des ids de test, qui ne reflètent en rien l’expérience des réels utilisateurs, qui ne peuvent les voir ou les entendre (byTestId).
Cela signifie qu’il vaut mieux privilégier l’usage des sélecteurs de la première catégorie, sinon ceux de la seconde catégorie lorsque ce n’est pas possible. Dans de rares cas, vous pouvez utiliser les ids de tests, que la documentation qualifie de «portes de sortie» pour les cas où obtenir les éléments du DOM selon leur label ou leur contenu n’a pas de sens ou n’est pas pratique. Effectivement, en vous fiant trop aux ids de test, vous perdez la garantie que votre application est accessible. Et le fait d’avoir impérativement besoin de ces derniers dans un trop grand nombre de tests est possiblement un signe que votre application ne l’est pas.
L’un des défis auxquels on peut faire face lors de la rédaction des tests frontend est d’avoir plusieurs éléments similaires au sein de l’élément testé. Dans l’exemple suivant, le sélecteur getByRole détecte les multiples occurrences du bouton et le test échoue.
Plusieurs développeurs et développeuses ont alors le réflexe d’avoir recours au data-testid pour distinguer les deux boutons, comme dans les captures d’écran ci-dessous. Et bien que le test soit certes maintenant réparé, en faisant ainsi, on perd l’assistance que nous apporte React Testing Library quant à l’accessibilité, comme mentionné précédemment, considérant que les ids de test ne reflètent en rien l’expérience utilisateur.
Une autre solution, détaillée ci-dessous, est l’emploi des méthodes getAll, findAll ou queryAll de React Testing Library, qui ne lance pas d’erreur lorsque plusieurs éléments similaires sont détectés. Plutôt, ces éléments sont mis dans un tableau et on peut les sélectionner individuellement par la suite. Néanmoins, bien que meilleure, cette façon de faire a le défaut que nos tests s’en trouvent fragilisés: si, soudainement, j’ajoute un troisième bouton similaire dans la page ou si j’en retire un, comment puis-je garantir que le test détecte toujours le bon bouton?
Pour régler cette impasse, React Testing Library offre la fonction utilitaire within, qui permet de restreindre la recherche du sélecteur au contenu d’une section spécifique de la page.
Vous aimeriez contribuer davantage à l’accessibilité du Web, mais ne savez pas par où commencer? Vous pouvez regarder cette formation gratuite créée par l’équipe de Chrome et des spécialistes externes pour en apprendre davantage et découvrir d’autres pistes d’apprentissage.