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 365 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 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’image svg du logo "Koplescht Briddel" est porteuse d’information mais n’a pas d’alternative textuelle. Celle-ci doit être renseignée dans l’attribut aria-label ou aria-labelledby de la balise <svg>, qui doit par ailleurs être pourvue d'un attribut role="img". (Ex: <svg role="img" aria-label="yyy" ... ></svg>)

Cas rencontré : CAPTCHA

Tout CAPTCHA visuel qui ne fournit pas d’alternative permettant d’identifier sa nature et qui n’est pas accompagné d’un moyen alternatif pour passer le test (ex : CAPTCHA sonore) constitue un problème insurmontable pour les aveugles et les déficients visuels. Différentes alternatives aux CAPTCHA visuels sont décrites dans le document « Inaccessibility of CAPTCHA - Alternatives to Visual Turing Tests on the Web » publié par le W3C.

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

Le lien-image du CAPTCHA n'a pas d'intitulé (ex: Image CAPTCHA). 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, notamment en précisant la fonction de l'image.

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 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 notamment le tableau "Aïkido Kopstal-Bridel".

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 ne réagit pas à la touche ESC (disclosure). Le menu ne respecte pas le design pattern "Disclosure Navigation Menu" https://www.w3.org/WAI/ARIA/apg/example-index/disclosure/disclosure-navigation.html https://www.w3.org/WAI/ARIA/apg/example-index/disclosure/disclosure-navigation-hybrid.html

Thématique "éléments obligatoires"

Éléments obligatoires

Recommandations générales

Vérifier que dans chaque page Web, le titre est pertinent et la langue par défaut est indiquée. Vérifier que les balises ne sont pas utilisées uniquement à des fins de présentation, que les changements de langues et de direction de sens de lecture sont indiqués.

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 le texte luxembourgeois de l'article du Agenda au 16.11.25).

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 2

L’étiquette du champ d'entrée du CAPTCHA n’est pas visible. Un placeholder n’est ici pas suffisant, car il ne sera plus visible une fois que l’utilisateur aura commencé à remplir le champ. Une solution peut être de placer un attribut title sur le champ, qui contient le contenu de l’étiquette. Ce contenu sera visible au "hover", même pendant la saisie.

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 texte qui indique les champs obligatoires n’est pas précisé avant le formulaire. Il doit être indiqué de manière visible avant la soumission pour éviter les erreurs.

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 de regroupement 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". La zone de recherche n'utilise pas le rôle "search".