Audit d’accessibilité simplifié - Koerich

Thématique "images"

Cas rencontré : images de décoration

Les images de décoration ne doivent pas avoir d’alternative textuelle et doivent être ignorées correctement par les technologies d’assistance. Dans le cas contraire, elles peuvent causer des problèmes de compréhension aux utilisateurs de lecteurs d’écran (aveugles et grands malvoyants). Pour une image matricielle, son attribut alt doit être vide. Pour une image vectorielle SVG, celle-ci doit avoir l’attribut aria-hidden="true".

Exemples de problèmes détectés sur la page 1

L'image du blason en pied de page dispose d'une alternative "logo reflet", l'attribut alt doit rester vide dans ce cas de figure.

Thématique "cadres"

Cas rencontré : titres de cadres

Les titres de cadres sont utiles à la compréhension de la structure de la page et des contenus pour les personnes aveugles. Tout cadre (élément <iframe> ou <frame>) doit avoir un titre fourni via son attribut title. Ce titre doit être pertinent, il doit représenter le contenu du cadre.

Exemples de problèmes détectés sur la page 2

Chaque <iframe>/<frame> doit disposer d’un attribut title non vide et pertinent décrivant sa fonction ou son contenu. (Ex: <iframe src="..." title="yyy"></iframe>)

Thématique "tableaux"

Cas rencontré : déclaration des entêtes et liaison des cellules d’entêtes et de données

Les utilisateurs de lecteurs d’écran ou de loupe d’écran vocalisée ne peuvent percevoir un tableau dans son ensemble. Il est donc important de leur communiquer des informations de contexte sur chaque cellule, notamment à quelles entêtes chaque cellule est reliée. Ces informations peuvent être données via des structures HTML dédiées. Les entêtes de colonnes et de lignes doivent notamment être déclarées via la balise <th>.

Dans un tableau de données simple, où chaque entête est valable pour l’ensemble de la ligne ou de la colonne, la relation entre les cellules et les entêtes doit être définie en appliquant un attribut scope="col" à toutes les entêtes de colonnes et scope="row" à toutes les entêtes de lignes.

Dans un tableau de données complexe, chaque entête doit avoir un identifiant déclaré via l’attribut id et chaque cellule doit faire référence à ces entêtes via l’attribut headers (liste d’identifiants séparés par des espaces).

Exemples de problèmes détectés sur la page 3

Dans les tableaux présents sur cette page, les entêtes de lignes et de colonnes ne sont pas structurés via des balises <th>. Ceci concerne le tableau (horaires et arrêts) où les intitulés de colonnes sont codés en <td>.

Thématique "liens"

Cas rencontré : pertinence des intitulés

Chacun doit pouvoir comprendre aisément la fonction et la destination de chaque lien. Les problèmes rencontrés ici le sont pour les aveugles, les malvoyants, les handicapés moteurs qui naviguent à la voix et les handicapés cognitifs.

Exemples de problèmes détectés sur la page 1

L’alternative textuelle du lien image "Capture d'écran …" dans la section Actualités en continu n’est pas pertinente. L'attribut alt doit, dans ce cas, rester vide.

Cas rencontré : présence d’intitulés

Un lien doit toujours avoir un intitulé. Celui-ci permet aux utilisateurs de comprendre la destination du lien. La présence d’intitulés sur tous les liens est particulièrement importante pour les aveugles et malvoyants. Si un lien n’a pas d’intitulé, les lecteurs d’écran vont lire simplement « lien » sans annoncer sa destination.

• Pour un lien qui ne contient qu’une image, l’intitulé du lien est l’alternative de l’image. Pour une image matricielle, son attribut alt doit contenir l’intitulé du lien (ex : <a href="https://facebook.com"><img src="..." alt="facebook" /></a>). Pour une image vectorielle SVG, celle-ci doit avoir l’attribut role="img" et l’intitulé du lien pourra être fourni via les attributs aria-label ou aria-labelledby (ex : <a href="https://facebook.com"><svg role="img" aria-label="facebook">...</svg></a>).
• Lorsqu’un lien contient du texte et des images, l’intitulé du lien correspond à la concaténation des intitulés de ces différents éléments contenus dans le lien (ex : pour <a href="https://facebook.com"><img src="..." alt="logo Facebook" /> Facebook</a> l’intitulé du lien est « logo facebook facebook ». Dans cet exemple, cet intitulé n’est pas pertinent et l’alternative de l’image doit être vide.)

