Appréciation générale

Niveau d’accessibilité global pour les critères testés : bon.

(Échelle : très faible, faible, moyen, bon, très bon)

Avertissement

Il s’agit là d'un audit simplifié et non d’un audit de conformité (ou audit "complet"). Il a vocation à détecter une série de problèmes d’accessibilité mais n’est pas exhaustif. Le fait qu’aucun problème ne soit remonté pour un critère d’accessibilité donné ne signifie pas qu’il n’y a pas de problème d’accessibilité pour ce critère. De même, lorsque nous rapportons une occurrence d’un problème, ce problème peut avoir d’autres occurrences. Il est nécessaire de vérifier de manière exhaustive l’accessibilité de ce site conformément au référentiel RAWeb.

Échantillon de pages et référentiel

Voici les pages qui ont été évaluées lors de cet audit :

Méthode d’évaluation : Méthode de contrôle simplifiée de l’accessibilité pour le Luxembourg – v1.2.1

Référentiel : RAWeb v1

Déclaration sur l’accessibilité

La déclaration sur l’accessibilité est manquante. Celle-ci est obligatoire d’après l’article 5 de la loi du 28 mai 2019. Cette déclaration s’effectue après avoir réalisé un audit de conformité basé sur le RAWeb. Pour créer une déclaration sur base des résultats d’un audit de conformité, le formulaire disponible à cet effet sur accessibilite.public.lu peut être utilisé. Une fois la déclaration d’accessibilité publiée, l’éditeur du site a 30 jours pour en informer le SIP par e-mail à l’adresse accessibilite@sip.etat.lu.

Documents bureautiques en téléchargement

L’accessibilité d’un échantillon de 602 fichiers bureautiques en téléchargement sur le site considéré a été analysée.

Le niveau d’accessibilité global présenté dans la section "Appréciation générale", doit être nuancé au vu des points suivants :

Pour information, le SIP met à disposition le référentiel d’évaluation de l’accessibilité des documents au format PDF (RAPDF). Pour chaque document PDF en téléchargement, il est possible de le rendre accessible en respectant les critères de ce référentiel, ou de proposer une alternative accessible, sous la forme d’une page Web ou d’un document Office (.docx, .pptx, etc.) proposant les mêmes informations.

 

Annexe technique

Thématique "images"

Images

Recommandations générales

Donner à chaque image porteuse d’information une alternative textuelle pertinente et une description détaillée si nécessaire. Lier les légendes à leurs images. Remplacer les images textes par du texte stylé lorsque c’est possible. Pour trouver la bonne alternative textuelle pour une image donnée, vous pouvez vous aider de l’arbre de décision proposé par la WAI.

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’alternative textuelle de l’image dans la section "Découvrir" n’est pas pertinente. Elle est actuellement "Image is not available". Elle doit recevoir un attribut alt sans valeur indiquée.

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 motif de conception ARIA « disclosure »).

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

L’image « Garnich en chiffres » est porteuse d’informations (par ex. « Garnich à 56,70 % », répartition hommes/femmes « 1147/1172 »), mais ces données ne sont pas décrites textuellement de manière détaillée à proximité. Fournir une description structurée (titres, listes, tableau) restituant l’intégralité de l’information.

Thématique "cadres"

Cadres

Recommandations générales

Donner à chaque cadre un titre pertinent.

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 1

Certaines iframes ne portent pas d'attribut title.

Thématique "couleurs"

Couleurs

Recommandations générales

