Accessibilité – 4 : les composants simples
Tribune Glob'codeurQuatrième article de la série sur le thème de l'accessibilité.
Sommaire
Retrouvez l'ensemble de notre contenu sur l'accessibilité dans un livret PDF dédié. Il est à la destination de tous les professionnels du Web afin de rendre le web plus inclusif.
Les médias
Concernant les médias, on les mettra en général dans une balise <figure>, au côté d'une balise <figcaption>. Cette dernière ne fait pas office de nom accessible pour le média, mais plutôt de titre, un peu comme les appendices à la fin des livres où l'on retrouve la liste de toutes les images, de tous les tableaux...
Dans tous les cas, il est déconseillé de mettre les médias en autoplay, ou lecture automatique. Et pour tout ce qui est animé, ou qui dure plus de trois secondes, on doit pouvoir mettre le média en pause.
Images
On distingue plusieurs types d'images :
- les images porteuses d'information : qui nécessitent une alternative textuelle non vide. Celle-ci doit être courte, concise, et réellement en relation avec le contenu de l’image. Ce n'est généralement pas une description littérale de l'image, et on ne met pas le mot "image".
- les images décoratives : qui n'apportent aucune information particulière et qui pourraient très bien ne pas être affichées. Ici l'alternative textuelle sera présente, mais obligatoirement vide (
alt="") - les images complexes : qui nécessitent plus qu'une phrase pour être décrites, comme par exemple les graphes, ou les illustrations. On peut joindre la description complète dans une balise
<details><summary>à l'intérieur même de la balise<figure>: elle doit décrire en totalité l’information véhiculée par l’image.
Ces bonnes pratiques s'appliquent non seulement à la balise <img>, mais également aux balises <svg>, <canvas>,... sauf qu'en lieu et place de l'attribut alt="", on utilisera plutôt :
- un attribut
aria-label=""non vide pour les images porteuses d'information - un attribut
aria-hidden="true"pour les images décoratives
See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.
Pour tester, on peut afficher directement les alternatives au-dessus des images grâce à l'extension Web Developer, car les outils de tests automatisés ne sont pas capables de :
- différencier les images décoratives, informatives, …
- juger de la pertinence des alternatives textuelles et des descriptions détaillées
Pour vous aider à dans cette démarche, il existe un arbre de décision pour les alternatives sur le site de la WAI (nouvelle fenêtre) (en anglais)
Cadres
Selon le référentiel général d'amélioration de l'accessibilité, le contenu des <iframe> n'est pas soumis à une obligation d’accessibilité. En effet, la plupart du temps c'est le contenu d'un autre site qui est affiché, et sur lequel nous n'avons pas la main. On doit cependant veiller à ajouter un attribut title="" qui décrit pertinemment la nature du contenu diffusé.
Qu'en est-il des <iframe> contenant une vidéo Youtube ou Vimeo ? Il semblerait que la situation s'améliore :
- concernant Youtube, même le site du gouvernement britannique explique dans un article pourquoi ils utilisent Youtube (nouvelle fenêtre)↗(en anglais) (il faut préciser ici que le site du gouvernement britannique est un des sites les plus accessibles au monde)
- concernant Vimeo, c'est le site Vimeo lui-même qui indique que des améliorations ont été apportées (nouvelle fenêtre) (en anglais)
Vidéos
Nous venons d'évoquer le fait qu'il existe des lecteurs déjà accessibles, on ne va donc pas réinventer la roue, et recréer un lecteur avec la balise <video>. Par contre, on peut apporter plusieurs éléments complémentaires :
- un fichier WebVTT pour les sous-titres, qui doivent être synchronisés, équivalents en contenu, et contrastés. On peut même les générer automatiquement et ensuite corriger les erreurs d'interprétation, et ajouter les effets sonores et sons non-verbaux (rires,...)
- une audio description qui restitue l'ambiance, à la manière d'un livre audio, et qui permet au public de s'immerger dans l'univers (lire l'article sur l'audio description dans la série Mandalorian (nouvelle fenêtre), en anglais)
- une transcription textuelle adjacente, indiquant également les effets sonores, les sons non-verbaux , le ton, les émotions, les déplacements... (exemple ci-après)
See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.
Audios
Pour les lecteurs audios accessibles , on peut en citer deux (qui font d'ailleurs également lecteur vidéo) :
Et comme l'exemple de code ci-dessus, on doit ajouter une transcription de l'audio avec toutes les informations nécessaires à la compréhension du contenu. Cette règle est aussi valable pour les lecteurs de podcasts qui sont, quant à eux, bien souvent à la traîne niveau accessibilité, notamment au clavier...
Les formulaires
Labels
Chaque champ de formulaire doit avoir une étiquette soit en utilisant :
- Dans la mesure du possible, l'élément label pour associer explicitement du texte à des champs de formulaire (cf. exemple 1).
- L'attribut for du label doit correspondre exactement à l'id du champ de formulaire.
- L'élément label doit permettre de connaitre la fonction exacte du champ de formulaire
- L'élément label doit être accolé à son champ de formulaire
- Dans certains cas, on est obligé de cacher le label pour éviter la redondance. Par exemple, si le champ de recherche est placé directement à côté du bouton de recherche. le contexte est explicitement décrit par le bouton de recherche (cf. exemple 2).
- L'attribut WAI-ARIA aria-label. Cette approche est bien prise en charge par les lecteurs d'écran et autres technologies d'assistance (cf.exemple 3).
- L'attribut WAI-ARIA aria-labelledby peut également être utilisé pour identifier les champs de formulaires. Cette approche est bien prise en charge par les lecteurs d'écran et autres technologies d'assistance (cf. exemple 4).
- L'attribut title peut également être utilisé pour identifier les champs de formulaires. Cette approche n'est pas recommandée car certains lecteurs d'écran et technologies d'assistance n'interprètent pas l'attribut title comme un remplacement de l'élément label (cf. exemple 5).
See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.
Groupes
Le regroupement de champs de formulaires connexes rend les formulaires plus compréhensibles pour tous les utilisateurs.
Cependant, il existe plusieurs approches qui permet le regroupement des champs de même nature (champs connexes) :
- Regrouper les champs connexes avec un fieldset.
- L'élément fieldset fournit un conteneur pour les champs de formulaire regroupés, et l'élément legend fait office d'en-tête pour identifier le groupe.
- À noter qu'au cas où le legend ne serait pas lu par les lecteurs d'écran, l'étiquette du premier champ de formulaire de chaque groupe doivent inclure le nom du groupe. Ce nom peut être masqué visuellement.
- Regrouper les champs connexes dans un conteneur et en utilisant les propriétés WAI-ARIA.
- WAI-ARIA fournit un rôle de groupe qui fonctionne de la même manière que fieldset et legend. l'élément div a un role=group pour indiquer que les éléments contenus sont membres d'un groupe et l'attribut aria-labelledby fait référence à l'id du texte qui servira d'étiquette au groupe.
- Étant donné que WAI-ARIA n'est pas entièrement pris en charge par tous les navigateurs Web et lecteurs d'écran, l'étiquette du premier champ de formulaire de chaque groupe doivent inclure le nom du groupe. Ce nom peut être masqué visuellement.
- Regrouper les options d'un select de même nature :
- Pour les select comportant des groupes d'options, l'élément optgroup peut être utilisé pour indiquer ces groupes. L'attribut label de l'élément optgroup est utilisé pour fournir une étiquette pour le groupe.
See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.
Instructions
Il est important de fournir des instructions pour aider les utilisateurs à comprendre comment remplir le formulaire et utiliser les contrôles des champs de formulaire. Par exemple, indiquer toute saisie obligatoire et facultative, les formats de données et toute autre information pertinente.
Cependant, il faut fournir ces instructions avant l'élément form afin de s'assurer qu'elles sont lues à haute voix par les lecteurs d'écran avant qu'ils ne passent en "mode formulaires".
En plus des instructions générales, il est également important de fournir des instructions pertinentes dans les étiquettes des champs de formulaires. Par exemple, indiquer les champs de saisie obligatoires et les formats de données dans le texte des étiquettes.
- Fournir des instructions sur les labels. Cette approche est fiable pour les différents navigateurs Web et technologies d'assistance (cf. exemple 1).
- Fournir des instructions en dehors des étiquettes. Cette methode n'est pas non plus prise en charge par certains navigateurs Web (généralement les anciennes versions) et les technologies d'assistance qui ne mettent pas en œuvre la norme WAI-ARIA.
- L'une des approches consiste à utiliser l'attribut WAI-ARIA aria-labelledby pour associer des instructions aux champs de formulaires. (cf. exemple 2)
- Une autre approche pour associer des instructions supplémentaires à un champ de formulaire consiste à utiliser aria-describedby. Les informations référencées par cet attribut sont mises à la disposition des utilisateurs après l'annonce de l'étiquette (label) et des autres informations (cf. exemple 3).
- Une dernière approche consiste à utiliser les placeholders pour associer des instructions aux champs de formulaire. Cependant, Le texte de remplacement est généralement affiché avec un contraste de couleurs plus faible que le texte fourni par les utilisateurs, en plus, il disparaît lorsque les utilisateurs commencent à saisir du texte. Si le texte de remplacement contient des informations pédagogiques ou des exemples qui disparaissent, il est plus difficile pour les utilisateurs de vérifier leurs réponses avant de soumettre le formulaire (cf. exemple 4).
Il existe plusieurs approche qui permet de fournir des instructions pour chaque champ de formulaire
See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.
Validations
La validation personnalisée doit notifier les utilisateurs d'une manière accessible. La validation côté client n'est pas suffisante à garantir la sécurité, les données doivent donc également être validées côté serveur.
- Validation des champs requis (cf. exemple 1)
- Validation des champs input type (cf. exemple 2)
- Validation des champs input en utilisant des patterns (expressions régulières) (cf. exemple3)
En général, la validation côté client offre une meilleure expérience à l'utilisateur et rend la résolution des erreurs de validation plus compréhensible. Elle peut également réduire la charge du réseau et du serveur. Cependant, tous les navigateurs web ne prennent pas en charge le HTML5, ou il se peut qu'ils ne prennent pas en charge vos scripts de validation personnalisés. La validation côté client peut également être facilement contournée, ou les données sont modifiées avant d'atteindre le serveur. Cela signifie que la validation doit également être effectuée côté serveur.
See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.
Notifications
Il s'agit de fournir un retour d'information aux utilisateurs sur les résultats de leur soumission de formulaire, qu'elle soit réussie ou non. Lorsqu'un formulaire est soumis, il est important que l'utilisateur soit informé si la soumission est réussie ou si des erreurs sont survenues. il existe plusieurs techniques :
- "Overall feedback"
- Utilisation du titre principal (cf. exemple 1)
- Utilisation du titre de la page, l'élément title de la page web peut être utile pour indiquer les réussites et les erreurs. En particulier, les utilisateurs de lecteurs d'écran recevront ce retour d'information immédiatement lors du chargement de la page web (cf. exemple 2).
- Utilisation des boites de dialogues (cf. exemple 3)
- Listing d'erreurs (les champs de formulaire peuvent être associés au message d'erreur correspondant à l'aide de aria-describedby) (cf. exemple 4).
- "In-line feedback"
- Après soumission (cf. exemple 5)
- Pendant la saisie (cf. exemple 6)
- Lors du changement du focus (cf. exemple 7)
See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.
Les tableaux
Le but d'un tableau est de présenter des informations de façon claire, mais selon le découpage des données et l'imbrication des en-têtes du tableau, cela peut devenir impossible de se repérer sans indication visuelle. Il est donc conseillé de découper les tableaux complexes en plusieurs tableaux simples, si possible.
Pour les indications visuelles, on peut aider l'utilisateur à se repérer grâce à des bordures, et/ou des couleurs de fond alternées selon les rangées paires ou impaires. On peut éviter aussi les cellules trop grandes ou trop espacées.
Description
On utilise la balise <caption> au tout début de la balise <table> pour aider à la compréhension. Elle peut servir pour décrire le contenu général, ou les en-têtes plus spécifiquement. Si vous souhaitez que le nom accessible du tableau soit différent du contenu de la balise <caption>, vous devez fournir un attribut title="" non vide à l'élément <table>, ou bien mettre le tableau dans une balise <figure> avec un élément <figcaption>.
En-têtes régulières
Ce sont les attributs scope="row" et scope="col" qui aident les lecteurs d'écrans à se repérer dans un tableau :
See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.
En-têtes irrégulières
Les deux tableaux de l'exemple précédent sont en fait le résultat du découpage de ce tableau plus complexe :
See the Pen A11y - Liens d'évitement by Globalis MS (@globalis-ms) on CodePen.
Les attributs ajoutés ici en plus des précédents sont les attributs scope="rowgroup" et scope="colgroup".
Il y aurait une autre possibilité pour les tableaux complexes, c'est de jouer avec les attributs id="" et headers="", mais cette solution est difficilement maintenable...
Conclusion
Dans cet article, nous avons vu ensemble les composants simples, astuces et bonnes pratiques qui permettent de rendre ces composants accessible à un public plus vaste.
Dans le prochain article nous allons voir des composants plus complexes.
Retrouvez notre série sur l'accessibilité :