Appréciation générale
Niveau d’accessibilité global pour les critères testés : trè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 :
- Page 1 : Douanes - Luxembourg
- Page 2 : Contact — Douanes - Luxembourg
- Page 3 : Certex - Prohibitions et restrictions - Douanes - Luxembourg
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 présente et complète.
Documents bureautiques en téléchargement
L’accessibilité d’un échantillon de 171 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 :
Une quantité importante de documents bureautiques en téléchargement a été détectée, ce qui peut avoir un impact négatif sur l’accessibilité globale de ce site. Sur l’échantillon de fichiers analysé, 92 % sont des documents PDF dont 50 % de formulaires PDF. Le format PDF est en général moins accessible que les pages Web et que les documents Office (.docx, .pptx, etc.). L’accessibilité des formulaires est particulièrement importante dans la mesure où ils sont en général nécessaires à la réalisation de procédures administratives.
Sur les fichiers PDF qui entrent dans le cadre de la loi (publication après le 23 septembre 2018) et issus de l’échantillon, 1 % ont un problème d’accessibilité grave, qui empêche totalement l’accès au contenu du document par les utilisateurs (ex : fichier non balisé, fichier protégé, document numérisé). Ces informations sont données à titre indicatif, car la présence d’une alternative accessible n’a pas été vérifiée dans le cadre de cet audit simplifié.
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 "tableaux"
TableauxRecommandations 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>.
Thématique "scripts"
ScriptsRecommandations 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 » https://www.w3.org/WAI/ARIA/apg/patterns/button/. La croix du menu burger n’est pas accessible au clavier (la touche ESC ne ferme pas le menu).
Thématique "présentation de l'information"
Présentation de l'informationRecommandations générales
Utiliser des feuilles de styles pour présenter de l’information. S’assurer que l’information reste compréhensible lorsque les feuilles de styles sont désactivées. Vérifier l’effet de l’agrandissement à 200 % de la taille des caractères et de la redéfinition des propriétés d’espacement sur la lisibilité. S’assurer que les liens sont correctement identifiables, que la prise de focus est signalée et que l’utilisateur a le contrôle des contenus additionnels qui deviennent visibles au survol ou au focus. S’assurer que les contenus cachés sont ignorés par les technologies d’assistance et que l’information n’est pas donnée uniquement par la forme, taille ou position d’un élément.
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 : infobulles, menus déroulants). Tout élément qui apparaît 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 1
Les sous-menus du menu de navigation apparaissent via des styles CSS uniquement, ils ne peuvent être rendus visibles au clavier.