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 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 :

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 manquante. Celle-ci est obligatoire d’après l’article 5 de la loi du 28 mai 2019. Cette déclaration s’effectue après avoir réalisé un audit de conformité basé sur le RGAA. Pour créer une déclaration sur base des résultats d’un audit de conformité, le formulaire disponible à cet effet sur accessibilite.public.lu peut être utilisé. Une fois la déclaration d’accessibilité publiée, l’éditeur du site a 30 jours pour en informer le SIP par e-mail à l’adresse accessibilite@sip.etat.lu.

Annexe technique

Thématique "images"

Images

Recommandations 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

Les images du carrousel sont purement illustratives, mais comme elles sont liées à un composant interactif (les flèches), il est pertinent que ces images soient dotées d'un attribut alt qui ait comme valeur, par exemple, "image 1", "image 2", etc. de telle sorte que, grâce à la vocalisation du lecteur d'écran, l'internaute en situation de handicap ait une idée de l'endroit où il se trouve dans le carrousel.

Cas rencontré : images porteuses d’information complexes

Certaines images porteuses d’informations sont particulièrement complexes, par exemple lorsqu’elles présentent des graphiques, schémas, cartes, etc. Dans ce cas, ces images nécessitent une description détaillée adjacente à l’image afin de permettre aux personnes aveugles et dyslexiques d’accéder à toutes les informations véhiculées par l’image. Pour mettre à disposition cette description détaillée, plusieurs solutions sont possibles. Le texte peut être adjacent à l’image dans la même page ou on peut placer un lien adjacent à l’image qui mène à une page où se trouve la description. Le texte peut aussi être inclus dans un composant permettant de le masquer et de l’afficher sur demande, au clic d’un bouton « afficher la description de l’image » (via le motif de conception ARIA « disclosure »).

Exemples de problèmes détectés sur la page 2

L'image présentant le quai d'accostage ne dispose d'aucune description détaillée. La description détaillée d’une image porteuse d’information complexe ne doit pas être fournie dans l’attribut alt de l’image, mais elle doit être présente dans un bloc de texte adjacent à l’image et de manière structurée via l’utilisation de titres, de listes, etc. Toute l’information véhiculée par l’image complexe doit être présente dans la description détaillée. Lorsqu’une description détaillée est présente, l’alternative textuelle de l’image (attribut alt) doit contenir le titre de cette image et une référence à la description détaillée (par exemple : "voir la description détaillée de cette image ci-dessous").

Thématique "couleurs"

Couleurs

Recommandations 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

Dans le menu de navigation, l’information de l’élément actif 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-current="page". 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 RGAA 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 sncf.com, 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. la couleur de l'élément actif dans le menu de navigation : contraste de couleur constaté 4.2:1 ; contraste attendu : 4.5:1).

Thématique "multimédia"

Multimédia

Recommandations 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 3

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 3

Il doit y avoir au moins une piste de sous-titres dans la langue dans laquelle les personnes filmées s'expriment.

Thématique "tableaux"

Tableaux

Recommandations 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 2

Les en-têtes de lignes ne sont pas déclarés.

Thématique "liens"

Liens

Recommandations générales

Utiliser des intitulés de liens explicites, grâce à des informations de contexte notamment.

Cas rencontré : pertinence des intitulés

Chacun doit pouvoir comprendre aisément la fonction et la destination de chaque lien. Les problèmes rencontrés ici le sont pour les aveugles, les malvoyants, les handicapés moteurs qui naviguent à la voix et les handicapés cognitifs.

Exemples de problèmes détectés sur la page 1

Le lien image du logo "Service de la navogation fluviale" a comme valeur de l'attribut alt un texte qui ne reprend pas l'intégralité du texte visible sur l'image.

Thématique "scripts"

Scripts

Recommandations 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 scripts ne respectent pas les motifs de conception ARIA. Exemple le carrousel (https://www.w3.org/WAI/ARIA/apg/patterns/carousel/) où le focus est perdu à chaque action sur l'une des flèches, ou le menu (https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/) qui ne peut rendre les sous-menus accessibles au clavier.

Thématique "éléments obligatoires"

Éléments obligatoires

Recommandations 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 « Deutsch »).

Cas rencontré : titre de page

Le titre de page est la première information restituée aux aveugles et grands malvoyants, elle leur permet de confirmer que le lien sur lequel ils viennent de cliquer les a bien menés au bon endroit, il permet aussi de retrouver une page dans l’historique, les favoris ou les onglets ouverts. Tout changement significatif de l’état de la page doit être repris dans le titre de la page (pagination, erreur, étape d’un workflow, etc.).

Exemples de problèmes détectés sur la page 1

Le titre "Home" est trop générique et peut créer de la confusion, par exemple dans l’historique du navigateur.

Thématique "structuration de l'information"

Structuration de l'information

Recommandations générales

Utiliser des titres, des listes, et des citations pour structurer l’information. S’assurer que la structure du document est cohérente.

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 1

Les zones de navigation principale et de contenu principal ne sont pas structurées par les balises html5 correspondant à leur fonction (<main>, <nav>).

Thématique "présentation de l'information"

Présentation de l'information

Recommandations 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.

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

Le lien de langue active est précisé par un rectangle gris. Il est nécessaire de donner cette information par d’autres moyens, notamment via l’attribut aria-selected="true". Ceci permettra aux personnes aveugles et malvoyantes de se repérer dans le module.

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 du menu de navigation apparaissent via des styles CSS uniquement, ils ne peuvent être rendus visibles au clavier.

Navigation

Recommandations 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 contenu principal, 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" 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é : 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 infobulles des drapeaux de langues ne sont pas atteignables au clavier.