Audit d'accessibilité simplifié

Fiche signalétique

Site: logo.public.lu

Date de l’évaluation : 29 septembre 2020

Échantillon de pages :

Méthode d'évaluation : Méthode de contrôle simplifiée de l’accessibilité pour le Luxembourg – v1

Référentiel : RGAA v4

Avertissement

Attention, l’audit effectué est 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 RGAA 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. N’hésitez pas à vérifier de manière exhaustive l’accessibilité de votre site conformément au référentiel RGAA v4.

Résumé

Le site est partiellement accessible. Pour les rédacteurs, les principaux problèmes sont liés aux alternatives d’images et à la structuration des tableaux. Pour les développeurs, les principaux problèmes sont liés à la navigation en général et à la navigation au clavier en particulier.

Problèmes d’accessibilité par critère

Critère 1.6 : Chaque image porteuse d'information a-t-elle, si nécessaire, une description détaillée ?

Sur ce site, nous avons fréquemment des images porteuses d’information. Celles-ci doivent avoir une alternative textuelle renseignée, mais aussi une description détaillée juste en dessous.

Par exemple sur la page https://logo.public.lu/fr/elements-base/couleur-identite-visuelle.html l’image principale pourrait avoir pour alternative « couleurs du logotype, voir description ci-dessous ».

Et en dessous de l’image, il est nécessaire d’avoir un texte explicatif. Par exemple pour la même page nous pourrions proposer l’explication suivante :

« Les couleurs du logotype sont les suivantes :

Ces descriptions détaillées d’images peuvent éventuellement être dans une boite « plus d’informations » qui est fermée par défaut et s’ouvre au clic.

Ces informations sont nécessaires pour les personnes non-voyantes.

Une page sur laquelle la description détaillée est ok est celle-ci : https://logo.public.lu/fr/elements-base/element-image-marque/lion-trame.html

Toutes les informations de l’images sont reprises dans la description détaillée. Il manque cependant une alternative textuelle sur l’image.

Critère 5.6 : Pour chaque tableau de données, chaque en-tête de colonnes et chaque en-tête de lignes sont-ils correctement déclarés ?

Dans certains tableaux, l’entête de la première colonne est vide. Soit la première colonne constitue aussi des entêtes de lignes (<th scope=row>), soit il est nécessaire de renseigner l’entête de la première colonne.

Occurence :

Sur la page https://logo.public.lu/fr/elements-base/logotype/construction.html nous avons un tableau dont la première colonne a une entête vide.

Les entêtes de tableaux permettent aux personnes aveugles et malvoyantes de se repérer dans un tableau. Il faut s’imaginer que ces utilisateurs se déplacent cellule par cellule dans un tableau. Chaque cellule doit être techniquement reliée à des entêtes pour qu’il puissent comprendre le contexte de chaque cellule.

Critère 7.1 : Chaque script est-il, si nécessaire, compatible avec les technologies d'assistance ?

Deux patterns utilisés dans ces pages ne sont pas compatibles avec les technologies d’assistance :

Ces points sont importants car ils permettent aux aveugles et handicapés moteurs de naviguer correctement dans la page en utilisant un clavier.

Critère 7.3 : Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage (hors cas particuliers) ?

Certaines parties de la page sont cachées par défaut et s’affichent à l’appui d’un bouton, par exemple le menu mobile ou la boîte de recherche. Les scripts qui gèrent ces affichages doivent respecter le design pattern « disclosure ». En particulier, lorsque la boîte est ouverte, le focus doit être placé sur le premier élément interactif. Dans le cas présent il n’est par exemple pas évident au clavier d’entrer dans la boite de recherche une fois cette boîte ouverte (possible après 8 tabulations).

Ces points sont importants car ils permettent aux aveugles et handicapés moteurs de naviguer correctement dans la page en utilisant un clavier.

Critère 9.3 : Dans chaque page web, chaque liste est-elle correctement structurée ?

Sur chaque page, les liens d’évitement ne sont pas structurés sous forme de liste.

Les listes permettent de structurer un ensemble de liens et de naviguer plus facilement dans ces liens (fonctionnalités des technologies d’assistances spécifiques pour les listes)

Critère 11.13 : La finalité d'un champ de saisie peut-elle être déduite pour faciliter le remplissage automatique des champs avec les données de l'utilisateur ?

Dans le formulaire de contact, les champs nom, prénom, email, téléphone et pays ne peuvent être préremplis automatiquement par le navigateur. Il est nécessaire d’ajouter des attributs « autocomplete » pertinents sur ces champs.

Les personnes en situation de handicap qui ont des difficultés à saisir des informations au clavier utilisent l’autocomplétion pour saisir leurs informations personnelles.

Critère 12.3 : La page « plan du site » est-elle pertinente ?

La page « plan du site » affiche des liens vers des pages techniques, notamment « confirmation » et « mail reçu ». Ces liens sont à supprimer du plan du site.

Critère 12.6 : Les zones de regroupement de contenus présentes dans plusieurs pages web (zones d'en-tête, de navigation principale, de contenu principal, de pied de page et de moteur de recherche) peuvent-elles être atteintes ou évitées ?

La navigation principale n’a pas de rôle « navigation ». Il est nécessaire d’ajouter ce rôle « navigation » sur cette navigation.

Les utilisateurs aveugles utilisent des fonctionnalités de leur technologie d’assistance pour naviguer plus rapidement dans les différentes zones d’une page. Ici, ils ne pourront pas atteindre facilement la navigation principale.