Appréciation générale
Niveau d’accessibilité global pour les critères testés : moyen.
(É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 : Accueil - Parc-Hosingen
- Page 2 : Contactez-nous - Parc-Hosingen
- Page 3 : Les associations locales - Parc-Hosingen
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 incomplète. Certaines informations obligatoires sont manquantes, par exemple : niveau de conformité, coordonnées de contact (adresse email), lien vers le site du Service information et presse (SIP), lien vers le site du médiateur (Ombudsman). Les éléments obligatoires de la déclaration sont présentés dans l’article 5 de la loi du 28 mai 2019. Une fois la déclaration d’accessibilité mise à jour, l’éditeur du site a 30 jours pour en informer le SIP par mail à l’adresse accessibilite@sip.etat.lu.
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 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’image "app parchousen" dispose d’un attribut alt renseigné alors qu’il devrait être vide.
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
Chaque <iframe> doit disposer d’un attribut title non vide et pertinent décrivant sa fonction ou son contenu. (Actuellement, certains iframes n’ont pas l’attribut title rempli.)
Thématique "liens"
LiensCas rencontré : présence d’intitulés
Un lien doit toujours avoir un intitulé. Celui-ci permet aux utilisateurs de comprendre la destination du lien. La présence d’intitulés sur tous les liens est particulièrement importante pour les aveugles et malvoyants. Si un lien n’a pas d’intitulé, les lecteurs d’écran vont lire simplement « lien » sans annoncer sa destination.
- Pour un lien qui ne contient qu’une image, l’intitulé du lien est l’alternative de l’image. Pour une image matricielle, son attribut
altdoit contenir l’intitulé du lien (ex :<a href="https://facebook.com"><img src="..." alt="facebook" /></a>). Pour une image vectorielle SVG, celle-ci doit avoir l’attributrole="img"et l’intitulé du lien pourra être fourni via les attributsaria-labelouaria-labelledby(ex :<a href="https://facebook.com"><svg role="img" aria-label="facebook">...</svg></a>). - Lorsqu’un lien contient du texte et des images, l’intitulé du lien correspond à la concaténation des intitulés de ces différents éléments contenus dans le lien (ex : pour
<a href="https://facebook.com"><img src="..." alt="logo Facebook" /> Facebook</a>l’intitulé du lien est « logo facebook facebook ». Dans cet exemple, cet intitulé n’est pas pertinent et l’alternative de l’image doit être vide.)
Exemples de problèmes détectés sur la page 1
Le lien "pacte climat" a un intitulé qui ne reprend pas son contenu visible / n’a pas d’intitulé explicite dans la section « Les pactes de la commune ». Cela peut poser problème pour les utilisateurs de technologies d’assistance et de logiciels de reconnaissance vocale.
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 ». Il n’est pas tabulable au clavier et ne réagit pas aux touches ESC ou Espace.
Thématique "structuration de l'information"
Structuration de l'informationCas 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 1
Les zones de navigation principale, d’entête, de pied de page et de contenu principal ne sont pas structurées par les balises html5 correspondant à leur fonction. Par exemple, la balise <main> n’est pas utilisée.
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é : visibilité du focus
Les handicapés moteurs qui naviguent au clavier utilisent l’indicateur de focus fourni par le site sur les éléments interactifs pour savoir où ils se situent dans la page. L’indicateur de focus se déplace via les touches tab et shift-tab. L’indicateur de focus par défaut peut être désactivé via CSS, dans ce cas il est nécessaire de changer le style de l’élément interactif pour rendre l’indicateur de focus visible (sa couleur devra avoir un contraste minimum de 3:1 avec l’arrière-plan contigu).
Exemples de problèmes détectés sur la page 1
Dans de nombreux éléments de cette page, le focus n’est pas visible (ex: les sous-éléments du menu burger).
Cas rencontré : contenus cachés
Tout contenu dans la page peut être ignoré par les technologies d’assistance (notamment en utilisant l’attribut aria-hidden="true"). Si un contenu est visible mais ignoré par les technologies d’assistance, les utilisateurs de ces technologies d’assistance ne pourront pas prendre connaissance du contenu ni interagir avec les éventuels éléments interactifs qu’ils pourraient contenir. La visibilité d’un contenu doit donc être cohérente pour tous les utilisateurs du site, qu’ils utilisent ou non une technologie d’assistance.
Exemples de problèmes détectés sur la page 1
Certains éléments marqués aria-hidden="true" sont inaccessibles aux technologies d’assistance mais contiennent des éléments interactifs focalisables au clavier (ex: le bouton avec tabindex="0" dans <li aria-hidden="true">). Ces éléments doivent se voir assigner un attribut tabindex="-1" ou être retirés du DOM.
Cas rencontré : information donnée par la forme, la taille ou la position
Ce type d’information est un problème pour les personnes aveugles et grands malvoyants. Pour chaque information véhiculée par la forme, la taille ou la position, il est nécessaire de mettre en place une alternative.
Exemples de problèmes détectés sur la page 1
La puce active du carrousel dispose bien d'un attribut visuel spécifique mais doit également comporter un attribut aria-selected="true".
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 pas être rendus visibles ni parcourus au clavier.
Thématique "formulaires"
FormulairesRecommandations 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é : 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 type de données attendu dans le champ « e-mail » n’est pas précisé, et cela ni dans l’étiquette, ni dans le message d’erreur. Il est nécessaire de donner un exemple.
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=bannerpour l’entête,role=navigationpour le menu de navigation,role=mainpour la zone de contenu principale,role=contentinfopour le pied de page,role=searchpour le moteur de recherche.
Exemples de problèmes détectés sur la page 1
Les zones d’entête, de navigation principale, de contenu principal et de pied de page 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", "contentinfo". (Ces rôles ne sont pas appliqués.)
Cas rencontré : liens d’accès rapide
Les liens d’accès rapide sont des liens présents en début de page et permettent aux utilisateurs qui naviguent au clavier et aux utilisateurs malvoyants qui utilisent une loupe d’écran d’éviter des zones de contenus redondants comme l’entête et la navigation. Il est indispensable d’avoir au moins un lien d’accès rapide vers la zone de contenu principale (<main>). Ces liens peuvent être positionnés hors écran et apparaître à la prise de focus.
Exemples de problèmes détectés sur la page 1
Aucun lien d’accès rapide n’est présent dans la page ou le lien d’accès rapide ne fonctionne pas (l’accès rapide ne permet pas d’atteindre directement le contenu principal).
Cas rencontré : contenus additionnels
Un exemple de contenu additionnel apparaissant au survol ou à la prise de focus est une infobulle personnalisée proposant dans son contenu un élément interactif (ex : un lien). Les utilisateurs aveugles et les personnes avec un handicap moteur doivent pouvoir accéder à ces contenus en navigant au clavier.
Exemples de problèmes détectés sur la page 1
Les contenus additionnels apparaissant au survol, à la prise de focus ou à l’activation d’un composant d’interface doivent être atteignables au clavier. Exemple : les sous-menus de la navigation principale ne sont pas accessibles au clavier.