Audit d'accessibilité simplifié - www.niederanven.lu

Thématique "images"

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 bitmap, son attribut alt doit être vide. Pour une image vectorielle SVG, celle-ci doit avoir l’attribut aria-hidden="true".

Exemple de problème détecté sur la page P01

L'image de décoration macommune.lu ne dispose pas d'un attribut alt vide.

Thématique "cadres"

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.

Exemple de problème détecté sur la page P03

La plupart des vidéos Vimeo dans la page sont dans un élément <iframe> qui n'a pas d'attribut title renseigné.

Thématique "couleurs"

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

Exemple de problème détecté sur la page P01

Un article du premier menu sélectionné n'affiche qu'un changement de couleur (ex : Aktualitéit). Absence de l'attribut aria-current="page" sur l'article actif, ou de l'attribut aria-selected="true" sur l'onglet actif.

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 « style switcher ». 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 « style switcher » est disponible sur le site sncf.com, dans son menu « Accessibilité ».

Exemple de problème détecté sur la page P01

Certains textes sur cette page n’ont pas un contraste suffisant (p. ex. les articles de la première barre de menus (3.23:1 contre 4.5:1 attendu au minimum ; certains textes affichés sur les images tels "Primes élèves / étudiants" (3.17:1 contre 4.5:1 attendu au minimum) ; les dates (3.23:1 contre 4.5:1 min) ; les textes en blanc sur fond orange en pied de page (2.43:1 contre 4.5:1 attendu au minimum)).

Thématique "multimédia"

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.

Exemple de problème détecté sur la page P03

Les vidéos ne sont accompagnées 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.

Exemple de problème détecté sur la page P03

Trois vidéos ne disposent d'aucun sous-titre.

Thématique "liens"

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 le 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 bitmap, 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’attribut role="img" et l’intitulé du lien pourra être fourni via les attributs aria-label ou aria-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.)

Exemple de problème détecté sur la page P01

Plusieurs liens images n'ont pas d'intitulé (réseaux sociaux, flèches des carrousels, liens images sous "Aktualitéit", lien vers la page d'accueil "Gemeng Nidderaanwen").

Thématique "scripts"

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 »). 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.

Exemple de problème détecté sur la page P01

Les onglets doivent pouvoir être activés aussi avec la touche espace; le système ne respecte pas le design pattern ARIA "tabs" https://www.w3.org/WAI/ARIA/apg/patterns/tabpanel/.

Thématique "éléments obligatoires"

Cas rencontré : validité du code source de la page

Les lecteurs d’écran s’appuient sur la sémantique des balises HTML pour restituer le contenu et naviguer, si la syntaxe HTML n’est pas respectée ou si les balises sont détournées, cela peut avoir un impact sur la navigation qui peut devenir inopérante et la restitution qui peut devenir incompréhensible. Pour vérifier la validité de la syntaxe HTML, on peut utiliser le validateur HTML du W3C avec le bookmarklet « WCAG 2.1 parsing error ». Ce bookmarklet filtre les résultats et ne montre que les erreurs ayant un impact sur l’accessibilité.

Exemple de problème détecté sur la page P01

Vérifier que les éléments <li> sont utilisés sémantiquement

Documentation : https://dequeuniversity.com/rules/axe/4.3/listitem?application=webdriverjs&lang=fr

Occurrences :

• Corriger l’un des éléments suivants : L’item de liste n’a pas d’élément <ul> ou <ol> parent (Ex : .news-slider__list > li)

  Vérifiez que le code html de la page est valide

Validateur : https://validator.w3.org/nu/

Occurrences :

• L'élément "li" n'est pas autorisé comme enfant de l'élément "div".

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.

Exemple de problème détecté sur la page P01

L’élément <html> n’a pas d’attribut lang.

Thématique "structuration de l'information"

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

Exemple de problème détecté sur la page P01

Les items de la rubrique "Aktualitéit" (ou Agenda ou Raider) sont présentés comme liés à Ruffbus Syrdall.

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

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

Exemple de problème détecté sur la page P01

Dans de nombreux éléments de cette page (les éléments de carrousel invisibles, le sujet de Une ("Replay vum Gemengerot vum 14. Oktober 2022", etc.), 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.

Exemple de problème détecté sur la page P01

Les sous-menus devraient être accessibles aux technologies d'assistance.

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: tooltips, 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.

Exemple de problème détecté sur la page P01

Les sous-menus ne peuvent être affichés via le clavier.

Thématique "formulaires"

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

Exemple de problème détecté sur la page P01

L'étiquette du champ de recherche ne lui est pas correctement associée. De plus elle n'est pas 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.

Exemple de problème détecté sur la page P02

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"

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.

Exemple de problème détecté sur la page P01

La page ne contient aucun rôle ARIA de type "banner", "main", "contentinfo".

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.

Exemple de problème détecté sur la page P01

Présent, mais inopérant.

Cas rencontré : contenus additionnels

Un exemple de contenu additionnel apparaissant au survol ou à la prise de focus est une tooltip 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.

Exemple de problème détecté sur la page P01

Les sous-menus ne sont pas accessibles au clavier.