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 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 RGAA.
Échantillon de pages et référentiel
Voici les pages qui ont été évaluées lors de cet audit :
- Page 1 : Portail de l'environnement - emwelt.lu - Luxembourg
- Page 2 : Contact — Portail de l'environnement - emwelt.lu - Luxembourg
- Page 3 : Bruit - Loft a Kaméidi - Portail de l'environnement - emwelt.lu - Luxembourg
Méthode d’évaluation : Méthode de contrôle simplifiée de l’accessibilité pour le Luxembourg – v1.2
Référentiel : RGAA v4.1.2
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 1085 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 :
Un nombre important de contenus dérogés impacte la pertinence des résultats de l’audit (la liste des dérogations prévues par la loi est disponible sur la page "obligations" du site accessibilite.public.lu). Le site contient un grand nombre de contenus dérogés. En effet, un nombre important de fichiers PDF a été publié avant le 23 septembre 2018 (soit 467 fichiers). Bien que ces fichiers soient exemptés d’obligation de mise en accessibilité par la loi du 28 mai 2019, il est recommandé de les rendre accessibles, sans quoi une part importante du contenu mis à disposition sur ce site ne pourra être consulté par les personnes en situation de handicap.
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é, 95 % sont des documents PDF dont 1 % 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 "images"
ImagesRecommandations 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 3
Le logo placé en illustration sous l'entête "Administration de l'environnement" est porteur d'information et devrait bénéficier d'un attribut alt
reprenant le texte visible (et non pourvu de la valeur "Logo-AEV-MECDD").
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
En mode mobile, la loupe comme le burger menu doivent pouvoir être activés aussi via la touche espace, répondant aux critères du motif de conception ARIA Button (https://www.w3.org/WAI/ARIA/apg/patterns/button/).
Thématique "éléments obligatoires"
Éléments obligatoiresRecommandations générales
Vérifier que dans chaque page Web, le code source généré respecte les règles d’écriture correspondant au type de document, que le titre est pertinent et la langue par défaut, 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.
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 les articles de menu, le titre à la une, certaines publications).
Thématique "structuration de l'information"
Structuration de l'informationCas 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 1
Les premiers éléments de la colonne de droite, "Eist Wëllt", "Newsletters", "Info eau" etc. jusqu'à "Agenda" se rapportent au titre "Publications". Il faudrait que ces éléments soient de niveau <h1>
, comme l'est l'agenda (qui présente d'ailleurs la même apparence que les titres précédents, ce serait donc logique de retrouver cette même structuration dans le code).
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 3
Le fil d'Ariane doit être intégré dans une balise <nav>
.
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 apparait 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 ne sont pas accessibles au clavier.
Thématique "navigation"
NavigationRecommandations 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
Le rôle search doit correspondre à une recherche portant sur l'intégralité du site.