Audit d'accessibilité simplifié - work-luxembourg.public.lu

Thématique "images"

Cas rencontré : images porteuses d’information

Les images porteuses d’information doivent avoir une alternative textuelle qui sera restituée aux personnes utilisant un lecteur d’écran, aveugles et grands malvoyants. Cette alternative textuelle doit fournir l’information véhiculée par l’image, il ne s’agit pas d’une description de l’image. Pour une image bitmap, son attribut alt doit contenir cette alternative textuelle. Pour une image vectorielle SVG, celle-ci doit avoir l’attribut role="img" et son alternative textuelle pourra être fournie via les attributs aria-label ou aria-labelledby.

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

Le logo "Luxembourg let's make it happen" est porteur d'une information. Ce logo doit avoir une alternative textuelle.

Cas rencontré : images porteuses d’information complexes

Certaines images porteuses d’informations sont particulièrement complexes, par exemple lorsqu’elles présentent des graphiques, schémas, cartes, etc. Dans ce cas, ces images nécessitent une description détaillée adjacente à l’image afin de permettre aux personnes aveugles et dyslexiques d’accéder à toutes les informations véhiculées par l’image. Pour mettre à disposition cette description détaillée, plusieurs solutions sont possibles. Le texte peut être adjacent à l’image dans la même page ou on peut placer un lien adjacent à l’image qui mène à une page où se trouve la description. Le texte peut aussi être inclus dans un composant permettant de le masquer et de l’afficher sur demande, au clic d’un bouton « afficher la description de l’image » (via le design pattern « disclosure »).

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

Les images porteuses d'informations se trouvant sous le titre "Luxembourg's labour market at a glance" ne disposent pas d'une description détaillée.

Thématique "couleurs"

Cas rencontré : informations données uniquement par la couleur

Ce type d’information est un problème pour les personnes déficientes visuelles, aveugles ou par exemple les personnes qui ne voient pas certaines couleurs ou ne perçoivent simplement pas les couleurs. Pour chaque information véhiculée par la couleur, il est nécessaire de mettre en place une alternative, comme par exemple un changement de style (graisse du texte, taille du texte, soulignement, etc.)

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

Dans le menu de navigation, l'information de l'élément actif est donnée uniquement par la couleur. Il est nécessaire de donner cette information par d'autres moyens, notamment via une modification du style (taille du texte, graisse, soulignement, bordure, ...) ainsi que l'attribut aria-current="page".

Cas rencontré : contrastes des textes

Les contrastes de couleurs sont importants pour plusieurs types de déficiences visuelles comme celles des grands malvoyants ou des personnes ayant des problèmes de perception des couleurs. Les contrastes minimaux d’un texte sur le fond de page sont définis par le RGAA comme suit :

• Pour un texte sans effet de graisse
  • De taille inférieure à 24 px : le contraste minimum est de 4.5:1 ;
  • De taille supérieure ou égale à 24 px : le contraste minimum est de 3:1.
• Pour un texte en gras
  • De taille inférieure à 18.5 px : le contraste minimum est de 4.5:1 ;
  • De taille supérieure à 18.5 px : le contraste minimum est de 3:1.

Pour vérifier les contrastes, on peut utiliser un outil tel que « Colour Contrast Analyser ». Si les problèmes de contraste ne peuvent être résolus simplement, il est aussi possible d’utiliser un « style switcher ». C’est une fonctionnalité proposée par le site qui permet de renforcer les contrastes pour les personnes qui ont des problèmes avec les couleurs. Un exemple de « style switcher » est disponible sur le site sncf.com, dans son menu « Accessibilité ».

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

De nombreux textes, notamment les textes des titres ("Luxembourg Labour Market", ...) ont un rapport de contraste largement inférieur aux rapports minimaux pour permettre l'utilisation du site par les grands malvoyants et déficients visuels.

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 P02

Le lien "workinluxembourg@adem.etat.lu" a pour l'attribut title: "Contact workinluxembourg - new window". Ceci ne reprend pas l'intitulé visible du lien.

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 le 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 bitmap, 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 P03

Le lien-image qui représente des graphiques n'a pas d'intitulé (balise alt de l'image vide).

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 »). 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 P01

Le bouton pour afficher la recherche et le bouton pour afficher/ masquer le menu mobile sont structurés par des liens qui possèdent le rôle button. Cependant ils ne respectent pas le design pattern button, car ils ne supportent pas l'activation via la barre d'espace. https://w3c.github.io/aria-practices/#button

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.

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

Le lien "BI Statistiken" n'est pas pourvu d'un indicateur de changement de langue.

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 P01

le focus sur le logo du gouvernement.lu en haut à gauche n'est pas assez visible car on ne voit qu'un trait à droite à côté du logo (dans chrome).

Cas rencontré : contenus additionnels au survol et au focus

Les utilisateurs doivent pouvoir garder le contrôle des contenus additionnels qui apparaissent au survol et au focus (ex: tooltips, menus déroulants). Tout élément qui apparait au survol, doit aussi pouvoir apparaître au clavier, lorsque l’élément prend le focus. Pour les malvoyants qui utilisent une loupe d’écran, ces contenus apparaissant au survol peuvent perturber la consultation du site. Ils doivent pouvoir être masqués simplement. Si le contenu apparaît hors de la zone affichée par la loupe, il doit pouvoir être survolé à la souris.

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

Les contenus des sous-menus ne peuvent être rendus visibles au clavier.

Thématique "formulaires"

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 P02

Le format attendu pour l'adresse Email n'est pas précisé dans l'étiquette ou dans un passage de texte associé au champ.

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 P01

Le formulaire de recherche possède un attribut role="search". Cependant ce moteur de recherche ne permet pas de rechercher dans toutes les pages du site (ex: aspects légaux), il n’est donc pas considéré comme un système de navigation. Le role="search" doit être ici supprimé.