Communiquez les informations d'accessibilité aux équipes
Nous venons d'atteindre le dernier chapitre et, avec lui, la limite ultime de l'accessibilité : l'annotation en faveur de l'accessibilité. Certes, ce n'est peut-être pas la limite ultime. Ce que je veux dire, c'est que cette discipline spécifique visant à mettre en œuvre l'accessibilité dans le monde réel est plutôt récente, et qu'il reste encore beaucoup à faire dans ce domaine. En réalité, bien souvent, les concepteurs ne réfléchissent pas vraiment à l'accessibilité, les développeurs mettent en œuvre des modèles reposant sur des conceptions visuelles sans disposer de suffisamment d'informations sur le comportement attendu, et les propriétaires des produits ne savent pas toujours à quoi prêter attention pour déterminer si leurs produits finaux sont accessibles.
Dans une situation idéale, pour envisager l'accessibilité depuis le début du processus de conception, nous devons être en mesure de communiquer à ce sujet avec toutes les équipes. Vous savez désormais qu'il y a beaucoup à faire pour rendre le contenu accessible. Certaines considérations concernent le contenu, d'autres le visuel, d'autres encore la technique. De fait, la réflexion autour de l'accessibilité doit avoir lieu dans plusieurs services et dans différentes fonctions. La communication est donc essentielle !
Nous réfléchissons encore aux meilleurs moyens d'y parvenir. Par conséquent, considérez ce chapitre comme un point de départ et n'ayez pas peur de faire vos propres explorations. Les meilleures solutions varient en fonction du projet, de l'organisation et du niveau de collaboration entre les services. Dans la mesure du possible, essayez d'intégrer dans ce travail des processus et pratiques déjà en place.
Cartographiez les zones les plus importantes de la page
Afin de faciliter la navigation dans la page pour les utilisateurs de technologies d'assistance, vous devez définir les principales zones de votre page à l'aide d'éléments HTML structurels, de rôles de repérage ARIA, ou des deux. Ainsi, les utilisateurs peuvent comprendre rapidement l'organisation de la page et les zones disponibles. Ils peuvent également se déplacer dans le contenu de manière rapide et efficace.
Il existe plusieurs types de repères. Certains sont disponibles en HTML, d'autres en ARIA, et certains dans les deux. En voici un résumé :
Fonctionnalité | HTML | ARIA |
Navigation | <nav> | role=”navigation”
Remarque : ce rôle de repérage exige un nom accessible utilisant aria-label ou aria-labelledby. Ce point est particulièrement important lorsqu'une page comporte plusieurs zones de navigation. |
Contenu principal | <main> | role=”main” |
En-tête | <header> | role=”banner” |
Contenu supplémentaire | <aside> | role=”complimentary” |
Pied de page | <footer> | role=”contentinfo” |
Formulaire | <form> | role=”form” |
Section | <section> | role=”region”
Remarque : ce rôle de repérage exige un nom accessible utilisant aria-label ou aria-labelledby. |
Recherche | S/O | role=”search” |
À vous de jouer
À votre tour d'essayer ! Examinez la maquette suivante d'une page d'accueil. Quelles sont les principales zones de cette page ? Utilisez le tableau ci-dessus si vous avez besoin d'aide.
La maquette est composée d'une zone d'en-tête avec navigation et fonction de recherche, d'une zone principale et d'un pied de page avec des liens de navigation supplémentaires. Nous pouvons la cartographier comme suit :
Veuillez noter qu'il existe deux zones de navigation. Chacune dispose d'un libellé (étiquette) unique.
Identifiez l'ordre de lecture et l'ordre du focus
Vous pouvez inclure des annotations concernant l'ordre dans lequel un lecteur d'écran doit parcourir le contenu de la page. Cela vaut aussi bien pour le contenu statique (ordre de lecture) que pour le contenu interactif (ordre du focus). Les deux sont liés et doivent généralement concorder. Vous pouvez utiliser des icônes différentes pour les éléments statiques, les éléments interactifs, ainsi que les éléments interactifs qui modifient l'ordre du focus lorsqu'ils sont activés, tels que la navigation dans une liste déroulante.
Par exemple, dans la maquette suivante, la plupart des éléments d'en-tête sont interactifs, le menu de profil redirige le focus vers le contenu contextuel qui s'est ouvert, et le contenu des sections principales telles que le titre, le texte et l'image est statique.
Si un élément modifie le focus, l'interaction doit avoir son propre cadre. Dans cet exemple, les paramètres de profil ouvrent un nouveau contenu. Par conséquent, un cadre de maquette supplémentaire explique l'ordre d'interaction une fois le contenu développé.
Vous pouvez à présent numéroter l'ordre de lecture et l'ordre du focus pour organiser les informations concernant tous les éléments dans un tableau d'annotations. Dans les dernières sections, nous allons ajouter quelques couches d'informations d'accessibilité à ce tableau.
Prenez note des rôles, des états et des propriétés
Cette couche d'informations d'accessibilité exige le plus de recherche, en particulier si vous êtes en train d'apprendre les ficelles d'ARIA. Je pense qu'il est utile de diviser ce processus en deux étapes.
Identifiez le rôle de chaque élément.
Spécifiez les états et propriétés essentiels pour comprendre la commande.
Tout d'abord, définissez le rôle, par exemple bouton, lien, onglet, etc. Dans la mesure du possible, ces rôles doivent être communiqués via des commandes HTML natives. Si vous utilisez une case à cocher, le rôle checkbox sera inhérent dans l'élément HTML. Comme je l'ai évoqué dans le chapitre consacré aux interactions accessibles, certains composants tels que les onglets ne peuvent pas être communiqués uniquement au moyen de HTML. Dans ce cas, vous devez définir vos rôles via ARIA.
Une fois que vous savez quels sont les rôles, réfléchissez aux informations supplémentaires devant être communiquées afin que l'utilisateur puisse comprendre l'interaction sans se fier aux informations visuelles.
Si vous ne savez pas par où commencer, lisez les documents ARIA 1.1 specification (en anglais) et ARIA authoring practices (en anglais). Pour chaque rôle, étudiez la liste des états et propriétés pris en charge et hérités dans les spécifications, afin de déterminer lesquels pourraient s'appliquer à votre commande. Explorez les pratiques de création de contenu pour voir si vous pouvez trouver des exemples similaires au modèle sur lequel vous travaillez. Au fil du temps, vous maîtriserez les états et propriétés généralement requis pour chaque rôle.
Examinons un exemple de plus près. Le menu Profil dans notre exemple de site est un bouton qui ouvre un menu comportant des liens vers d'autres pages. La première chose que nous pouvons indiquer est que cet élément est un bouton. De nombreux attributs sont répertoriés dans la liste des états et propriétés pris en charge et hérités pour cet élément. Si vous êtes familiarisé avec ces attributs, vous serez sans doute en mesure de parcourir rapidement la liste pour repérer les éléments pertinents. Si vous maîtrisez moins ARIA, essayez de trouver des exemples d'interactions qui fonctionnent de manière similaire. En parcourant le document consacré aux bonnes pratiques de création de contenu, vous trouverez un exemple de bouton de menu de navigation (en anglais). À partir de là, vous verrez que cette interaction exige :
un attribut aria-haspop qui peut être défini sur ‘true’ ou ‘menu’ ;
un attribut aria-controls qui établit une relation par programmation entre le déclencheur et le contenu qu'il développe ;
un attribut aria-expanded qui indique si le contenu est actuellement réduit ou développé.
Examinez quelques exemples, en particulier si vous travaillez avec un nouveau modèle. Testez-les avec un clavier et un lecteur d'écran et collectez les suggestions et commentaires formulés sur les blogs, les communautés a11y et les sites tels que WebAIM pour orienter vos décisions concernant les rôles, états et propriétés à inclure.
Incluez des descriptions et des noms accessibles
Comme pour les descriptions textuelles alternatives des images, incluez des noms et des descriptions accessibles pour toutes les commandes interactives, telles que les boutons et les liens. Dans certains cas, le nom accessible correspondra à ce qui est effectivement affiché, par exemple si vous utilisez un bouton « Envoyer ». Dans d'autres cas, les boutons et les liens peuvent être associés à des indicateurs basés sur les images et n'ont pas de descriptions textuelles visibles. Par exemple, une icône + indiquant une section développable ou une icône de profil renvoyant vers le menu des préférences d'un utilisateur. Dans ce cas, les noms accessibles doivent fournir une description équivalente à une indication visuelle.
Exercice : testez l'annotation en faveur de l'accessibilité !
Reprenez la maquette que vous avez créée au chapitre précédent et ajoutez-lui des informations d'accessibilité.
Divisez votre maquette en sections. Quels repères pourraient être utiles pour identifier les zones de votre page ?
Numérotez tous les éléments pour préciser l'ordre de lecture et l'ordre du focus. Pensez à distinguer le contenu statique, le contenu interactif et les éléments qui redirigent le focus.
Créez un tableau contenant les numéros que vous avez utilisés à l'étape précédente afin de vous y référer. Indiquez le rôle de chaque élément.
Parcourez les rôles et interactions plus complexes et indiquez tous les états et propriétés pertinents. Cette étape peut nécessiter que vous fassiez des recherches supplémentaires pour trouver des exemples, et que vous examiniez la documentation plus en détail.
En résumé
Réfléchissez à et communiquez les informations relatives à l'accessibilité dès le début du processus de conception.
Indiquez l'ordre du focus et l'ordre de lecture des éléments.
Précisez le rôle de chaque élément
Mentionnez tous les états et propriétés nécessaires pour clarifier l'interaction.
Ajoutez des noms accessibles aux images et aux éléments visuels interactifs, tels que les boutons et les liens.
Et le tour est joué ! Nous avons fait un long parcours. Récapitulons à présent tout ce que nous avons appris, dans le résumé du cours.