Exemples de problèmes détectés sur la page 1

Certains liens-images n’ont pas d’intitulé (ex: une grande majorité de liens dans la section Actualités en continus). Dans ce cas il est nécessaire de donner un intitulé au lien via l’attribut alt de l’image. Cet intitulé doit désigner la destination du lien et reprendre le texte affiché s'il existe.

Thématique "scripts"

Cas rencontré : éléments interactifs inaccessibles au clavier

Les composants riches développés en JavaScript doivent respecter des modèles de conception spécifiques pour pouvoir être considérés comme accessibles (modèles de conception décrits dans le document « WAI-ARIA Authoring practices guide »). Sans cela le composant ne sera pas correctement restitué aux utilisateurs de lecteurs d’écran qui ne sauront pas comment l’utiliser. Ces composants doivent notamment utiliser des interactions au clavier spécifiques, sans lesquelles ils seront inutilisables pour les utilisateurs de la navigation au clavier.

Exemples de problèmes détectés sur la page 1

Lors de l’ouverture du menu burger en mode tablette/téléphone mobile, le focus clavier est mal piégé. L'élément doit pouvoir être fermé ou ignoré par le clavier (par ex. touche ESC) sans bloquer la navigation. Il ne réagit plus aux touches ESC et Echap, ce qui viole le design pattern WAI-ARIA « Dialog (Modal) » https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

Thématique "éléments obligatoires"

Cas rencontré : indication de langue

Les lecteurs d’écran utilisent les indications de langue pour vocaliser correctement le contenu. La langue principale de la page est spécifiée via l’attribut lang sur l’élément <html>. Lorsqu’un mot d’origine étrangère est inséré dans du contenu écrit dans la langue principale de la page, il doit posséder si nécessaire une indication de langue. L’indication de langue se fait par l’intermédiaire de l’attribut lang. Il existe néanmoins des exceptions :

• Lorsqu’il s’agit d’un nom, l’indication de langue doit être faite uniquement quand le nom doit se prononcer dans sa langue d’origine ;
• Lorsqu’il s’agit d’un mot d’origine étrangère, présent dans le dictionnaire de la langue principale de la page, l’indication de langue n’est pas nécessaire ;
• Lorsqu’il s’agit d’un mot d’origine étrangère d’usage courant, mais absent du dictionnaire, l’indication de langue doit être faite uniquement si la prononciation dans la langue principale de la page est problématique.

Plus d’information sur le sujet dans notre article : L’attribut lang, pour rendre la page audible… et compréhensible

Exemples de problèmes détectés sur la page 1

Cette page contient des textes en d’autres langues non marqués par un changement de langue via l’attribut lang (par exemple « Konferenz iwwer Ierfrecht » dans la section Articles en continu).

Thématique "structuration de l'information"

Cas rencontré : titres

Les titres permettent aux utilisateurs de comprendre la structure du document. Ils permettent aussi aux utilisateurs aveugles, malvoyants et handicapés moteurs de naviguer de titre en titre dans la page. Il est donc important d’avoir une bonne hiérarchie de titres dans une page. Cette hiérarchie est similaire à un sommaire de document. La vérification de la hiérarchie de titres peut se faire via l’extension de navigateur HeadingsMap.

Exemples de problèmes détectés sur la page 2

Certains passages de texte sont visuellement des titres mais cette information n’est pas présente dans le code html de la page. Ex: Le texte "Contact" au-dessus du texte des communes utilise des classes de titre au lieu d'utiliser directement une balise de titre appopriée.

Thématique "présentation de l'information"

Cas rencontré : visibilité du focus

Les handicapés moteurs qui naviguent au clavier utilisent l’indicateur de focus fourni par le site sur les éléments interactifs pour savoir où ils se situent dans la page. L’indicateur de focus se déplace via les touches tab et shift-tab. L’indicateur de focus par défaut peut être désactivé via CSS, dans ce cas il est nécessaire de changer le style de l’élément interactif pour rendre l’indicateur de focus visible (sa couleur devra avoir un contraste minimum de 3:1 avec l’arrière-plan contigu).

Exemples de problèmes détectés sur la page 1

Dans de nombreux éléments de cette page, le focus n’est pas visible, notamment en parcourant les éléments à droite de l'accès rapide.

Cas rencontré : contenus cachés

