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 :
- Page 1 : Les meilleurs cours de langue du Luxembourg à votre portée
- Page 2 : Contact - INL
- Page 3 : Consultez les prochains événements de l'INL
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 "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é : 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. Quelques exemples : le titre "Vos premeirs pas vers des échanges enrichissants" doit avoir un contraste minimum de 3:1 avec l'image d'arrière-plan. Or, sur les parties les plus claires de l'image, le contraste n'est plus que de 2:1. Les éléments "Cours", "Certifications", "Sproochentest", etc. : contraste de 4.04:1 contre 4.5:1 attendu. Les dates dans la section "Nos dernières actualités" : contraste de 1.84:1 contre 4.5:1 attendu. Le texte du bouton "Ok" de la boîte cookies a un contraste de 2.93:1 avec la couleur verte d'arrière-plan contre 4.5:1 attendu.
Thématique "tableaux"
TableauxRecommandations 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 3
Les jours de semaine sont bien dans des éléments <th>
mais eux-mêmes dans un sous-tableau du tableau principal, ce qui ne permet pas de faire le lien avec chaque cellule.
Thématique "liens"
LiensCas 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
Dans le footer le lien sur le logo "Institut national des Langues" a pour intitulé "logo footer", cet intitulé n'est pas pertinent.
Cas 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 des réseaux sociaux n'ont pas d'intitulé.
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 bouton pour afficher la recherche n'est pas activable au clavier avec la la barre d’espace. Il doit être implémenté avec l'élément <button>
ou respecter le design pattern ARIA button. https://www.w3.org/WAI/ARIA/apg/patterns/button/ (un bouton exécute une action dans la page tandis qu'un lien permet d'aller sur une autre page). Idem pour le bouton "fermer" dans la fenêtre de recherche.
En mode mobile, le burger menu n'est pas accessible au clavier. Il en est de même pour la croix de fermeture. Il s'agit d'un élément <input type="checkbox"> caché, ne pouvant en conséquence pas recevoir le focus.
La modale présentant le menu de navigation doit circonscrire la tabulation à ses éléments.
Les flèches du carrousel doivent pouvoir réagir aussi à la barre d’espace.
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 (p. ex. "Sproochentest").
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
Le titre "Membres de:" est un titre de niveau 3, hiérarchiquement sous le titre "Centre d'échange et de rencontre" de niveau 2. Il n'y a cependant pas de relation entre ces titres. Le titre "Membres de" devrait être un titre de niveau 2.
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, de pied de page et de contenu principal ne sont pas structurées par les balises html5 correspondant à leur fonction (<nav>
, <footer>
, <main>
.)
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.
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 2
Tous les messages d'erreur ont l'attribut aria-hidden="true"
ce qui empêche la restitution de ces informations par les lecteurs d'écrans.
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é : identification des champs, des contrôles et des regroupements de formulaires
L’identification de ces éléments fournit aux aveugles et grands malvoyants les informations nécessaires pour pouvoir remplir un formulaire. Les handicapés moteurs utilisant un système de reconnaissance vocale s’appuient aussi sur ces éléments pour se déplacer dans les différents champs et actionner les boutons. Pour associer une étiquette (<label>
) à un champ de formulaire on peut utiliser l’attribut for
de l’étiquette dont la valeur doit être identique à celle de l’attribut id
du champ. Les champs de même nature doivent être regroupés, cela peut être réalisé via l’élément <fieldset>
auquel on doit fournir une légende via l’élément <legend>
.
Exemples de problèmes détectés sur la page 1
Le champ de recherche n'a pas d'intitulé visible. Un placeholder n’est ici pas suffisant, car il ne sera plus visible une fois que l’utilisateur aura commencé à remplir le champ. Une solution peut être de placer un attribut title
sur le champ, qui contient le contenu de l’étiquette. Ce contenu sera visible au "hover", même pendant la saisie.
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. Par ailleurs, la signification de l'astérisque doit être indiquée en amont du premier champ.
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
La page ne contient aucun rôle ARIA de type "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é : 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
Les éléments de la boîte cookies ne doivent pas être les derniers à recevoir le focus. Il faut dix tabulations entre l'activation de la loupe et l'accès au champ de recherche.