Ne pas donner l’information uniquement par la couleur et utiliser des contrastes de couleurs suffisamment élevés pour les textes, les composants d’interface ou les éléments porteurs d’informations.

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. Par exemple :

  • Lien de navigation « Agenda et Manifestations » (#FFFFFF sur #41B6E7, 12px non gras) : contraste mesuré 2.31:1, attendu 4.5:1.
  • Titre « Contactez-nous » (#FFFFFF sur #E73456, 20px non gras) : contraste mesuré 4.18:1, attendu 4.5:1.

Thématique "tableaux"

Tableaux

Recommandations générales

Associer correctement les tableaux de données à leur titre, donner à chaque tableau de données complexe, un résumé, identifier clairement les cellules d’en-tête, utiliser un mécanisme pertinent pour lier les cellules de données aux cellules d’en-tête. Pour chaque tableau de mise en forme, veiller à sa bonne linéarisation.

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 1

La portée des entêtes de ligne et de colonne n’est pas précisée dans le tableau « Contact & horaires ». Ajouter scope="col" sur chaque entête de colonne et scope="row" sur les entêtes de ligne pour garantir l’association cellules↔en-têtes.

Thématique "liens"

Liens

Recommandations générales

Utiliser des intitulés de liens explicites, grâce à des informations de contexte notamment.

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

Des liens ne sont pas explicites. Par exemple, le lien « facebook » n’expose pas d’intitulé discernable, et le lien « cliquez-ici » dans « Accédez à nos publications » ne désigne pas clairement sa destination. Cela peut poser problème pour les utilisateurs de logiciels de reconnaissance vocale.

Thématique "scripts"

Scripts

Recommandations générales

Donner si nécessaire à chaque script une alternative pertinente. Avertir ou permettre le contrôle des scripts qui initient un changement de contexte. Rendre possible le contrôle de chaque code script au moins par le clavier et par tout dispositif de pointage et s’assurer de leur compatibilité avec les technologies d’assistance notamment pour les messages de statut.

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 burger doit être implémenté avec une balise <button> ou répondre au design pattern ARIA « Button » (activation clavier). Le menu burger ne réagit pas à la touche ESC (disclosure).

Thématique "structuration de l'information"

Structuration de l'information

Recommandations générales

Utiliser des titres, des listes, et des citations pour structurer l’information. S’assurer que la structure du document est cohérente.

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 3

Certains passages de texte sont visuellement des titres sans utilité structurelle. Dans « Qui habite Garnich ? », les pourcentages sont marqués comme titres HTML alors qu’ils ne structurent pas le contenu ; ils devraient être intégrés dans le texte courant plutôt qu’en <hX>.

Thématique "formulaires"

Formulaires

Recommandations générales

Pour chaque formulaire, associer chacun de ses champs à son étiquette, grouper les champs de même nature et leur donner une légende, structurer les listes de choix de manière pertinente, donner à chaque bouton un intitulé explicite. Vérifier la présence de suggestions lors des erreurs de saisie, s’assurer que le contrôle de saisie est accessible, que la finalité des champs peut être déduite et que l’utilisateur peut garder le contrôle sur ses données à caractère financier, juridique ou personnel.

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 1

Dans le formulaire de contact, les étiquettes ne sont pas associées aux champs de saisie. Lier chaque <label for="..."> à l’id du champ correspondant.

Cas rencontré : intitulés de boutons pertinents

Les boutons doivent avoir des intitulés pertinents, qui communiquent l’action réalisée à l’activation. Ces informations sont particulièrement importantes pour les déficients visuels et cognitifs.

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

Le bouton tout en bas de la page dans la section « Il vous reste encore des questions ? » n’est pas accessible : son nom accessible (aria-label/title) ne reprend pas l’intitulé visible du bouton ou n’est pas correctement exposé.

Navigation

Recommandations générales

Proposer au moins deux systèmes de navigation différents dans un ensemble de pages (menu de navigation, plan du site ou moteur de recherche). Donner la possibilité d’éviter ou d’atteindre les principaux regroupements de contenus en particulier la zone de contenu principale via un lien d’évitement ou d’accès rapide. S’assurer que l’ordre de tabulation est cohérent et que la page ne comporte pas de piège au clavier. S’assurer que les raccourcis clavier n’utilisant qu’une seule touche sont contrôlables par l’utilisateur.

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, de navigation principale, de moteur de recherche, de contenu principal et de pied de page ne peuvent être atteintes ou évitées : les rôles de regroupement "banner", "navigation", "search", "main" et "contentinfo" ne sont pas présents. Les ajouter avec la valeur appropriée

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

L’ordre de tabulation n’est pas cohérent. Exemple : les éléments de la boîte cookies ne doivent pas figurer parmi les derniers à recevoir le focus.