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 - Kultur | lx - Arts Council Luxembourg
- Page 2 : Contacts - Kultur | lx
- Page 3 : Nos actions - Kultur | lx
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.
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 1
Plusieurs images porteuses d’information n’ont pas d’alternative textuelle. Exemple en pied de page : les logos partenaires et même l’image « KulturLX » ont un attribut alt
vide.
Thématique "couleurs"
CouleursRecommandations générales
Ne pas donner l’information uniquement par la couleur et utiliser des contrastes de couleurs suffisamment élevés pour les textes, les composants d’interface ou les éléments porteurs d’informations.
Cas rencontré : informations données uniquement par la couleur
Ce type d’information est un problème pour les personnes déficientes visuelles, aveugles ou par exemple les personnes qui ne voient pas certaines couleurs ou ne perçoivent simplement pas les couleurs. Pour chaque information véhiculée par la couleur, il est nécessaire de mettre en place une alternative, comme par exemple un changement de style (graisse du texte, taille du texte, soulignement, etc.)
Exemples de problèmes détectés sur la page 1
L’indication de langue active est donnée uniquement par la couleur. Il est nécessaire de donner cette information par d’autres moyens, notamment via une modification du style (taille du texte, graisse, soulignement, bordure, ...) ainsi que via l’attribut aria-selected="true"
. Ceci permettra aux personnes aveugles et malvoyantes de se repérer dans le menu de navigation.
Cas rencontré : contrastes des textes
Les contrastes de couleurs sont importants pour plusieurs types de déficiences visuelles comme celles des grands malvoyants ou des personnes ayant des problèmes de perception des couleurs. Les contrastes minimaux d’un texte sur le fond de page sont définis par le RAWeb comme suit :
- Pour un texte sans effet de graisse
- De taille inférieure à 24 px : le contraste minimum est de 4.5:1 ;
- De taille supérieure ou égale à 24 px : le contraste minimum est de 3:1.
- Pour un texte en gras
- De taille inférieure à 18.5 px : le contraste minimum est de 4.5:1 ;
- De taille supérieure à 18.5 px : le contraste minimum est de 3:1.
Pour vérifier les contrastes, on peut utiliser un outil tel que « Colour Contrast Analyser ». Si les problèmes de contraste ne peuvent être résolus simplement, il est aussi possible d’utiliser un sélecteur de styles. C’est une fonctionnalité proposée par le site qui permet de renforcer les contrastes pour les personnes qui ont des problèmes avec les couleurs. Un exemple de sélecteur de styles est disponible sur le site guichet.lu, dans son menu « Accessibilité ».
Exemples de problèmes détectés sur la page 1
Certains textes sur cette page n’ont pas un contraste suffisant (p. ex. les dates ou les langues non actives : contraste de couleur constaté 2.61:1 ; contraste de couleur attendu : 4.5:1).
Thématique "multimédia"
MultimédiaRecommandations générales
Donner à chaque média temporel audio et/ou vidéo une transcription textuelle, des sous-titres ou une audiodescription pertinents lorsque cela est nécessaire. Donner à chaque contenu graphique ou interactif (ou média non temporel) une alternative textuelle pertinente. Rendre possible le contrôle de leur consultation et leur manipulation au clavier et avec tout dispositif de pointage comme la souris. S’assurer de leur compatibilité avec les technologies d’assistance.
Cas rencontré : transcription textuelle et audiodescription
Si une vidéo possède des textes incrustés ou des informations sonores (ex : personnes qui parlent sur la piste sonore) alors il est nécessaire de fournir une transcription textuelle. De même pour un média audio seulement qui est porteur d’information (ex : podcast), une transcription textuelle est nécessaire. L’absence de transcription textuelle sur de tels médias va empêcher l’accès à l’information à de nombreux utilisateurs comme les aveugles, les malvoyants, les sourds, les malentendants, les handicapés moteurs et cognitifs. Une transcription textuelle présente de manière structurée toutes les informations visuelles et sonores de la vidéo dans l’ordre chronologique de leur apparition. Celle-ci peut-être présente sur la même page que la vidéo en question ou derrière un lien adjacent à la vidéo.
Par ailleurs, si une vidéo possède des informations importantes véhiculées uniquement par l’image (ex : textes incrustés), il est nécessaire de fournir une audiodescription synchronisée. Il s’agit d’une piste sonore supplémentaire qui s’ajoute à la piste sonore principale et décrit les éléments visuels importants qui ne peuvent être compris à partir de la poste sonore principale. Ces descriptions sont réalisées dans les blancs de la piste sonore principale.
Exemples de problèmes détectés sur la page 1
La vidéo n’est accompagnée d’aucune transcription textuelle ou audiodescription.
Cas rencontré : sous-titres
Les vidéos sur ce site doivent avoir des sous-titres. Il existe deux types de sous-titres : les sous-titres de traduction et les sous-titres pour sourds et malentendants. Il est nécessaire de fournir ici des sous-titres pour sourds et malentendants. Ceux-ci doivent notamment fournir en plus des dialogues toutes les informations sur les éléments sonores nécessaires pour comprendre l’action. Les sous-titres doivent être correctement synchronisés avec la vidéo.
Exemples de problèmes détectés sur la page 1
Aucune piste de sous-titres n’a pu être trouvée pour cet élément.
Cas rencontré : contrôle des lecteurs vidéo au clavier
La consultation de chaque vidéo doit être contrôlable par le clavier et tout dispositif de pointage. Cela permet aux personnes ayant un handicap moteur d’accéder à ces contenus. Si les vidéos présentes sur le site sont dérogées car publiées avant le 23 septembre 2020, cette dérogation ne s’applique pas au lecteur vidéo lui-même. Celui-ci se doit d’être accessible quelle que soit la date de publication de la vidéo.
Exemples de problèmes détectés sur la page 1
La vidéo n’est pas pilotable au clavier.
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
alt
doit 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-label
ouaria-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
Les liens images du retour à l’accueil ou des réseaux sociaux n’ont pas d’intitulé accessible.
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
Plusieurs éléments ne répondent pas aux motifs de conception ARIA. Exemple : le bouton permettant d’afficher le burger menu n’est pas un bouton et ne peut être atteint au clavier. Le burger menu ne répond pas au motif de conception Disclosure.
Thématique "éléments obligatoires"
Éléments obligatoiresRecommandations 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 « Dance from Luxembourg »).
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.
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é : intitulés de boutons pertinents
Les boutons doivent avoir des intitulés pertinents, qui communiquent l’action réalisée à l’activation. Ces informations sont particulièrement importantes pour les déficients visuels et cognitifs.
Exemples de problèmes détectés sur la page 1
Le bouton de soumission de la recherche n’a pas d’intitulé accessible.
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=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 d’entête, de navigation principale, 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", "contentinfo" ou "navigation".
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.
Cas rencontré : ordre de tabulation
L’ordre de tabulation, c’est-à-dire l’ordre dans lequel le focus se déplace lorsqu’on utilise les touches tab et shift-tab, doit être cohérent. Si l’ordre de tabulation est incohérent, les aveugles, les déficients visuels, les handicapés moteurs et handicapés cognitifs auront de grandes difficultés à naviguer dans la page.
Exemples de problèmes détectés sur la page 1
L’ordre de tabulation n’est pas cohérent. Exemple : les éléments de la boîte cookies ne doivent pas figurer parmi les derniers à recevoir le focus.
Thématique "consultation"
ConsultationRecommandations générales
S’assurer que l’utilisateur a le contrôle des actions imposées après un certain délai notamment les procédés de rafraîchissement. Donner la possibilité de contrôler les changements brusques de luminosité, les ouvertures de nouvelles fenêtres et les contenus en mouvement ou clignotants. S’assurer que les expressions inhabituelles et le jargon sont explicités. Proposer des versions accessibles des documents en téléchargement ou les rendre accessibles. S’assurer que le contenu puisse être consulté quelle que soit l’orientation de l’écran et au moyen de gestes simples. Permettre d’annuler les actions déclenchées par un mouvement et d’accéder aux mêmes fonctionnalités par une alternative, sans mouvement.
Cas rencontré : contenus en mouvement ou clignotants
Ces contenus posent problème aux utilisateurs avec des difficultés de lecture ou des troubles de l’attention. Les utilisateurs doivent avoir la possibilité de mettre le mouvement en pause, ou de masquer le contenu en mouvement.
Exemples de problèmes détectés sur la page 1
La vidéo ne peut être arrêtée. La présence d’un bouton « pause » est ici indispensable. Idem pour l’agenda en mode carrousel.