Tout contenu dans la page peut être ignoré par les technologies d’assistance (notamment en utilisant l’attribut aria-hidden="true"). Si un contenu est visible mais ignoré par les technologies d’assistance, les utilisateurs de ces technologies d’assistance ne pourront pas prendre connaissance du contenu ni interagir avec les éventuels éléments interactifs qu’ils pourraient contenir. La visibilité d’un contenu doit donc être cohérente pour tous les utilisateurs du site, qu’ils utilisent ou non une technologie d’assistance.

Exemples de problèmes détectés sur la page 1

« Le conteneur <div class="mm-ocd mm-ocd--right"> » est inaccessible aux technologies d’assistance via l’attribut aria-hidden="true" cependant il contient des éléments interactifs focalisables au clavier. Ces éléments doivent se voir assigner un attribut tabindex=-1 ou être retirés du DOM.

Thématique "formulaires"

Cas rencontré : identification des champs, des contrôles et des regroupements de formulaires

L’identification de ces éléments fournit aux aveugles et grands malvoyants les informations nécessaires pour pouvoir remplir un formulaire. Les handicapés moteurs utilisant un système de reconnaissance vocale s’appuient aussi sur ces éléments pour se déplacer dans les différents champs et actionner les boutons. Pour associer une étiquette (<label>) à un champ de formulaire on peut utiliser l’attribut for de l’étiquette dont la valeur doit être identique à celle de l’attribut id du champ. Les champs de même nature doivent être regroupés, cela peut être réalisé via l’élément <fieldset> auquel on doit fournir une légende via l’élément <legend>.

Exemples de problèmes détectés sur la page 2

L'étiquette du champ téléphone n'est pas associée au champ de formulaire par l’attribut for. L’association label/champ n’est pas fonctionnelle.

Cas rencontré : contrôle et aide à la saisie

Que ce soit pour les handicapés cognitifs ou pour les aveugles et déficients visuels, il est nécessaire d’expliciter les formats de données attendus dans les consignes et les messages d’erreur, ainsi que le caractère obligatoire de la saisie de certains champs.

Exemples de problèmes détectés sur la page 2

Le type de données attendu n’est pas précisé, et cela ni dans l’étiquette, ni dans le message d’erreur. De plus, les champs obligatoires ne sont pas indiqués dès le départ. Il est nécessaire de donner un exemple et de signaler les champs requis en amont.

Thématique "navigation"

Cas rencontré : landmarks ARIA

Les utilisateurs aveugles utilisent pour naviguer rapidement dans une page des points de repères ou landmarks. Ceux-ci définissent les principales zones de la page comme l’entête, le menu de navigation, la zone de contenu principale, le pied de page, le moteur de recherche. Chacune de ces zones doit avoir un attribut role dont la valeur correspond au type de zone :

• role=banner pour l’entête,
• role=navigation pour le menu de navigation,
• role=main pour la zone de contenu principale,
• role=contentinfo pour le pied de page,
• role=search pour le moteur de recherche.

Exemples de problèmes détectés sur la page 1

Les sous-menus du menu burger apparaissant au survol, à la prise de focus ou à l’activation d’un composant d’interface ne sont pas atteignables au clavier.

Cas rencontré : liens d’accès rapide

Les liens d’accès rapide sont des liens présents en début de page et permettent aux utilisateurs qui naviguent au clavier et aux utilisateurs malvoyants qui utilisent une loupe d’écran d’éviter des zones de contenus redondants comme l’entête et la navigation. Il est indispensable d’avoir au moins un lien d’accès rapide vers la zone de contenu principale (<main>). Ces liens peuvent être positionnés hors écran et apparaître à la prise de focus.

Exemples de problèmes détectés sur la page 1

Les zones d’entête, de navigation principale, de contenu principal, de pied de page et de moteur de recherche ne peuvent être atteintes ou évitées. Il est nécessaire de mettre sur ces zones un attribut role, avec la valeur appropriée correspondante : "banner", "main", "search", "contentinfo" ou "navigation". Les zones search, main et contentInfo ne sont pas utilisées.

Cas rencontré : ordre de tabulation

L’ordre de tabulation, c’est-à-dire l’ordre dans lequel le focus se déplace lorsqu’on utilise les touches tab et shift-tab, doit être cohérent. Si l’ordre de tabulation est incohérent, les aveugles, les déficients visuels, les handicapés moteurs et handicapés cognitifs auront de grandes difficultés à naviguer dans la page.

Exemples de problèmes détectés sur la page 1

Aucun lien d’accès rapide n’est présent dans la page, même après 3 tabulations.