Audit d’accessibilité simplifié - Work in Luxembourg

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 matricielle, 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 1

L’alternative textuelle de l’image des logos en pied de page, "Partner logo", n’est pas pertinente. Elle doit décrire brièvement l’information véhiculée sans redondance, éviter « image de », ne pas répéter le contexte visible et être cohérente avec le contenu. (Ex: <img alt="ADEM EURES Luxembourg Confinancé par l'Union européenne" … />)

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 3

Les images décoratives qui disposent le texte alternatif "Description Image" devraient porter un alt vide.

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 1

Dans le menu de navigation, l’information de l’élément actif est donnée par un soulignement. Il est nécessaire de donner cette information également via l’attribut aria-current="page". L'attribut aria current page n'est pas implémenté.

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 RAWeb 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 sélecteur de styles. 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 sélecteur de styles est disponible sur le site guichet.lu, dans son menu « Accessibilité ».

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

Certains textes sur cette page n’ont pas un contraste suffisant (p. ex. Les textes situés dans les encadrés « TALENTS WORLDWIDE » et « EMPLOYERS' AREA » : contraste de couleur attendu : 4.5:1). Contraste relevé de 1,98:1 sur #68C7BB sur #717DB4.

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

Le menu mobile ne respecte pas le design pattern ARIA "Disclosure" https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/ Il n’est pas possible de le fermer avec la touche ESC ou de l'activer/fermer avec la touche Espace. La fenêtre modale des cookies ne réagit pas à la touche ESC.

Thématique "structuration de l'information"

Cas rencontré : structure du document HTML5

La structuration du document HTML5 permet aux aveugles, grands malvoyants et handicapés moteurs de naviguer très rapidement entre les zones principales de la page (header, footer, zone de contenu principale, navigation, …)

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

La balise header manque pour la structure.

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 2

Le type de données attendu dans le champ « e-mail » n’est pas précisé, et cela ni dans l’étiquette, ni dans le message d’erreur. Il est nécessaire de donner un exemple.

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 zones d’entête qui manquent sont **banner, navigation et search **.

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 3

Aucun accès rapide.