RAPPORT D'AUDIT D'ACCESSIBILITE CHORUS PRO - Communauté Chorus Pro
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
access42.net
21bis rue du Simplon
bonjour@access42.net
75018 Paris
09 72 45 06 14
RAPPORT D’AUDIT D’ACCESSIBILITE
CHORUS PRO
19/11/2019
Rapport d'audit RGAA 3 1/31
Table des matières
INTRODUCTION ..................................................................................................... 3
Contexte ............................................................................................................. 3
Échantillon .......................................................................................................... 3
Accessibilité des pages auditées ........................................................................ 4
Conformité RGAA 3 du site ............................................................................. 4
Impacts utilisateurs ...................................................................................... 4
Note sur le relevé des non-conformités ............................................................. 5
Dérogations ................................................................................................. 5
Avis de l’inspectrice ............................................................................................ 5
Priorisation des réparations ............................................................................... 5
ANNEXE TECHNIQUE ............................................................................................. 7
Images ................................................................................................................ 7
Constats et préconisations de correction ........................................................... 7
Couleurs .............................................................................................................. 8
Constats et préconisations de correction ........................................................... 8
Ressources .................................................................................................. 9
Liens ................................................................................................................. 10
Constats et préconisations de correction .......................................................... 10
Ressources ................................................................................................. 11
Scripts ............................................................................................................... 11
Éléments obligatoires ....................................................................................... 11
Constats et préconisations de correction .......................................................... 11
Ressources ................................................................................................. 13
Structuration de l’information .......................................................................... 14
Constats et préconisations de correction .......................................................... 14
Présentation de l’information ........................................................................... 16
Constats et préconisations de correction .......................................................... 17
Ressources ................................................................................................. 20
Formulaires....................................................................................................... 21
Constats et préconisations de correction .......................................................... 21
Navigation ........................................................................................................ 23
Constats et préconisations de correction .......................................................... 23
Consultation ..................................................................................................... 24
Constats et préconisations de correction .......................................................... 24
Note technique - Structuration HTML5 et landmarks ARIA.............................. 25
En-tête de la page ....................................................................................... 25
Navigations ................................................................................................ 25
Contenu principal ........................................................................................ 26
Pied de page ............................................................................................... 26
Note technique – Formulaires .......................................................................... 27
Étiquettes et champs.................................................................................... 27
Contrôle de saisie et aide à la saisie ................................................................ 29
Regroupements de champs et légendes ........................................................... 30
Ressources ................................................................................................. 31
Rapport d'audit RGAA 3 2/31Introduction
Contexte
Ce rapport accompagne le relevé d’audit effectué sur le site « Chorus Pro ». En complément, une
note technique détaille les corrections à effectuer sur la partie JavaScript.
La méthodologie d’audit employée repose sur le référentiel français RGAA 3.0 2017, consultable à
l’adresse suivante : http://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html.
L’audit a été réalisé par Luce Carević au moyen de l’utilisation de navigateurs web et d’outils
spécialisés. Des tests de restitution ont également été effectués conformément à la base de
référence définie par le RGAA 3.0 2017.
Échantillon
L’audit a porté sur un échantillon de 14 pages pour le niveau double A (AA) :
Nº
Titre de la page URL
page
P01 Accueil non connecté https://chorus-pro.gouv.fr/qualif/utilisateur?
P02 Accueil connecté https://chorus-pro.gouv.fr/qualif/accueilConnecte?
Création de compte - https://chorus-pro.gouv.fr/qualif/utilisateur?execution=e1s2
P03
Saisie nouvel utilisateur
Enregistrer et configurer https://chorus-
mon compte rattachement pro.gouv.fr/qualif/activationCompte?execution=e2s1
P04
à une structure et
validation
Mon compte gestion des https://chorus-pro.gouv.fr/qualif/gestionCompte?
P05 abonnements aux espaces
(compte Gest Four)
Factures émises : https://chorus-pro.gouv.fr/qualif/gestionFacturesEmises?
P06
Synthèse
Factures émises : https://chorus-pro.gouv.fr/qualif/rechercheFacturesEmises?
P07
Recherche de factures
Factures émises : Tableau https://chorus-pro.gouv.fr/qualif/tableauBordEmises?
P08
de bord
Factures émises : Saisir https://chorus-pro.gouv.fr/qualif/saisieFacture?
P09
Factures - cadre A1
Factures émises : Dépôt https://chorus-pro.gouv.fr/qualif/depotFacture?execution=e3s1
P10 d'une nouvelle facture
(PDF non signé)
Espace Sollicitations https://chorus-pro.gouv.fr/qualif/sollicitationsEmises?
P11 émises : Saisir une
sollicitation
Espace Sollicitations https://chorus-pro.gouv.fr/qualif/rechercheSollicitationsEmises?
P12 émises : Recherche
sollicitations émises
Rapport d'audit RGAA 3 3/31Espace Sollicitations https://chorus-pro.gouv.fr/qualif/stockSollicitationsEmises?
P13 émises : Tableau de bord
sollicitation
Mentions légales https://chorus-
P14
pro.gouv.fr/qualif/mentionsLegales?execution=e12s1
P15 Accessibilité https://chorus-pro.gouv.fr/qualif/accessibilite?execution=e8s1
En effet, la page 4 n’a pas pu être auditée. Nous mettrons à jour les résultats lorsque nous aurons
accès à ce contenu.
Accessibilité des pages auditées
Un précédent audit avait été effectué en février 2018 avec un pourcentage de conformité d’environ
33% pour le niveau AA du RGAA.
Le niveau moyen de conformité relevé atteint 48 % de conformité sur l’ensemble des pages
auditées, avec 44 % de conformité au niveau simple A (A) et 66 % de conformité au niveau double
A (AA).
L’accessibilité de l’application a été améliorée considérablement sur certains points (intitulé des
boutons, fenêtres modales) qui ont correctement corrigé.
À noter que le taux de conformité pourrait être rapidement amélioré, si certaines erreurs simples
étaient corrigées.
Il reste néanmoins des problématiques importantes qui n’ont pas du tout été prises en compte.
Conformité RGAA 3 du site
Note sur le calcul de conformité
La conformité globale (Tableau « Conformité RGAA 3 ») est calculée de la manière suivante : C /
(C+NC). C est le nombre de critères conformes et NC le nombre de critères non conformes.
C’est ce nombre qui constitue la référence légale. Il représente le taux de conformité de
l’échantillon.
Il est normal que le taux de conformité global diffère sensiblement du taux de conformité par page.
En effet, un critère NC (non conforme) sur une page rend le critère non conforme sur l’ensemble de
l’échantillon.
Pour qu’un site soit conforme (100 % des critères applicables sont conformes au niveau AA), il est
nécessaire que le taux de conformité par page équivaille à 100 %.
Impacts utilisateurs
Les principales personnes impactées sont les personnes aveugles et déficientes visuelles ainsi que
celles qui naviguent au clavier.
Les non-conformités les plus bloquantes pour les utilisateurs concernent :
• les scripts ;
• le manque de structuration HTML5 et l’absence de lien d’accès rapide fortement pénalisant
pour les personnes qui naviguent au clavier puisque l’application repose sur des
rechargements de page réguliers ;
• les formulaires : étiquettes non accolées notamment.
Rapport d'audit RGAA 3 4/31Ce sont donc ces points qui devront nécessiter une attention toute particulière et qui
demanderont le plus d’efforts.
Note sur le relevé des non-conformités
Ne sont cités dans ce rapport que quelques exemples issus du relevé des non-conformités (tableau
joint). Nous vous renvoyons donc au relevé pour prendre connaissance des autres cas.
De plus, toutes les occurrences d’une non-conformité ne sont pas listées dans le relevé. Par
exemple : pour les étiquettes de champs de formulaire, le relevé mentionne quelques occurrences,
mais ne les cite pas tous.
Toutes les erreurs relevées doivent donc être accompagnées, en phase de correction, d’une
vérification attentive afin de détecter toutes les occurrences d’une non-conformité sur chaque
page.
Dérogations
On trouve de nombreux boutons qui devraient en fait être des liens. Compte tenu de l’impact faible
pour l’utilisateur dans un contexte applicatif comme Chorus Pro, l’inspection propose une
dérogation pour charge déraisonnable.
La reprise de contenu qu’il faudrait effectuer nous semble fort importante et non prioritaire face au
chantier restant.
D’autres dérogations pourraient être établies suite à la réunion de restitution à venir.
Avis de l’inspectrice
Le travail de correction a sans conteste été important et a en partie porté ses fruits.
Néanmoins, on constate que toutes les corrections n’ont pas été effectuées correctement et que
certaines n’ont pas toujours été bien comprises.
Sur certains écrans, on constate également que toutes les occurrences d’une même problématique
n’ont pas toujours été corrigées.
L’application peut parfois être complexe et un accompagnement des équipes techniques semble
indispensable pour atteindre la conformité et rendre l’application accessible aux utilisateurs
handicapés.
Il est également indispensable que les équipes appliquent bien les correctifs sur toute l’application
et les différents parcours qui sont hors échantillon.
Priorisation des réparations
Vous pouvez prioriser les corrections à effectuer selon 3 axes.
• Selon les fonctionnalités et contenus essentiels du site : si votre site a pour vocation de
donner accès à un compte utilisateur, il est impératif pour vos visiteurs de pouvoir réaliser
prioritairement cette action sans entrave, quels que soient les critères du RGAA impactés.
• Selon les niveaux de conformité. Le RGAA applique les 3 niveaux de conformité des
WCAG 2 : simple A (A), double A (AA) et triple A (AAA). En plus de ces niveaux qui donnent
en soi une indication de priorisation, vous pouvez vous appuyer sur la liste des 50 critères de
niveau 1 (niveau inférieur au niveau simple A), qui représentent le premier niveau
d’accessibilité du label e-accessible.
• Selon la facilité d’implémentation : certaines corrections sont extrêmement simples et
donc très peu coûteuses à mettre en œuvre rapidement. Il peut être motivant pour les équipes
Rapport d'audit RGAA 3 5/31techniques de les mettre en situation de succès dans la prise en compte de l’accessibilité en
leur donnant en priorité des corrections simples à mettre en œuvre. La progression est alors
rapide et motivante.
Il est important dans tous les cas de garder en tête que les corrections doivent permettre un
meilleur accès aux personnes potentiellement exclues en raison des non-conformités relevées.
Rapport d'audit RGAA 3 6/31Annexe technique Images Recommandation : 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. Constats et préconisations de correction Images de décoration Le site contient des images de décoration avec une alternative renseignée. De même, l’image de la facture importée est une image de décoration. Ces images n’apportent aucune information et peuvent causer des problèmes de compréhension pour les aveugles et les grands malvoyants qui vont écouter les contenus avec un lecteur d’écran. Mettre un alt="". Alternative au CAPTCHA Dans le cadre du RGAA, il suffit de proposer une alternative au CAPTCHA image, par exemple un CAPTCHA sonore, pour que ce contenu soit jugé conforme. Il faut cependant garder à l’esprit que cette solution reste loin d’être parfaite, bien que conforme. Les CAPTCHAS posent toujours des problèmes d’accessibilité́, qu’importe leur conception. Toutefois, il existe des solutions moins problématiques que d’autres. L’une des meilleures solutions de CAPTCHAS actuellement reste reCAPTCHA de Google, même si cette dernière comporte également son lot de problématiques. Une alternative satisfaisante aux CAPTCHAS pour l’accessibilité́ serait une validation avec un code envoyé́ par e-mail ou SMS. Plus d’informations sur les enjeux d’accessibilité́ pour les différents types de CAPTCHAS : https://www.w3.org/TR/turingtest/. Quoi qu’il en soit, en l’état, le CAPTCHA implémenté est non conforme puisque s’il propose une alternative au CAPTCHA image, la piste audio ne se lance jamais, que ce soit sur le site de qualif ou sur la version du site en production. Rapport d'audit RGAA 3 7/31
Note : on trouve deux versions du CAPTCHA sonore sur le site de qualif. Seule la version avec le
lecteur Able player est conforme et accessible.
Couleurs
Recommandation :
Ne pas donner l’information uniquement par la couleur et utiliser des contrastes de couleurs
suffisamment élevés.
Constats et préconisations de correction
Contrastes
Un rapport de contraste insuffisant, ce qui peut poser problème aux grands malvoyants et
aux déficients visuels qui ont des difficultés à percevoir les couleurs ou les contrastes.
Sur les écrans que nous avons pu auditer sur la version en production de Chorus Pro, la
thématique est globalement correctement traitée.
Néanmoins, on trouve déjà sur la page d’accueil en mode non
connecté un gris (#7e7e7e) qui n’est pas suffisamment contrasté.
Vous pouvez corriger simplement en reprenant un autre gris utilisé
sur le site et qui respecte le ratio de contraste de 4.5 :1.
Rapports de contrastes définis par le RGAA
• Jusqu’à 150 % pour la taille de police par défaut (ou 1.5 em) sans effet de graisse et jusqu’à
120 % (ou 1.2 em) avec effet de graisse, le rapport de contraste entre la couleur du texte (y
compris le texte en image) et son arrière-plan doit être de 4.5:1, au moins.
• Plus de 150 % (ou 1.5 em) sans effet de graisse et plus de 120 % (ou 1.2 em) avec effet de
graisse, le rapport de contraste entre la couleur du texte (y compris le texte en image) et son
arrière-plan doit être de 3:1, au moins.
Contrôlez les contrastes grâce à l’extension Firefox WCAG Contrast Checker1 ou l’outil Colour
Contrast Analyser2.
Information par la couleur
Lorsqu’une information est donnée par la couleur, il faut qu’elle soit également donnée
par une autre méthode, par exemple par un texte qui donne la même information.
En effet, l’absence d’alternative à l’information donnée par la couleur représente une perte
d’information pour certains utilisateurs (aveugles, malvoyants, déficients visuels qui perçoivent
mal ou pas les couleurs…).
1 https://addons.mozilla.org/fr/firefox/addon/wcag-contrast-checker/
2 https://www.paciellogroup.com/resources/contrastanalyser/
Rapport d'audit RGAA 3 8/31Item de menu actif
Dans les menus de navigation, la page active est mise en évidence par la couleur :
Dans ce cas, ajouter un titre de lien (attribut title) sur le lien en suivant ce modèle : « Accueil
connecté page active » ou « Synthèse page active ».
Ressources
• Couleurs et Contrastes — Guide du concepteur RGAA 33
• Informations par la forme et la couleur — Guide de l’intégrateur RGAA 34
3 https://disic.github.io/guide-concepteur/6-couleurs.html
4 https://disic.github.io/guide-integrateur/10-infos-forme-couleur.html
Rapport d'audit RGAA 3 9/31Liens
Recommandation :
Donner des intitulés de lien explicites, grâce à des informations de contexte notamment, et utiliser
le titre de lien le moins possible.
Constats et préconisations de correction
Titres de liens
La restitution des titres de liens (attribut title sur une balise ) dépend fortement des lecteurs
d’écran et des préférences utilisateurs. En effet, les titres peuvent :
• Être restitué en plus de l’intitulé du lien. Pour cette raison, il ne faut utiliser le titre de
lien que s’il y a une information complémentaire à rajouter par rapport à l’intitulé
du lien ;
• Être le seul contenu restitué, à la place de l’intitulé même du lien. Pour cette raison, le
titre de lien doit toujours reprendre l’intitulé en plus d’ajouter une information
complémentaire ;
• Ne pas être restitué. Pour cette raison, le titre de lien ne peut pas jouer le rôle
d’intitulé, il vient toujours en complément de l’intitulé. À ce titre, les titres vides sur
des liens (title="") doivent être supprimés s’il y en a.
Exemple de titre de lien conforme :
Mon intitulé
Ainsi, les titres de liens dans le pied de page doivent ainsi être revus pour inclure l’intitulé du lien.
Ex. title="Notes de version – nouvelle fenêtre".
De même pour les liens vers les sollicitations. Ex. title="198516 – Consulter la sollicitation…" ou
encore certains liens (CTA).
Présence d’intitulés
Un lien doit toujours posséder un intitulé permettant à l’utilisateur de comprendre sa destination.
On trouve une occurrence de lien sans intitulé (le lien d’accès à la documentation en ligne) sur
l’échantillon : .
Le lien n’a qu’un title qui n’est pas une méthode suffisante pour fournir un intitulé à un lien.
Rapport d'audit RGAA 3 10/31Correction proposée
Pour corriger, ajouter simplement un aria-label qui peut ici être identique au title.
Note : vous pouvez raccourcir l’indication d’ouverture dans une nouvelle fenêtre en « nouvelle
fenêtre » pour alléger la restitution. « Ouverture en nouvelle fenêtre » ne constitue néanmoins pas
une non-conformité.
Ressources
• Fiche 5 : Liens — Guide de l’intégrateur RGAA 35
Scripts
Recommandation :
Donner si nécessaire à chaque script une alternative pertinente. Rendre possible le contrôle de
chaque code script au moins par le clavier et la souris et s’assurer de leur compatibilité avec les
technologies d’assistance.
Il reste un certain nombre d’erreurs à corriger sur la partie Scripts. Celle-ci est traitée dans une
note technique dédiée.
À noter que les problèmes les plus impactants ont été correctement traités (fenêtres modales
changement de contexte avec le select par exemple).
Éléments obligatoires
Recommandation :
Vérifier que chaque page web a un code source valide selon le type de document, un titre pertinent
et une indication de langue par défaut. 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.
Constats et préconisations de correction
Indication de langue
Les lecteurs d’écran utilisent les indications de langue pour vocaliser le contenu dans la langue
définie. La page doit contenir une définition de langue principale (généralement sur l’élément
html).
Correction
Si l’indication de langue est bien gérée sur le site, ce n’est pas le cas pour les fenêtres popup
(Accessibilité, Mentions légales, etc.).
5 https://disic.github.io/guide-integrateur/5-liens.html
Rapport d'audit RGAA 3 11/31Indiquer le code langue par défaut sur la balise : lang="fr".
Titre de la page
Impact utilisateur
Le titre de la page (visible dans l’onglet du navigateur) est un élément de repère dans le site web.
Pour les utilisateurs de lecteur d’écran (utilisateurs aveugles ou grands malvoyants), c’est le
premier élément restitué par le lecteur d’écran au chargement de la page.
Cela permet de donner du contexte aux utilisateurs qui n’ont pas une vision globale de la page.
Pour les utilisateurs avec des troubles de la mémoire, c’est l’information à laquelle ils accèdent
lorsqu’ils naviguent avec l’historique de navigation du navigateur. Il est donc essentiel d’avoir des
titres de pages pertinents, concis et très souvent uniques dans le site, et qui reflètent de la position
de l’utilisateur dans le site web.
Note : Il existe des cas particuliers, comme les pages dont le contenu est une liste de résultats
paginés (ex. : les résultats de recherche), pour lesquels le titre doit si possible refléter la nature
de la recherche ainsi que le numéro de page en cours de consultation.
Constat et corrections
Sur le site Chorus Pro, toutes les pages ont le même titre de page : « Bienvenue sur Chorus Pro ».
Vous devez modifier tous les titres de pages (voir le relevé pour une suggestion de titre de page
pour chaque page de l’échantillon). Un titre de page pertinent n’est pas forcément un titre
complexe. Un titre pertinent est généralement :
− unique dans un site ou une application (justement pour permettre de différencier toutes les
pages et les étapes) ;
− dans le cas de moteur de recherche, il reprend au moins la position dans la pagination
(page 1/2/3, etc.) si elle existe ;
− dans le cas de formulaire, il mentionne la présence d’erreurs si c’est le cas avec
une mention comme « erreur sur le formulaire ».
Cette problématique est particulièrement importante sur Chorus Pro en raison de la complexité de
l’application et du nombre d’écrans et d’étapes dans un parcours.
Validité du code
Impact utilisateur
Le RGAA ne requiert pas un code source valide à 100 %, mais il demande que les balises et
attributs respectent les spécifications du type de document déclaré. Sauf indication contraire, les
attributs et balises non répertoriés par les spécifications sont non applicables (par exemple des
attributs de type ng-xx et éléments custom issus des framework).
Si le code comporte des erreurs (balises mal fermées par exemple), il y a un risque que les
fonctionnalités des technologies d’assistance soient impactées, comme la navigation de liens en
liens par exemple.
Constat et corrections
Sur l’échantillon d’audit, on trouve quelques erreurs de code. Par rapport à l’audit précédent, leur
nombre a fortement diminué, ce qui est très encourageant.
Rapport d'audit RGAA 3 12/31Pour vérifier la conformité d’une page, vous pouvez utiliser le validateur mis à disposition par le
W3C6. Nous vous invitons à tester ce critère après avoir effectué l’ensemble des autres correctifs
d’accessibilité et à chaque évolution sur le site.
Balises utilisées à des fins de présentation
Impact utilisateur
Les éléments de structure HTML ont chacun une sémantique particulière (paragraphe, titre, image,
lien, etc.). Si les éléments sont mal employés (détournés de leur utilité première), cela peut poser
des problèmes aux utilisateurs qui naviguent à l’aide d’une technologie d’assistance (lecteur
d’écran, plug-in…). En effet, les technologies d’assistance mettent des raccourcis à disposition
permettant de naviguer rapidement entre certains types d’éléments (paragraphe, titres, listes,
etc.). Si ces éléments sont mal employés, les utilisateurs ne peuvent pas utiliser ces fonctionnalités
de repère et navigation dans le contenu.
Constat et corrections
Le site utilise des balises uniquement pour créer des effets de présentation ou pour en détourner
l’usage tel que défini par la spécification HTML5.
à la place de
Des paragraphes sont encore écrits avec des . Remplacer toutes les balises qui
structurent des blocs de texte par des balises ou insérer une balise dans les balises
concernées.
C’est essentiellement le cas dans les fenêtres modales qui n’ont pas toutes été correctement
corrigées.
à la place de
On trouve également un peu partout sur l’échantillon des balises utilisées à la place de
paragraphes.
Sur l’exemple, quasiment tous les textes sont structurés avec des balises label ou div alors qu’ils
devraient être structurés dans des balises paragraphes ou dans une liste.
Ressources
• Fiche 1 : Gabarit général — Guide de l’intégrateur RGAA 37
6 https://validator.w3.org/nu/
7 https://disic.github.io/guide-integrateur/1-gabarit-general.html#essentiel
Rapport d'audit RGAA 3 13/31• Fiche 8 : Respecter la distinction fond et forme - Guide de l’intégrateur RGAA 38
Structuration de l’information
Recommandation :
Utiliser des titres, des listes, des abréviations et des citations pour structurer l’information.
S’assurer que la structure du document est cohérente.
Constats et préconisations de correction
Titres
Le titrage des contenus est une étape importante dans la structuration des contenus. Cela
répond à deux besoins :
1. identifier rapidement un contenu recherché ;
2. naviguer rapidement dans le contenu en se déplaçant de titre en titre. Un titrage correct
fournit à l'utilisateur de lecteur d’écran un plan du document et lui permet de naviguer de
titre en titre pour se déplacer plus rapidement dans le contenu de la page.
Astuce : pour valider la structure de votre page, vous pouvez utiliser l'extension Firefox
HeadingsMap9. Lorsque l’extension est active, sélectionnez l'onglet « Headings » et vérifiez la
cohérence et l'imbrication des titres.
Constat et corrections
Le titrage a dans l’ensemble été bien corrigé sur le site. On trouve encore quelques erreurs
néanmoins notamment sur les fenêtres popup.
Pied de page
Les textes en gras dans le pied de page devraient être des titres H1.
Fenêtres popup Accessibilité, Mentions légales
Nous contacter, Défenseur des droits doivent être des titres H2.
"Adresse", "réalisation éditoriale", etc. devraient être des titres de niveau 2.
Note : le titrage des CGU (hors échantillon) est également défaillant et doit être corrigé.
8 https://disic.github.io/guide-integrateur/8-distinction-fond-forme.html
9 https://addons.mozilla.org/fr/firefox/addon/headingsmap/
Rapport d'audit RGAA 3 14/31Plan du site Le titrage n’est pas correct dans la fenêtre modale Plan du site. Portail [Mode connecté] et Informations complémentaires doivent être des titres de niveau 2. Utilisez les balises h2 ou ARIA (role="heading" aria-level="2"). Portail [Mode connecté] Les textes en bleu doivent être des titres de niveau 3. Utilisez les balises h3 ou ARIA (role="heading" aria-level="3"). Listes La structuration en listes permet aux utilisateurs de lecteurs d’écran de consulter plus rapidement le contenu, grâce à des raccourcis spécifiques. Dans le cas d’une succession de liens (comme dans le pied de page), la structuration en liste permet aussi de pallier une caractéristique gênante de certains lecteurs d’écran. En effet, certains lecteurs d'écran peuvent en effet répéter le terme « lien » plusieurs fois de suite pour un même lien par exemple, lors de la mise à jour du tampon de vocalisation. L'utilisation de listes HTML permet alors à l'utilisateur de faire une distinction claire entre chaque lien, et de mieux comprendre le contenu qui lui est restitué. Corrections Structurez les éléments de l’accès rapide dans une liste ul/li. De même, pour les éléments du fil d’événement. Rapport d'audit RGAA 3 15/31
On peut imaginer une liste imbriquée avec une première liste avec les services puis une liste par
service avec les items à l’intérieur.
Même principe pour le fil d’actualité si des informations se présentent de la même façon.
De manière générale, structurez les liens successifs dans des listes UL/LI.
Ressources
• Listes — Fiche 3 : Contenus — Guide de l’intégrateur RGAA 310
Structure du document
Les utilisateurs aveugles ne perçoivent pas les mises en forme. Pourtant, celles-ci aident à
la compréhension de la fonction de certaines régions de la page.
L’utilisation correcte des balises HTML5 et des landmarks ARIA permet d'enrichir la restitution
pour ces utilisateurs : la navigation principale ne sera plus perçue simplement comme une liste de
liens, elle sera restituée à l'utilisateur comme un élément de navigation, par l’intermédiaire du
lecteur d'écran. L'utilisateur pourra alors la distinguer des autres listes de liens.
De plus, ces marqueurs sémantiques constituent également des éléments de navigation rapide
dans la page. Grâce à un raccourci clavier, certains utilisateurs naviguent plus rapidement entre
les régions identifiées.
Constats et corrections
Les différentes balises HTML5 ainsi que les landmarks ARIA n’ont pas été implémentés.
Vous trouverez à la fin de ce document, dans la note technique correspondante, une proposition
d'implémentation des balises HTML5 (main, header, nav et footer) ainsi que des landmarks ARIA
pour la structure du document.
Ressources
• Éléments HTML5 et landmarks ARIA — Fiche 1 : Gabarit général — Guide de l’intégrateur
RGAA 311
Présentation de l’information
Recommandation :
Utiliser des feuilles de styles pour contrôler la présentation de l’information. Vérifier l’effet de
l’agrandissement des tailles des caractères sur la lisibilité. S’assurer que les liens sont
correctement identifiables, que la prise de focus est signalée, que l’interlignage est suffisant et
donner la possibilité à l’utilisateur de contrôler la justification des textes. S’assurer que les textes
10 https://disic.github.io/guide-integrateur/3-contenus.html#listes
11 https://disic.github.io/guide-integrateur/1-gabarit-general.html#html5aria
Rapport d'audit RGAA 3 16/31cachés sont correctement restitués et que l’information n’est pas donnée uniquement par la forme ou la position d’un élément. Constats et préconisations de correction Utilisation de CSS exclusivement Certains utilisateurs qui présentent des troubles de la lecture (dyslexiques par exemple) vont avoir besoin d’adapter la présentation des pages avec leurs propres mises en forme. Cela est possible sans difficulté si le site web utilise exclusivement les feuilles de styles CSS pour réaliser les mises en forme. Cependant, l’utilisation d’attributs et balises HTML de mise en forme rend ces adaptations plus compliquées, sinon impossibles. Le RGAA donne la liste des attributs et balises qu’il est interdit d’utiliser 12 : Les éléments (basefont, blink, center, font, marquee, s, strike, tt et big) et les attributs (align, alink, background, bgcolor, border, cellpading, cellspacing, char, charoff, clear, compact, color, frameborder,hspace, link, marginheight, marginwidth, text, valign, vlink, vspace, size) sont interdits. Note : Les attributs width et height utilisés sur d’autres éléments que les balises img, object, embed, canvas et svg, sont également interdits. On trouve des balises sur la page Mentions légales dans les contenus contribués : chorus-pro.gouv.fr Correction Repérez dans vos pages tous les attributs et balises de mise en forme, retirez-les et réalisez les mises en forme uniquement avec CSS (feuille de style externe, balise dans le head de la page pour attribut style en ligne). Contenu visible sans les feuilles de styles Des contenus informatifs insérés avec CSS (avec la propriété content ou avec des images de fond contenant du texte en image) peuvent ne pas être restitués par les lecteurs d’écran ou les systèmes de loupes vocalisés. Le composant Oui/Non n’est pas accessible. Les éléments ne sont pas restitués, car injectés avec CSS. Ce composant sera discuté en restitution. Contenu compréhensible sans les styles : ordre visible vs ordre réel Un utilisateur aveugle n’a pas accès à la mise en forme qui parfois est porteuse d’informations importantes, notamment des relations entre les éléments. Il est important de ne pas implémenter les textes dans l’ordre visuel, mais bien dans l’ordre logique de dépendance et hiérarchie des éléments. 12 http://references.modernisation.gouv.fr/referentiel/glossaire.html#prsentation-de-linformation Rapport d'audit RGAA 3 17/31
Le contenu doit rester compréhensible sans les feuilles de styles (vous pouvez tester vos contenus en désactivant les feuilles de styles). Libre à vous ensuite, de repositionner les éléments visuellement avec CSS (position : absolute, Flexbox, etc.) pour respecter la maquette, mais veillez à toujours conserver un ordre compréhensible de succession des textes. Voir un exemple de repositionnement CSS avec Flexbox (en anglais)13. Ainsi, le bandeau des cookies est situé en haut de l’écran, mais à la fin du code source. Le code de celui-ci devra se trouver au tout début du DOM, après l’ouverture de la balise idéalement. Sur l’écran de validation de la facture (P09), l’ordre des boutons dans le code HTML n’est pas le même que l’ordre visuel. Il nous semblerait plus logique et pratique pour l’utilisateur aveugle ou qui navigue au clavier d’avoir accès d’abord au bouton Valider et envoyer. Ce n’est pas le cas actuellement, l’ordre est inversé, on commence par Saisir une nouvelle facture. Agrandissement des tailles de texte Certaines personnes déficientes visuelles, également des personnes ayant des difficultés de lecture comme les personnes dyslexiques, ont besoin d’adapter la taille du texte à l’écran uniquement, et non pas le graphisme dans son ensemble. L’agrandissement des caractères ne doit pas provoquer de perte d’informations. À 200 % de la taille de la police par défaut, le contenu doit rester lisible et compréhensible, toutes les informations doivent rester présentes. Le test d’agrandissement des caractères ne peut être réalisé que dans Firefox : activez l’option « zoom texte seulement » dans le menu « Affichage » de Firefox et faites Ctrl + six fois. De plus, afin d’assurer un agrandissement des caractères optimal sur toutes les plateformes, les feuilles de styles destinées à l’écran doivent comporter des déclarations de font-size uniquement en valeurs relatives (em, rem, %, etc.), et surtout pas de valeurs fixes comme px. Sur le site, l’agrandissement est relativement bien géré, à l’exception des call to action qui sont régulièrement tronqués. Correction Repérez dans les feuilles de styles toutes les déclarations de taille de police et convertissez les tailles déclarées en unités fixes par des tailles en unités relatives ( em ou % par exemple). Testez l’agrandissement des caractères sur toutes les pages du site et assurez-vous que les mises en forme ne viennent pas empêcher l’accès à l’information (disparition/chevauchement). 13 https://codepen.io/oliviernourry/pen/qKPBBQ Rapport d'audit RGAA 3 18/31
Visibilité de la prise de focus
Les personnes avec un handicap moteur qui naviguent au clavier peuvent rencontrer des difficultés
considérables à utiliser du contenu s’ils ne sont pas en mesure de repérer l’indication visuelle du
focus et ses déplacements.
Il ne faut jamais supprimer cette indication visuelle de prise de focus.
On trouve dans les feuilles de styles des déclarations css visant à dégrader la visibilité de la prise
de focus. :
.form-control:focus{outline:0;}
Les valeurs outline:0 ou outline:none par exemple sont interdites pour l’état :focus des
éléments, quand bien même vous implémenteriez une autre mise en forme pour la visibilité de la
prise de focus (bordure ou couleur de fond par exemple).
Il ne faut donc pas dégrader l’outline natif, cependant il est possible de le renforcer. Retirez de vos
feuilles de styles toutes les déclarations visant à dégrader l’outline natif à la prise de focus.
Note : L’outline est dégradé par les propriétés outline, outline-color, outline-width,
outline-style dès le moment où ces propriétés rendent difficilement visibles les bordures
normalement visibles à la prise de focus.
Contrôles positionnés hors écran
On rencontre une autre problématique sur le site, qui même si vous retirez les propriétés outline
dégradant la prise de focus, rend toujours la prise de focus invisible sur le site. En effet, certains de
vos composants sont redesignés. C’est le cas par exemple des cases à cocher et des boutons radio.
Les contrôles natifs (input) sont positionnés hors écran et c’est le label qui est stylé en CSS.
Néanmoins, c’est bien le contrôle natif qui reçoit le focus, or, étant positionné hors écran, la prise
de focus est toujours invisible.
Ici, le code source est construit de manière logique ( input puis label), il est possible d’utiliser le
sélecteur CSS d’enfant adjacent pour reporter la visibilité de la prise de focus sur le label.
Code HTML
J'accepte
[…]
Code CSS
input:focus+label{outline : [valeur de votre outline]}
Liens dont la nature n’est pas évidente
Un lien dont la nature n’est pas évidente est un lien qui peut être confondu avec un texte
normal lorsqu’il est signalé uniquement par la couleur par certains types d’utilisateurs ne
percevant pas ou mal les couleurs.
Les personnes déficientes visuelles peuvent ignorer ces liens puisque ceux-ci ne sont pas
visuellement discernables du reste du texte dans lequel ils sont insérés.
Dans une moindre mesure, les personnes présentant un handicap mental pourraient également
avoir des difficultés dans le même genre de situation.
Rapport d'audit RGAA 3 19/31On trouve deux cas notamment dans l’application Chorus Pro (les écrans ont été pris sur
l’application en production pour avoir la couleur réelle)
Pour le cas des tableaux, ce point sera détaillé en restitution.
Correction
Il existe deux solutions pour corriger ce problème d’accessibilité.
La première solution, la plus simple, consiste à rétablir le souligné des liens, lorsque ceux-ci se
trouvent dans un environnement de texte.
La seconde solution est de changer la couleur des liens dont la nature n’est pas évidente : dans
ce cas, ces liens doivent présenter un rapport de contraste de 3:1 par rapport à la couleur du texte
qui les entoure.
Ressources
• Fiche 7 : Prise de focus — Guide de l’intégrateur RGAA 314
• Fiche 9 : Images textes — Guide de l’intégrateur RGAA 315
• Fiche 11 : Agrandissement des caractères — Guide de l’intégrateur RGAA 316
• Visibilité des liens par rapport au texte environnant — Fiche 7 : Présentation — Guide du
concepteur RGAA 317
14 https://disic.github.io/guide-integrateur/7-focus.html
15 https://disic.github.io/guide-integrateur/9-images.html#imagestextes
16 https://disic.github.io/guide-integrateur/11-agrandissement-des-caracteres.html
17 https://dinsic.gitlab.io/guide-concepteurs/7-presentation.html#visibilite-liens
Rapport d'audit RGAA 3 20/31Formulaires
Recommandation :
Associer pour chaque formulaire chacun de ses champs à son étiquette, grouper les champs dans
des blocs d’informations de même nature, structurer les listes de choix de manière pertinente,
donner à chaque bouton un intitulé explicite. Vérifier la présence d’aide à la saisie, s’assurer que le
contrôle de saisie est accessible et que l’utilisateur peut contrôler les données à caractère financier,
juridique ou personnel.
Constats et préconisations de correction
Les aveugles, les grands malvoyants et les déficients visuels qui utilisent des lecteurs d’écrans ou
des loupes vocalisées auront des difficultés majeures pour comprendre le formulaire s’il contient
des champs de saisie dépourvus d’étiquette, de regroupement (par exemple pour les cases à
cocher et les boutons radio).
Pour cette thématique, nous résumons les principaux problèmes et renvoyons vers une note
technique pour les détails techniques afin d’alléger la lecture de cette thématique.
Par ailleurs, pour éviter des allers-retours entre cette partie et la partie technique pour
l’équipe de développement, toutes les informations sont reprises dans la note technique.
Étiquettes et champs
Les champs de formulaires doivent tous posséder des étiquettes.
Une étiquette de champ est un texte situé à proximité du champ de formulaire qui permet de
connaître la nature, le type ou le format des informations attendues.
Pour être conforme, une étiquette doit :
• être pertinente ;
• être correctement reliée au champ correspondant.
• être accolée au champ qu’elle contrôle.
De cette manière, lorsqu’un utilisateur entre dans le champ de saisie avec un lecteur d’écran, le
lecteur d’écran lit le contenu de l’étiquette. L’utilisateur comprend alors ce qu’il doit saisir.
Sans cela, même si une étiquette est présente visuellement, l’utilisateur entendra « champ de
saisie vide » en entrant dans le champ et ne saura donc pas quoi saisir.
Pour certains champs, lorsqu'il n'y a pas de contrôle sur le format de données, il est possible de
fournir l'étiquette en ajoutant un attribut title sur le champ. De cette manière, le champ sera
étiqueté pour les personnes aveugles sans impacter l'aspect visuel du site.
Note : on trouve de nombreux champs input avec un attribut title sur le champ redondant avec le
label. Il serait préférable de supprimer ces attributs title lorsqu’ils n’apportent pas d’information
complémentaire. Néanmoins, ce point n’est pas prioritaire et devrait être traité si possible.
Étiquettes accolées
Sur Chorus Pro, le principal problème est que les étiquettes ne sont généralement pas accolées aux
champs.
Rapport d'audit RGAA 3 21/31Cela peut poser d’importants problèmes à des personnes déficientes visuelles qui naviguent avec un fort taux de grossissement. Champs sans étiquettes Dans l’ensemble, les champs sont bien étiquetés sur l’application. Il y a néanmoins quelques erreurs, dont certaines récurrentes et faciles à localiser (voir note). Contrôle de saisie et aide à la saisie Certains champs de formulaires possèdent des aides à la saisie, ou des informations importantes pour remplir les champs, mais ces textes sont toujours situés après les champs concernés. Ainsi, les utilisateurs aveugles qui ont une lecture linéaire de l'information n’accéderont pas à cette information avant de remplir le champ, il y a donc un danger à ce qu’il y ait une réelle perte d’information. Exemple ci-dessous avec des informations pour le format du mot de passe. Indications de format Certains champs attendent un format spécifique. Il est nécessaire de l’indiquer à l’utilisateur en amont de sa saisie. Messages d’erreur Les messages d’erreur de saisie des champs de formulaire doivent être liés correctement aux champs en erreur, ce qui n’est pas le cas actuellement. Champs obligatoires Une autre problématique importante sur l’application est l’indication des champs obligatoires qui restent très mal indiqués dans l’application globalement. Nous vous conseillons de reprendre la mention « * champs obligatoires » que l’on peut voir sur certains écrans et de systématiser sa présence sur tous les écrans possédant des formulaires avec des champs obligatoires. Rapport d'audit RGAA 3 22/31
Regroupements de champs et légendes Certains champs de formulaires doivent être regroupés programmatiquement. En effet, sans cela, pour les utilisateurs aveugles, certains champs peuvent être ambigus, voire ne pas être compréhensibles. Les cas typiques de regroupements nécessaires sont les groupes de cases à cocher ou de boutons radio, notamment lorsque leur étiquette n’est pas suffisamment explicite. Navigation Recommandation : Faciliter la navigation dans un ensemble de pages par au moins deux systèmes de navigation différents (menu de navigation, plan du site ou moteur de recherche), un fil d’Ariane et l’indication de la page active dans le menu de navigation. Identifier les groupes de liens importants et la zone de contenu et donner la possibilité de les éviter par des liens de navigation interne. S’assurer que l’ordre de tabulation est cohérent et que la page ne comporte pas de piège au clavier. Constats et préconisations de correction Liens d’accès rapide On note l’absence d’un lien d’accès rapide au contenu au moins. Les liens d’accès rapides sont utiles aux utilisateurs qui naviguent au clavier, mais aussi aux utilisateurs malvoyants qui utilisent une loupe d’écran afin de sauter rapidement les éléments redondants, comme la navigation. Correction Implémentez au moins un lien d’accès rapide au contenu, qui permet de sauter toute la navigation principale. Ce lien d’accès rapide doit être le premier ou l’un des premiers éléments de contenu (il peut notamment être placé après le bandeau de cookies). Par exemple un lien en haut de page contenu qui permet d’accéder à la zone ayant le role main . La propriété tabindex="-1" est essentielle au bon fonctionnement de ce lien. Note : si le lien est gênant pour le design, il est possible de le masquer visuellement (position : absolute, méthode .sr-only18 par exemple) et de ne le faire apparaître qu’à la prise de focus. 18 https://gist.github.com/ffoodd/000b59f431e3e64e4ce1a24d5bb36034 Rapport d'audit RGAA 3 23/31
Landmarks ARIA
Pour fournir des points de repère aux utilisateurs aveugles, il faut également implémenter les
landmarks ARIA sur les balises HTML 5 de la page.
Les landmarks ARIA sont des propriétés qui donnent une fonction aux éléments structurants de la
page :
• role="banner" sur l’en-tête du site ;
• role="search" sur l’élément contenant le moteur de recherche ;
• role="main" sur le container du contenu principal ;
• role="navigation" sur la navigation principale et les éventuelles navigations secondaires
(pagination, fil d’Ariane) ;
• role="contentinfo" sur les éléments de pied de page (informations sur le contenu).
Voir annexe sur la structuration qui reprend également les landmarks à ajouter.
Consultation
Recommandation :
Vérifier que l’utilisateur a le contrôle des procédés de rafraîchissement, des changements brusques
de luminosité, des ouvertures de nouvelles fenêtres et des contenus en mouvement ou clignotants.
Indiquer lorsqu’un contenu s’ouvre dans une nouvelle fenêtre et donner des informations relatives
à la consultation des fichiers en téléchargement. Ne pas faire dépendre l’accomplissement d’une
tâche d’une limite de temps sauf si elle est essentielle et s’assurer que les données saisies sont
récupérées après une interruption de session authentifiée. S’assurer que les expressions
inhabituelles et le jargon sont explicités. Proposer des versions accessibles ou rendre accessibles
les documents en téléchargement.
Constats et préconisations de correction
Documents en téléchargement
Lorsqu’un fichier en téléchargement est proposé dans une page web, il faut indiquer les
informations nécessaires à sa consultation, telles que :
• le poids du fichier ;
• le format du fichier ;
• la langue du fichier, si elle diffère de la langue de la page.
Cette information doit être présentée dans l’intitulé du lien : dans le title ou dans le contexte
environnant, le mieux étant de le présenter dans l’intitulé du lien.
Si vous ne pouvez pas définir le poids a priori, vous pouvez par contre indiquer le format de
téléchargement.
Rapport d'audit RGAA 3 24/31Vous pouvez aussi lire
