Introduction
Ce rapport accompagne le relevé d'audit effectué sur le site « sécurité alimentaire ».
La méthodologie d'audit employée repose sur le référentiel RAWeb 1, consultable à l'adresse suivante : https://accessibilite.public.lu/fr/raweb1/index.html
L'audit a été réalisé au moyen de l'utilisation de navigateurs web et d'outils spécialisés. Des tests de restitution ont également été effectués conformément à la base de référence définie par le RAWeb 1.
Échantillon
L'audit a porté sur un échantillon de 14 pages :
| Nº page | Titre de la page | URL |
|---|---|---|
| P01 | Page d'accueil | https://securite-alimentaire.public.lu/fr.html |
| P02 | Mentions légales | https://securite-alimentaire.public.lu/fr/support/aspects-legaux.html |
| P03 | Accessibilité | https://securite-alimentaire.public.lu/fr/support/accessibilite.html |
| P04 | Plan du site | https://securite-alimentaire.public.lu/fr/support/plan.html |
| P05 | Contact | https://securite-alimentaire.public.lu/fr/support/contact.html |
| P06 | Aide | https://securite-alimentaire.public.lu/fr/support/a-propos.html |
| P07 | Recherche | https://securite-alimentaire.public.lu/fr/recherche.html?q= |
| P08 | Actualités | https://securite-alimentaire.public.lu/fr/actualites.html |
| P09 | Un événement | https://securite-alimentaire.public.lu/fr/actualites/evenements/2024/research-conference-contaminants.html |
| P10 | Une alerte | https://securite-alimentaire.public.lu/fr/actualites/alertes/2024/10/rappel-croutons-rouille-soupe-palais-des-mets.html |
| P11 | Contrôle | https://securite-alimentaire.public.lu/fr/organisme.html |
| P12 | Notification obligatoire | https://securite-alimentaire.public.lu/fr/professionnel/notification_probleme.html |
| P13 | Check-liste | https://securite-alimentaire.public.lu/fr/publications/checklists/allergenes-generaux.html |
| P14 | Formulaire signalement | https://securite-alimentaire.public.lu/fr/support/doleances.html |
Environnement de test (base de référence)
Quelques critères RAWeb, notamment ceux de la thématique JavaScript, incluent des tests de restitution à effectuer sur des technologies d'assistance associées à des navigateurs et des systèmes d'exploitation. Pour qu'un dispositif HTML / WAI-ARIA ou son alternative soit considéré comme compatible avec l'accessibilité, il faut qu'il soit pleinement fonctionnel, en termes de restitution et de fonctionnalités sur certaines combinaisons. Vous trouverez une explication détaillée de cet environnement de tests dans le document du RAWeb 1.
Nous détaillons ci-dessous la base de référence utilisée pour réaliser les tests de restitution des composants du site.
Environnement de test – ordinateur
| Technologie d'assistance | Navigateur |
|---|---|
| NVDA 2025 | Firefox |
| JAWS 2025 | Firefox |
| VoiceOver (macOS Tahoe version 26.1) | Safari 26.1 |
Environnement de test — mobile
| Système d'exploitation | Technologie d'assistance | Navigateur |
|---|---|---|
| Android natif | TalkBack (Android 16) | Chrome |
| iPhone | VoiceOver (iOS 18.5) | Safari |
Accessibilité des pages auditées
Le site présente un bon niveau général d'accessibilité
Le niveau de conformité relevé atteint 82,19 % de conformité au RAWeb sur l'ensemble des pages auditées.
Le site est partiellement conforme.
Note sur le calcul de conformité
La conformité globale (Tableau « Conformité RAWeb 1 ») est calculée de la manière suivante : C / (C+NC). C'est le nombre de critères conformes et NC le nombre de critères non conformes.
C'est ce nombre qui constitue la référence légale. Il représente le taux de conformité de l'échantillon.
Il est normal que le taux de conformité global diffère sensiblement du taux de conformité par page. En effet, un critère NC (non conforme) sur une page rend le critère non conforme sur l'ensemble de l'échantillon.
Pour qu'un site soit conforme (100 % des critères applicables sont conformes), il est nécessaire que le taux de conformité par page équivaille à 100 %.
Moyenne par pages
| Nº page | Titre de la page | %C |
|---|---|---|
| P01 | Page d'accueil | 93,88% |
| P02 | Mentions légales | 95,74% |
| P03 | Accessibilité | 97,96% |
| P04 | Plan du site | 97,96% |
| P05 | Contact | 92,31% |
| P06 | Aide | 97,87% |
| P07 | Recherche | 98,00% |
| P08 | Actualités | 98,00% |
| P09 | Un événement | 88,68% |
| P10 | Une alerte | 86,00% |
| P11 | Contrôle | 95,74% |
| P12 | Notification obligatoire | 89,83% |
| P13 | Check-liste | 93,88% |
| P14 | Formulaire signalement | 92,31% |
Moyenne par thématiques
| Thématiques | C | NC |
|---|---|---|
| Images | 66,67% | 33,33% |
| Cadres | 100,00% | 0,00% |
| Couleurs | 100,00% | 0,00% |
| Multimédia | 71,43% | 28,57% |
| Tableaux | 33,33% | 66,67% |
| Liens | 100,00% | 0,00% |
| Script | 50,00% | 50,00% |
| Éléments obligatoires | 88,89% | 11,11% |
| Structuration | 33,33% | 66,67% |
| Présentation | 84,62% | 15,38% |
| Formulaires | 91,67% | 8,33% |
| Navigation | 100,00% | 0,00% |
| Consultation | 75,00% | 25,00% |
| Documentation | 0,00% | 0,00% |
| Outils d'édition | 0,00% | 0,00% |
| Assistance | 100,00% | 0,00% |
| Communication | 0,00% | 0,00% |
Impacts utilisateurs
Globalement, le site présente peu d’erreurs, avec un impact modéré sur l’expérience utilisateur.
Exemptions
Sont listés ci-dessous les contenus exemptés de l’obligation d’accessibilité. Ils n’entrent pas dans le calcul de la conformité et ne sont pas audités.
- ---
Contenus dérogés
Lorsque l’organisme ne peut pas rendre un contenu ou une fonctionnalité accessible, le RAWeb prévoit sous certaines conditions la possibilité d’invoquer une dérogation pour charge disproportionnée. Cette dernière doit être dûment justifiée et compensée dans la mesure du possible avec la production d’une alternative accessible aux personnes handicapées.
Les contenus suivants n'entrent pas dans le calcul de la conformité ni dans le périmètre des éléments à rendre accessibles, ils sont dérogés :
- Les documents en téléchargement fournis par des administrations tierces ne sont pas sous notre contrôle.
- Toutes les vidéos publiées avant le 23 septembre 2020 sur le site.
- Le gestionnaire des cookies « Orejime » pour contenu de tiers
Droit à la compensation
Les dérogations émises notamment pour charge disproportionnée demandent en contrepartie la mise en place d'un moyen de compensation pour les utilisateurs. Pour les documents bureautiques par exemple, vous devez fournir un moyen à l'utilisateur de demander une version accessible d'un document s'il en a besoin. Cela peut être un mail ou un formulaire de contact.
Avis
Le site présente actuellement un bon taux de conformité, il repose sur des bases solides en matière d'accessibilité. De nombreuses erreurs relevées semblent relativement simples à corriger, et certaines ne se produisent que sur une seule page. Avec des ajustements ciblés, le site peut atteindre un niveau élevé de conformité, voire être totalement conforme et offrir une meilleure expérience à tous les utilisateurs.
Les non-conformités les plus bloquantes pour les utilisateurs concernent :
- Les tableaux
- Les vidéos
- Le menu de navigation principal
Ce sont donc ces points qui devront nécessiter une attention toute particulière et qui demanderont le plus d'efforts.
Annexe technique
Images
Recommandation
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.
Images porteuses d'information
Il est nécessaire de donner une alternative pertinente dans le cas où la suppression de l'image entraînerait un problème de compréhension des contenus.
Constats sur le site
Sur la page « Check-liste », l’image <img> représentant la version réduite du PDF contient l’information « Version non officielle », qui n’est présente nulle part ailleurs. Il est donc nécessaire soit de l’indiquer dans l’attribut alt, soit de faire apparaître cette information dans le texte adjacent ou directement dans le lien.
Multimédia
Recommandation
Donner si nécessaire à chaque média temporel une transcription textuelle, des sous-titres synchronisés et une audiodescription synchronisée pertinente. Donner à chaque média non temporel une alternative textuelle pertinente. Rendre possible le contrôle de la consultation de chaque média temporel et non temporel au clavier et s'assurer de leur compatibilité avec les technologies d'assistance.
Transcription textuelle
Les vidéos présentes sur le site ne disposent pas de transcription textuelle. Il s'agit d'un impact majeur d'accessibilité. En effet, la transcription textuelle est utile pour différents types d'utilisateurs (aveugles, malvoyants, sourds, malentendants, handicapés moteurs, handicapés cognitifs).
Cette transcription doit être un fichier structuré (docx, HTML) qui reprend toutes les informations présentes (visuelles et sonores) dans la vidéo.
Cette transcription peut être située :
- soit sur la même page que la vidéo ;
- soit ailleurs sur le site. Dans ce cas, ajouter alors un lien vers la transcription sous la vidéo par exemple.
Audiodescription
Chaque vidéo doit disposer d'une version audiodécrite, si nécessaire. En effet, des textes incrustés ou des actions d'intérêt dans une vidéo ne seront pas perçus par un utilisateur aveugle.
De plus, l'utilisateur doit pouvoir activer ou désactiver l'audiodescription depuis le lecteur vidéo.
Constats sur le site
Sur la page « Notification obligatoire », la vidéo de présentation du nouvel assistant pour la notification obligatoire de retrait/rappel via MyGuichet (Vidéo YouTube) ne possède ni transcription textuelle ni audiodescription.
Tableaux
Recommandation :
Donner un résumé à chaque tableau de données complexe, s'assurer que pour chaque tableau de données ayant un titre, ce titre est pertinent, 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.
Tableaux de données
Un tableau de données doit répondre à certains enjeux pour être exploité correctement par les lecteurs d'écran. Les enjeux sont les suivants :
- Le tableau doit posséder un titre permettant de l'identifier (
<caption>) ; - Les en-têtes doivent être identifiés (balises
<th>) et doivent pouvoir être restitués lorsque l'utilisateur parcourt chaque cellule à l'aide de son lecteur d'écran (attributsscopesi nécessaire).
Constats sur le site
Sur la page « Un événement », le tableau « Agenda » n'a pas de titre et les entêtes de ligne ne sont pas déclarés.
Scripts
Recommandation :
Donner si nécessaire à chaque script une alternative pertinente. Rendre possible le contrôle de chaque code script au moins par le clavier et la souris et s'assurer de leur compatibilité avec les technologies d'assistance. Identifier les messages de statut lorsque c'est nécessaire.
Éléments interactifs inaccessibles au clavier
Si un élément ne peut pas recevoir le focus ou n'est pas totalement utilisable au clavier, les utilisateurs pour lesquels le clavier est le seul moyen de naviguer seront bloqués.
Constats sur le site
Sur la page « Recherche », dans la fenêtre modale « Filtrer », la navigation au clavier ne permet pas de faire défiler verticalement le contenu. Lors de la tabulation, les cases à cocher atteintes devraient automatiquement être rendues visibles, ce qui n’est pas le cas actuellement.
Fenêtres modales
Constats sur le site
En version responsive, la zone de recherche utilise le motif ARIA Disclosure, qui n’est pas adapté pour ce type de composant. Dans ce cas, c’est le motif ARIA Dialog qui doit être appliqué, puisqu’il s’agit d’une fenêtre modale.
Gestion de la visibilité de zones
Le site possède des fonctionnalités d'affichage ou de masquage des zones de contenus. L'état affiché/masqué du contenu additionnel doit pouvoir être disponible pour les technologies d'assistance afin que les utilisateurs aveugles accèdent à cet état.
Pour ce type d’élément, l’implémentation du motif ARIA Disclosure est recommandée.
Constats sur le site
Dans le menu de navigation principal, les éléments cumulent deux rôles : ils sont à la fois des liens et des boutons permettant d’ouvrir un sous-menu. Le motif de conception ARIA Disclosure est déjà implémenté, ce qui rend la propriété aria-haspopup inutile et donc à supprimer.
Actuellement, les touches Entrée et Espace déclenchent des actions différentes : Entrée active le lien, tandis que Espace ouvre le sous-menu. Pour un utilisateur de lecteur d’écran naviguant au clavier, cette logique est déroutante : la touche attendue pour activer un lien est Entrée, et rien n’indique que la touche Espace ouvre le sous-menu.
La solution la plus simple consiste à s’appuyer uniquement sur le motif ARIA Disclosure, en utilisant de véritables éléments <button> pour ouvrir les sous-menus, les liens de premier niveau étant alors intégrés à l’intérieur de ces sous-menus.
Une autre option consiste à séparer clairement les deux fonctions : un bouton dédié à l’ouverture/fermeture du sous-menu, distinct du lien qui mène vers une nouvelle page.
À noter qu’en version responsive (ou en zoom élevé), les éléments du menu deviennent uniquement des liens : l’ouverture des sous-menus n’est alors plus possible, ce qui entraîne une perte de fonctionnalité par rapport à la version desktop.
Éléments obligatoires
Recommandation
Vérifier que chaque page web a un code valide selon le type de document, un titre pertinent et une indication de langue par défaut. 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.
Balises utilisées à des fins de présentation
Les éléments de structure HTML ont chacun une sémantique particulière (paragraphe, titre, image, lien, etc.). Si les éléments sont mal employés (détournés de leur utilité première), cela peut poser des problèmes aux utilisateurs qui naviguent à l'aide d'une technologie d'assistance (lecteur d'écran, plug-in…). En effet, les technologies d'assistance disposent de raccourcis permettant de naviguer rapidement entre certains types d'éléments (paragraphes, titres, listes, etc.). Si ces éléments sont mal employés, les utilisateurs ne peuvent pas utiliser ces fonctionnalités de repère et de navigation dans le contenu.
Constats sur le site
Sur la page « Mentions légales », on trouve des paragraphes (<p>) vides servant à créer des espacements. Par exemple entre les textes « Le responsable de ces traitements est l'Organisme responsable de ce site. » et « Dernière modification le 22.11.2024 » dans le bloc « Traitements liés à la gestion de la newsletter ».
Structuration de l'information
Recommandation
Utiliser des titres, des listes, des abréviations et des citations pour structurer l'information. S'assurer que la structure du document est cohérente.
Titres
Le titrage des contenus est une étape importante dans la structuration des contenus. Cela répond à deux besoins :
- identifier rapidement un contenu recherché ;
- naviguer rapidement dans le contenu en se déplaçant de titre en titre.
Un titrage correct fournit à l'utilisateur d'un lecteur d'écran un plan du document et lui permet de naviguer de titre en titre pour se déplacer plus rapidement dans le contenu de la page.
Pour valider la structure de votre page, vous pouvez utiliser l'extension Firefox HeadingsMap ou Chrome HeadingsMap. Lorsque l'extension est active, sélectionnez l'onglet « Headings » et vérifiez la cohérence et l'imbrication des titres.
Constats sur le site
Sur la page « Accueil », le texte « Administration luxembourgeoise vétérinaire et alimentaire » doit être un titre de niveau 2.
Listes
La structuration en listes permet aux utilisateurs de lecteurs d'écran de consulter plus rapidement le contenu, grâce à des raccourcis spécifiques, et d'accéder directement à une liste ou de la passer sans avoir à en parcourir tous les items.
Constats sur le site
Sur la page « Accueil », les éléments de définition du bloc « Contact presse » ne sont pas structurés.
Présentation de l'information
Recommandation
Utiliser des feuilles de styles pour contrôler la présentation de l'information. Vérifier l'effet de l'agrandissement des tailles des caractères sur la lisibilité. S'assurer que les liens sont correctement identifiables, que la prise de focus est signalée, que l'interlignage est suffisant et donner la possibilité à l'utilisateur de contrôler la justification des textes. S'assurer que les textes cachés sont correctement restitués et que l'information n'est pas donnée uniquement par la forme ou la position d'un élément. S'assurer que les contenus sont lisibles et utilisables dans une fenêtre de largeur réduite. Veiller à ce que l'application de paramètres typographiques n'entraîne pas la perte de contenu ou de fonctionnalité. S'assurer que les contenus qui apparaissent au survol et à la prise de focus puissent être contrôlés par l'utilisateur.
Contenu compréhensible sans les styles : ordre visible vs ordre réel
Un utilisateur aveugle n'a pas accès à la mise en forme qui parfois est porteuse d'informations importantes, notamment des relations entre les éléments.
Il est important de ne pas implémenter les textes dans l'ordre visuel, mais bien dans l'ordre logique de dépendance et hiérarchie des éléments.
Le contenu doit rester compréhensible sans les feuilles de styles (vous pouvez tester vos contenus en désactivant les feuilles de styles).
Constats sur le site
Sur la page « Contact », le paragraphe concernant la « Protection des données à caractère personnel » est mal positionné dans le code source. On doit pouvoir prendre connaissance de ce texte avant l'envoi du formulaire.
Formulaires
Recommandation :
Associer pour chaque formulaire chacun de ses champs à son étiquette, grouper les champs dans des blocs d'informations de même nature, regrouper les items de même nature dans les listes de choix, donner à chaque bouton un intitulé explicite. Vérifier la présence d'aide à la saisie, s'assurer que le contrôle de saisie est accessible et que l'utilisateur peut contrôler les données à caractère financier, juridique ou personnel.
Groupe d'options de liste de choix
Dans une liste de choix, les options doivent être clairement organisées afin que tous les utilisateurs puissent comprendre la structure et la logique des catégories proposées.
Un regroupement d’options (via <optgroup>) permet de structurer une liste longue ou complexe en plusieurs sections, chacune portant un intitulé qui décrit le type d’options qu’elle contient.
Grâce à cela, lorsqu’un utilisateur navigue dans la liste avec un lecteur d’écran, celui-ci annonce le nom du groupe avant les différentes options. L’utilisateur comprend ainsi immédiatement à quelle catégorie appartient chaque choix.
Sans ces regroupements, toutes les options seraient lues les unes à la suite des autres, sans contexte. L’utilisateur ne percevrait pas la logique de classification et risquerait de ne pas trouver l’option pertinente.
Constats sur le site
Sur la page « Contact », la liste de sélection « Pays » utilise bien la balise <optgroup> mais les options à regrouper ne sont pas positionnées à l'intérieur de la balise.
Consultation
Recommandation
Vérifier que l'utilisateur a le contrôle des procédés de rafraîchissement, des changements brusques de luminosité, des ouvertures de nouvelles fenêtres et des contenus en mouvement ou clignotants. Ne pas faire dépendre l'accomplissement d'une tâche d'une limite de temps sauf si elle est essentielle et s'assurer que les données saisies sont récupérées après une interruption de session authentifiée. Proposer des versions accessibles ou rendre accessibles les documents en téléchargement. S'assurer que la consultation n'est pas dépendante de l'orientation de l'écran. Toujours proposer un geste simple en alternative d'un geste complexe permettant de réaliser une action.
Documents en téléchargement
Assurez-vous que chaque document soit accessible (cf. les Guides de créations de documents bureautiques accessibles), ou qu'il dispose d'une alternative accessible proposant le même contenu (par exemple, une version HTML correctement structurée).
Constats sur le site
Sur la page « Un événement », dans le document PDF « eskes.pdf »,plusieurs problèmes sont présents : contrastes insuffisants, absence de titres, absence de table des matières, et surtout absence de balisage du document.