Accessibilité : partiellement conforme

Déclaration d’accessibilité au Référentiel Général d’Amélioration de l’accessibilité (RGAA)

La Caisse Nationale des Allocations Familiales (CNAF) s’engage à rendre ses sites internet, intranet, extranet et ses applications mobiles, etc. accessibles conformément à l’article 47 de la loi n° 2005-102 du 11 février 2005. 
À cette fin, elle est en train de mettre en place son schéma pluriannuel et travaille depuis plusieurs années à la mise en conformité de ses projets numériques. 
Cette déclaration d’accessibilité s’applique à la partie éditoriale du site caf.fr. 
 

Contact

En cas de difficulté, vous pouvez adresser vos remarques à accessibilite-numerique@cnaf.fr.
 

État de conformité

Le site caf.fr pour sa partie éditoriale est en conformité partielle avec le référentiel général d’amélioration de l’accessibilité, RGAA version 3.0. 
Les corrections des non-conformités sont planifiées en 2021 et la présente déclaration d’accessibilité sera mise à jour à l'issue d’un contre-audit qui sera réalisé à la suite des corrections.
 

Résultats des tests

L’audit de conformité réalisé le 23 octobre 2020 par la société AVENCOD révèle que, sur un échantillon de 9 pages, 84% des critères RGAA sont respectés.
 

Contenus non accessibles

Non-conformités
NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitait d’être détaillées en dehors de la seule grille d’audit.  
 

• Scripts :

Dans l’échantillon audité, il y a un problème récurrent concernant les carrousels situés en haut de page de certains écrans. 

•  Couleur :

Dans l’échantillon audité, certains liens ne sont plus identifiables lors de l’application de la feuille de style permettant d’accéder au contenu en version renforcé. 

• Eléments obligatoires : 

Dans l’échantillon audité, la plupart des contenus textuel situés dans le contenu principal des pages sont implémentés avec des balises <div> ou <span>. 

Technologies utilisées pour la réalisation du site

• Drupal
• PHP
• Bootstrap
• Javascript
• Html
• CSS

Environnement de test

Les vérifications de restitution de contenus ont été réalisées conformément à la base de référence fournie par RGAA 3.0.

•  Mozilla Firefox (à titre principal) : V 80.0.1 (64 bits) et NVDA 2020 
• Google chrome : V 85.0.4183.83 (Build officiel) (64 bits) 

Outils pour évaluer l’accessibilité

• WCAG Contrast checker _ V 3.5.4
• Extension Web Developer.
• Inspecteur de code.
• Axe (extension mozzilla) _ V 4.5.3
• HeadingsMap – V 3.8.2
   

Pages ayant fait l'objet de la vérification de conformité

• Accueil
• Accueil Rubrique Actualité
• Accueil Rubrique Mes Services en ligne
• Accueil Rubrique Droits et Prestations
• Accueil Rubrique Vies de Famille
• Accueil Rubrique Aide
• Accueil Rubrique Ma Caf
• Page d'accueil Partenaires
• Page d'accueil Presse & Institutionnel
   

Voies de recours

Il est important de rappeler qu’en vertu de l’article 11 de la loi de février 2005 :

La personne handicapée a droit à la compensation des conséquences de son handicap, quels que soient l’origine et la nature de sa déficience, son âge ou son mode de vie.

Si vous nous signalez un problème d’accessibilité et que vous ne parvenez pas à obtenir une réponse rapide de notre part, vous êtes en droit de faire parvenir vos doléances ou demande de saisine au Défenseur des droits.

• Formulaire en ligne pour contacter le Défenseur des droits  
• Contacter le délégué du Défenseur des droits dans votre région
• Envoyer un courrier postal (courrier gratuit, sans affranchissement) : Le Défenseur des droits - Libre réponse 71120 - 75342 Paris CEDEX 07

Accessibilité numérique - Rapport d’audit RGAA4 - « Offre Bailleurs »

L’audit de conformité réalisé par la société AVENCOD révèle que, sur un échantillon de 9 pages, 78% des critères RGAA sont respectés.

Nom du service numérique : CNAF

Date de l’audit : 23 octobre 2020
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :

1. Introduction 
Contexte 
Accessibilité du site 
2. Description des erreurs d'accessibilité 
Couleur 
Eléments obligatoires 
Formulaires 
Navigation 
3. Conclusion 
 

1. Introduction

Contexte

Le périmètre comprend un audit des pages offre bailleurs.
La version utilisée pour réaliser les tests est la version <4.0> du RGAA.
Le thème du site a été audité sur la première page du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.0 (incluant les scripts).

Les navigateurs employés pour tester les pages sont : 
• Mozilla Firefox (à titre principal) : V 80.0.1 (64 bits)
• Google chrome : V 85.0.4183.83 (Build officiel) (64 bits)

Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9 et 13.12 n’ont ainsi pas pu être réalisés. 
De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés. 
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular
Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2
La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.0 :
- Non visual Desktop Access (NVDA) ; Version 2020.

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est moyennement bon.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendants de l’implémentation de l’écran et de chacun de ses composants. N’étant pas voyants, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants. D’autre part, les utilisateurs mal-voyants sont également beaucoup impactés par certaines des erreurs, typiquement liées aux contrastes des composants d’interface et les éléments relatifs aux infobulles sachant que la pop-up d’accessibilité permettant d’augmenter les contrastes était absente de ce périmètre.
Il s’agit d’ailleurs d’une des erreurs majeures de ce périmètre.
Il persiste quelques erreurs comme des détournements de balises, ou encore de focus/ordre de tabulation.
 

2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitaient d’être détaillées en dehors de la seule grille d’audit.

Couleur 

Les couleurs du thème présentent un contraste de couleurs insuffisant. En l’absence de la pop-up d’accessibilité qui permet habituellement de mettre un mode de contrastes renforcés, et en la présence d’un certain nombre d’informations données par la couleur uniquement, l’utilisateur malvoyant est totalement pénalisé.
Pour éviter ce genre de cas, vous pouvez privilégier une implémentation en deux temps avec une forme (ex : soulignement) et une couleur pour les informations données uniquement par la couleur.
D’autre part, on vous recommande fortement d’implémenter la pop-up d’accessibilité comme celle retrouvée dans d’autres périmètres du style Allocataires, qui permettrait l’application d’un mode renforcé sur le contenu, et ne vous impose donc pas de changer les couleurs de votre thème.

Eléments obligatoires

Dans l’échantillon audité, un certain nombre de contenus textuels situés dans le contenu principal des pages sont implémentés avec des balises <div> ou <span>. 
Le RGAA 4 considère cela comme une Non-conformité car pour reprendre le critère : les balises ne doivent pas être détournées et utilisées à des fins de présentation (paragraphes etc.). 
Pour corriger ces problèmes utilisez simplement les balises ayant la nature correspondante aux éléments que vous souhaitez insérer dans le code. En cas de texte par exemple, utiliser la balise <p>.

Formulaires

Les formulaires de la CNAF contiennent de nombreux champs obligatoires. 
2 réflexes doivent donc être pris par les équipes de développement : indiquer les champs obligatoires par un message précédant le champ (ou le regroupement de champs) et bien relier les messages d’erreurs aux champs non remplis ou mal remplis. 

1/ l’indication que les champs sont obligatoires :
Cela permet aux utilisateurs voyants et aveugles de ne pas rester bloqués indéfiniment dans un écran à la recherche du champ obligatoire qu’ils n’auraient pas renseigné. 
Pour satisfaire cette obligation, il faut penser d’une part aux utilisateurs voyants et d’autre part aux utilisateurs non-voyants.
Pour les utilisateurs voyants : une indication visible des champs obligatoires doit être fournie. Elle peut concerner chaque champ obligatoire isolément, ou un regroupement de champs, ou même consister en une indication en haut de page lorsque tous les champs sont obligatoires. 
En arrivant sur l’écran, aucune mention ne précise qu’il faut choisir un des champs avant de cliquer sur le bouton continuer. 
En l’état, un utilisateur peut avoir l’impression qu’il peut passer la page en appuyant sur continuer, apparaîtra alors le message d’erreur, postérieurement à l’essai de validation du formulaire. 
Ici, les utilisateurs non-voyants, qui utilisent un lecteur d’écran reçoivent bien l’information que le champ est obligatoire en raison de l’implémentation de l’attribut required. Il serait toutefois préférable de relier aux champs le message indiquant aux utilisateurs voyants que les champs sont obligatoires.

2/ Bien relier les messages d’erreurs aux champs en erreur 
Ici, les utilisateurs impactés sont principalement les personnes aveugles, qui ne vont pas pouvoir accéder aux indications visuelles que nous avons lorsque nous ne remplissons pas ou que nous remplissons mal les champs obligatoires. Ils ne voient pas les messages d’erreur ni les bordures rouges des champs. 
Il est donc primordial de bien relier chaque message d’erreur avec le champ effectivement en erreur.
Visuellement, il est évident que le texte en rouge se rapporte aux champs dont le contour est rouge. 
Pourtant, dans l’implémentation, l’Id du texte d’erreur n’est pas relié par la propriété aria-describedby aux champs en erreur. Les utilisateurs aveugles n’ont donc pas accès à cette information en temps utile et de manière fonctionnelle. 
Puisque l’accès à l’écran suivant est conditionné par le fait de remplir correctement ces champs, il est très important de faciliter la compréhension des erreurs aux personnes utilisatrices d’un lecteur d’écran. 

Navigation

Le principal problème dans ce critère est le placement du focus :

Le focus n’est pas replacé au bon endroit lorsqu’on clique sur le bouton continuer pour atteindre la suite du processus.
Les utilisateurs aveugles qui utilisent le lecteur d’écran ne savent pas qu’ils sont sur une nouvelle page, puisque le focus n’est pas replacé sur le titre h1 ou en haut de page. L’utilisateur va penser qu’il est toujours sur la même page (puisque son focus est sur le bouton continuer).
D’autre part, s'il se rend compte qu’il est dans une nouvelle page, il doit naviguer à travers toute la page pour remonter sur les premiers éléments de celle-ci.
Il est donc important de corriger cela, en replaçant correctement le focus.

D’autre part, le focus n’est pas perceptible sur certains boutons radio, comme ils se trouvent en dehors de l’écran. Dans ce cas, répercutez la visibilité de la prise de focus sur l’élément visible (le label).
De fait, vous rendez le focus perceptible pour les utilisateurs malvoyants.

3. Conclusion 

Globalement, l’accessibilité de cet échantillon est moyenne. 
Il reste des erreurs à corriger, souvent communes à un ensemble d’écrans du processus, une correction générale devrait résoudre une bonne partie des problématiques.

Les corrections à apporter sont dans l’ensemble assez importantes, notamment concernant la problématique des couleurs qui est une problématique majeure lorsqu’on parle d’accessibilité.

Il est donc recommandé de corriger cela en priorité ainsi que les problématiques de visibilité et de placement du focus, puis de se pencher sur d’autres problématiques un peu moins impactantes comme les scripts, les formulaires, …

Si besoin, nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments de la grille d’audit ou de ce rapport.

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte    
Accessibilité du site    
2. Description des erreurs d’accessibilité    
Formulaires    
Navigation    
3. Conclusion    
Avis de l’inspecteur

1. Introduction 

Contexte

Le périmètre audité concerne la partie Bascule du périmètre CafConnect.
La version utilisée pour réaliser les tests est la version <4.0> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.0 (incluant les scripts).

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 80.0.1 (64 bits)
- Google chrome : V 85.0.4183.83 (Build officiel) (64 bits)

Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9 et 13.12 n’ont ainsi pas pu être réalisés. 
De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés. 
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angula

Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2

La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.0 :
- Non visual Desktop Access (NVDA) ; Version 2020.

L’audit a porté sur un échantillon de 2 pages. En effet, sur les 4 pages de cette parties, 2 ont été non auditables en l’état : le carrousel des pages promotionnelles ainsi que la page de sécurité (via le lien suivez le guide).
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est globalement très bon.
Le taux de conformité est d’environ 88% (calcul effectué sans la prise en compte du nombre de critères non-applicables).
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.0, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendants de l’implémentation de l’écran et de chacun de ses composants. N’étant pas voyants, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2. Description des erreurs d'accessibilité 

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitaient d’être détaillées en dehors de la seule grille d’audit.

Formulaires

Le formulaire de la page des CGU est d’une importance majeure pour l’utilisateur, puisque sa validation lui permet d’accéder à son compte.
L’utilisateur de lecteurs d’écran est actuellement pénalisé car la seule case à cocher de ce formulaire n’a pas de nom accessible. Il s’agit d’un bouton avec un role=checkbox.
Implémentez le nom accessible en créant une étiquette :
- En ajoutant à la case à cocher une propriété aria-label qui reprenne le texte visible
- Ou en ajoutant la propriété aria-labelledby et en y référençant l’id de l’étiquette « checkCGULabel »

Navigation

Le principal problème dans ce critère est le placement du focus : le focus n’est pas replacé au bon endroit lorsqu’on clique sur le lien d’accès rapide. Il ne se place en effet pas sur le contenu principal.
Assurez vous que ce lien place le focus au bon endroit pour que l’utilisateur aveugle puisse naviguer plus facilement dans la page

3. Conclusion 

Avis de l’inspecteur

Globalement, l’accessibilité de cet échantillon est très satisfaisante.

Il reste quelques erreurs à corriger, parfois répétées dans plusieurs écrans, une correction générale devrait résoudre une partie des problématiques.
Les corrections à apporter sont dans l’ensemble minimes, avec un impact limité. 

Si besoin, nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport.

Nom du service numérique : CNAF

Date de l’audit : Mai 2021

Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte    
Dérogations et éléments non testés    
Accessibilité du site    
2. Description des erreurs d’accessibilité    
Images     
Liens 
Script     
Formulaire    
Navigation     
3. Conclusion    
Avis de l’auditeur

1. Introduction

Contexte

Le périmètre audité concerne le périmètre Mon Compte pages principales.
La version utilisée pour réaliser les tests est la version <4.1> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.1 (incluant les scripts), sauf quelques exceptions indiquées ci-dessous.

Dérogations et éléments non testés

Dérogations :

Le critère 11.13 demandant le remplissage automatique des champs de saisie de formulaire via un autocomplete n’est pas audité car il est dérogé dans le contexte de la cnaf : les informations traitées étant très sensibles, la sécurité de ces données prévaut sur leur facilité d’accès.
Cette aide à l’auto-remplissage des champs (élément autocomplete) peut poser de graves brèches de sécurités en ce qui concerne la gestion des données personnelles des utilisateurs. Si une personne se connecte sur un réseau public sur le site de la CNAF et que l’autocomplete est implémentée, l’utilisateur suivant qui se connecterait sur le site de la CNAF bénéficierait, via le remplissage automatique, de l’ensemble des accès aux données personnelles de l’utilisateur précédent.
Cette situation critique est à éviter absolument, notamment en raison des exigences légales relatives à la gestion des données personnelles.
Ces enjeux ont été considérés comme supérieurs au gain en accessibilité que permettrait cette implémentation, la dérogation est donc accordée.

Eléments non testés :

- Les critères 13.3 et 13.4 sur les documents bureautiques ne seront pas mis en non-conformité quand il y a présence desdits documents. Les équipes de la CNAF nous ont remonté que, pour l’instant, les fichiers PDF générés lors des démarches des utilisateurs ne sont pas accessibles. Ils ne sont donc pas réaudités dans ce périmètre.
- Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9 et 13.12 n’ont ainsi pas pu être réalisés. De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés en raison de problèmes de connexion via VPN en environnement mobile, ce test ne peut donc pas être performé pour l’instant.
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les navigateurs employés pour tester les pages sont : 

• Mozzilla firefox (à titre principal) : V 80.0.1 (64 bits)
•  Google chrome : V 85.0.4183.83 (Build officiel) (64 bits)

Les technologies utilisées sur le site sont les suivantes :

• HTML5
• CSS
• Framework angular

Les outils suivants ont été utilisés pour vérifier l’accessibilité :

• WCAG Contrast checker _ V 3.5.4
• Axe (extension mozzilla) _ V 4.5.3
• HeadingsMap – V 3.8.2

La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.1 :
L’audit a porté sur un échantillon de 14 pages.
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est globalement bon.
Le taux de conformité sur l’échantillon globale est d’environ 73% (calcul effectué sans la prise en compte du nombre de critère non-applicable). 
Le taux de conformité moyen par pages est quant à lui de 92%.
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.1, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendants de l’implémentation de l’écran et de chacun de ses composants. N’étant pas voyants, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitaient d’être détaillées en dehors de la seule grille d’audit.

Images 

Non conformités correspondant au critères 1.8 du RGAA 4.1 :

Lorsque l’utilisateur veut accéder au tableau de bord, une pop-up s’ouvre. 
Cette pop-up est constituée d’une image promotionnelle, avec une alternative qui ne retranscrit pas le contenu de cette image.
Cette image dans la pop-up est particulièrement problématique. Si on doit s’en tenir à la lecture même de cette image, elle n’apporte aucune information, c’est une pure image de décoration (image promotionnelle). Cette image a en outre le défaut de laisser suggérer l’existence d’un bouton ‘accéder’ alors que ca n’est qu’un trompe l’œil. 
Le alt de cette image est renseigné ce qui par principe serait une non-conformité en vertu du critère 1.2. 
Mais, le contexte de cette image conduit à requalifier cette image. 
En effet, l’image est le contenu unique de la modale qui s’affiche à peine la connexion effectuée. Si on lui attribue un alt vide, alors les utilisateurs aveugles de lecteur d’écran vont subir l’ouverture d’une pop-up vide, qu’ils auront juste à fermer.
Cette situation produirait de la confusion pour les utilisateurs aveugles. 
Nous préconisons donc de considérer, à raison du contexte d’unique élément de la modale, que cette image est une image porteuse d’information. Puisqu’il s’agit d’une image texte, nous vous suggérons de produire comme alternative un texte stylé reprenant le texte de l’image. Cela permettra au moins de donner du sens à l’ouverture de la modale.
Vous pouvez également simplement supprimer cette modale qui n’apporte pas d’information particulière et possède un affichage trompeur (avec l’effet bouton qui n’est pas un réel élément cliquable et peut donc induire en erreur les personnes ayant des troubles cognitifs ou mentaux, ou même les utilisateurs d’eye-tracker qui ne naviguent qu’au clic et n’ont donc pas de possibilité de voir que l’élément n’est en réalité pas interactif).

Liens 

Non-conformité liée au critères 6.1 du RGAA 4.1 :

Il y a un problème concernant l’intitulé de plusieurs liens dans la page tableau de bord.
Précisément, les deux liens dans la rubrique « la caf m’informe ».
Ces liens possèdent des intitulés à rallonge, avec beaucoup de texte dedans.
Cela crée une surcharge d’information, pour les utilisateurs de lecteur d’écran.
De plus, vous avez implémenté un intitulé de lien qui apparaît comme tronqué (utilisation de …) alors qu’en réalité ces points de suspensions sont codés en dur dans le html. Indépendamment des conditions d’affichage de ces liens, aucun texte supplémentaire n’apparaîtra.
Du coup, nous déconseillons vivement de ne pas recourir à des points de suspensions dans un intitulé de lien. Si vous avez besoin de ces points de suspension, c’est que l’intitulé du lien est trop long.
Pour simplifier la compréhension et l’accessibilité de ces liens, vous devez mettre une majeure partie du texte dans des balises de paragraphe, et laisser deux liens plus succincts possédant des intitulés assez explicites pour que l’utilisateur en comprenne la destination.

Par exemple : 

 -Pour le lien concernant le mot de passe, vous pouvez utiliser le h1 de la page de destination du lien et puis mettre le reste du texte dans des balises <p>.

-Pour le lien concernant la déclaration aux impôts vous pouvez laisser la première phrase en tant que lien et le reste du texte dans des balises <p>.

Script 

Il y a, dans le périmètre, plusieurs problèmes concernant les scripts.

Non-conformité liée au critères 7.1 du RGAA 4.1 :

Sur la page mes paiements et droits, les boutons « précédant » et « suivant » liés au paiement et au droits de l’utilisateur, induisent un changement de date et de montant.  
L’utilisateur n’est pas informé de cette modification, car le focus n’est pas replacé sur les éléments actualisés.
Cela peut entrainer de la confusion chez les utilisateurs de lecteur d’écran, car les informations recherchées (le montant et la date) ne sont pas restituées immédiatement, il faut remonter dans le texte pour comprendre ce qui a été modifié.
Il faut bien replacer le focus dessus à chaque actualisation des données, afin d’améliorer la compréhension de la fonctionnalité de ces boutons, et d’éviter tout déperdition d’information. 

Non-conformité liée au critère 7.4 du RGAA 4.1 :
Sur la page Mes ressources annuelles, le système d’onglets (permettant d’afficher soit les ressources annuelles, soit les ressources trimestrielles, soit les ressources pour l’aide au logement) ne se trouve pas dans un contexte permettant de comprendre que la sélection du bouton radio correspondant à ce que l’on souhaite afficher va modifier le contenu entier de la page.
En effet, l’usage fait ici du système de boutons radio sort de l’utilisation classique qui est faite de ces derniers.
Les utilisateurs naviguant au lecteur d’écran (principalement aveugles et malvoyants) vont s’en retrouver grandement lésés, car ils vont devoir naviguer « à l’erreur » pour comprendre que le contenu de la page change entièrement selon leur utilisation de cet élément de la page.
Pour résoudre cela, il faut donc venir ajouter du contexte à cette implémentation, comme un passage de texte (qui sera lu par les lecteurs d’écran) avant cet élément ou une modification des étiquettes (exemple : « onglet ressources annuelles ») pour les rendre explicites concernant ce point.

Non-conformité liée au critère 7.3 du RGAA 4.1 :

Il y a deux problèmes liés à ce critère dans l’audit :

Premièrement :
Sur la page Mon agenda, les mois ne sont dépliables qu’avec la touche Enter au lieu de pouvoir être aussi dépliable avec la touche espace. 
Les utilisateurs qui naviguent au clavier doivent pouvoir utiliser indifféremment ces 2 touches pour activer les boutons.

Deuxièmement :
Sur la page Mes courriers, courriels, on trouve un système d’onglets pour naviguer entre l’historique des courriers-courriels et les messages non lus.
Du fait de son implémentation, en liste contenant des boutons, le focus n’est pas pris sur le premier bouton lorsque l’on navigue au clavier.
Les utilisateurs naviguant exclusivement au clavier n’ont aucun moyen d’accéder à ce système d’onglets. 
La recommandation que l’on fera ici est d’implémenter plutôt un système de boutons radio (comme dans la page Mes ressources annuelles). Cela va permettre la prise de focus sur l’élément pour les personnes naviguant au clavier, qui pourront en plus changer la sélection via les flèches de direction.
Cela va aussi régler un problème annexe : la cohérence d’implémentation entre les différentes pages. 
En effet, entre la page Mes ressources annuelles et cette page, on a deux systèmes d’onglets, qui ont donc le même but, mais qui sont implémentés de façon différente.
Ce changement de fonctionnement dans le site entre plusieurs pages est à éviter. 
Il est très pénalisant (impact majeur) pour différents utilisateurs handicapés tels que les personnes aveugles qui utilisent un lecteur d’écran, ou les utilisateurs ayant des problèmes de compréhension ou des handicaps cognitifs.
Ces utilisateurs se retrouvent actuellement forcés de deviner à chaque page le nouveau fonctionnement de celle-ci. 
Utiliser une implémentation cohérente (c’est-à-dire un élément = 1 fonctionnement unique et prévisible, qui ne diverge pas ou au minimum possible de l’utilisation habituelle) est donc primordial.

Formulaire 

Dans l’écran changement de mot de passe, les étiquette "mot de passe actuel" et "nouveau mot de passe" sont trop éloignées de leur champ respectif 
Cela impacte particulièrement les utilisateurs de loupe d’écran.
Vous devez accoler les champs de formulaires et leurs étiquettes, vous pouvez par exemple opérer un alignement vers la droite ou placer les champs à remplir immédiatement sous l’étiquette.

Navigation 

Sur les pages Mes ressources aide au logement, Mes démarches, changement de mot de passe et Mon agenda ; le lien d’évitement a un défilement (effet de scroll) qui va en bas de page et le focus qui n’est pas replacé au bon endroit. 
L’utilisation du lien d’évitement doit permettre de positionner le focus sur le contenu principal de la page directement. A ce repositionnement est classiquement ajouté un effet de scroll permettant d’afficher l’élément qui a le focus.
Dans la 1ère capture ci-dessus, après avoir activé le lien d’évitement, un effet de scroll est appliqué. Pour autant, le focus n’a pas été déplacé car après 1 tabulation, le focus est placé sur le lien ‘Accessibilité’. Or, cet élément est celui qui prend le focus immédiatement après le lien d’évitement.
Le lien d’évitement n’est donc pas fonctionnel, malgré l’effet de scroll. 
Les utilisateurs impactés sont principalement les personnes aveugles et celles navigant uniquement au clavier.
La deuxième capture ci-dessus nous montre que le défilement nous emmène en bas de page et non au début du contenu principal.
Cela affecte les utilisateurs navigant uniquement avec le clavier dans la mesure où le focus est repositionné dans un espace de la page qui n’est pas affiché. Cela est d’autant plus problématique que le 1er élément du contenu principal, sur lequel est positionné le focus suite à l’activation du lien d’évitement est un titre, et donc un élément non interactif. 
Si l’utilisateur tabule pour ajuster l’affichage sur l’endroit où le focus est positionné, il ne pourra pas rétrotabuler pour remonter effectivement au tout début de la zone de contenu principal.
Il faut donc s’assurer que le repositionnement du focus opéré par l’activation d’un lien d’évitement soit suivi d’un effet de scroll adéquat.

3. Conclusion

Avis de l’auditeur

Globalement, l’accessibilité de cet échantillon est assez satisfaisant.
Il n’y a pas beaucoup d’erreurs sur chacune des pages mais certaines sont très impactantes. Il s’agit ici principalement de soucis de contextes d’implémentation, plus que de véritables défauts dans l’implémentation même des composants.
Les correctifs prioritaires sont indiqués en rouge dans la grille d’audit. 
Une fois ces correctifs appliqués, le niveau d’accessibilité sera bon.
Les auditeurs ont ressenti les efforts fournis afin de rendre plus accessible le site.
Si besoin, nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport.

Nom du service numérique : CNAF
Date de l’audit : Juin 2021
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte    
Dérogations et éléments non testés    
Accessibilité du site    
2. Description des erreurs d’accessibilité    
Script
Eléments obligatoires
Navigation   
3. Conclusion    
Avis de l’auditeur

Introduction

Contexte

Le périmètre audité concerne le périmètre DTR-AAH.
La version utilisée pour réaliser les tests est la version <4.1> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.1 (incluant les scripts), sauf quelques exceptions indiquées ci-dessous.

Dérogations et éléments non testés

Dérogations :

Le critère 11.13 demandant le remplissage automatique des champs de saisie de formulaire via un autocomplete n’est pas audité car il est dérogé dans le contexte de la cnaf : les informations traitées étant très sensibles, la sécurité de ces données prévaut sur leur facilité d’accès.
Cette aide à l’auto-remplissage des champs (élément autocomplete) peut poser de graves brèches de sécurité en ce qui concerne la gestion des données personnelles des utilisateurs. Si une personne se connecte sur un réseau public sur le site de la CNAF et que l’autocomplete est implémentée, l’utilisateur suivant qui se connecterait sur le site de la CNAF bénéficierait, via le remplissage automatique, de l’ensemble des accès aux données personnelles de l’utilisateur précédent.
Cette situation critique est à éviter absolument, notamment en raison des exigences légales relatives à la gestion des données personnelles.
Ces enjeux ont été considérés comme supérieurs au gain en accessibilité que permettrait cette implémentation, la dérogation est donc accordée.

Eléments non testés :

- Les critères 13.3 et 13.4 sur les documents bureautiques ne seront pas mis en non-conformité quand il y a présence desdits documents. Les équipes de la CNAF nous ont remonté que, pour l’instant, les fichiers PDF générés lors des démarches des utilisateurs ne sont pas accessibles. Ils ne sont donc pas réaudités dans ce périmètre.
- Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9 et 13.12 n’ont ainsi pas pu être réalisés. De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés en raison de problèmes de connexion via VPN en environnement mobile, ce test ne peut donc pas être performé pour l’instant.
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 89.0 (64 bits)
- Google chrome : V91.0.4472.101 (Build officiel) (64 bits)

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular
Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2
La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.1 :
L’audit a porté sur un échantillon de 8 pages.
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est globalement moyen.
Le taux de conformité sur l’échantillon globale est d’environ 71,74% (calcul effectué sans la prise en compte du nombre de critère non-applicable). 
Le taux de conformité moyen par pages est quant à lui de 82,76%.
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.1, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendants de l’implémentation de l’écran et de chacun de ses composants. N’étant pas voyants, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitaient d’être détaillées en dehors de la seule grille d’audit.

Scripts

Non-conformités correspondant au critères 7.1 du RGAA 4.1 :
Il y a des problèmes concernant les scripts dans le périmètre,
1- Dans les écrans « fin de perception », il y a des calendriers.
Il n’est pas nécessaire que l’utilisateur puisse naviguer dans ces calendriers qui ne sont pas accessibles, cela rend le remplissage de la date plus complexe.
De plus, ces calendriers possèdent une alternative : un champ de formulaire permettant de rentrer la date manuellement.
Les utilisateurs de lecteur d’écran ainsi que les personnes ayant des problèmes de compréhension dus à un handicap mental sont impactés, car la navigation dans le tableau est difficile.
Vous devez donc « cacher » ces calendriers aux lecteurs d’écran à l’aide d’un attribut Aria-hidden= true ainsi qu’un
Tabindex -1 permettant d’empêcher l’accès à la tabulation.

2- Dans l’écran final une zone de texte dépliable est repliée par défaut. Le composant qui permet d’ouvrir la zone ne prend pas le focus est n’est donc pas accessible au clavier. Le contenu de cette zone n’est donc pas accessible pour les personnes qui naviguent au clavier.
Pour réparer cette implémentation, nous vous conseillons d’utiliser un motif aria-disclosure (aria-expanded) tout en prenant soin de rendre focusable l’élément permettant de déplier le champ.

Éléments obligatoires

Le titre de page des pages du processus n’est pas assez précis. On ne connait pas l’étape dans laquelle on se trouve. 
Cela va poser un problème majeur pour les personnes aveugles.
En effet, ce sont des utilisateurs qui ont un besoin important de contexte pour pouvoir naviguer sur des sites, notamment dans le cadre de processus comptant plusieurs étapes et parfois plusieurs pages par étape.
Par exemple : la capture ci-dessous montre le title d’une des pages de saisie des ressource Toutes les pages du processus ont ce title.
Pour rendre ce title pertinent, ajoutez en fin de title une référence à l’étape en cours.

Navigation

Non-conformité correspondant au critères 12.8 du RGAA 4.1 :
Dans plusieurs écrans du périmètre, l’implémentation des champs de formulaires modifie l’ordre de la tabulation d’une façon qui n’est pas cohérente.
En effet, les champs possèdent des attributs tabindex avec des valeurs positives, ce qui priorise l’accès à la tabulation de ces champs.
Ils sont donc les premiers éléments de l’écran à prendre le focus. 
L’ordre de tabulation créé à l’aide de ces attribut tabindex rend la compréhension de la page plus difficile, surtout quand les champs de formulaires concernés sont dans des tableaux. Dans cet échantillon, les groupe de boutons radio sont aussi concerner par ces soucis de tabindex.
En effet, les champs sont restitués avant même le menu de navigation. Lorsque l’utilisateur arrive enfin au tableau dans la page et accède aux entêtes du tableau, ils n’ont plus accès aux champs de formulaires, restitués très en amont. La même remarque s’applique pour les boutons radio. Cela rend le remplissage très fastidieux et peu intuitif pour les personnes aveugles navigant au clavier.
Il faut supprimer les valeurs positives des tabindex pour pouvoir rétablir un ordre de tabulation cohérent et une meilleure compréhension de la page pour les utilisateurs de lecteurs d’écran.

3. Conclusion
Avis de l’auditeur
Globalement, l’accessibilité de cet échantillon est assez moyenne.

Le processus semble un peu daté. Auditer des processus moins récents permet néanmoins d’apprécier les nombreux efforts déployés pour rendre le site de la CAF toujours plus accessible.
Actuellement l’erreur la plus impactante concerne l’attribution de tabindex ayant des valeurs positives aux champs de formulaires.
Les correctifs prioritaires sont indiqués en rouge dans la grille d’audit. 
Une fois ces correctifs appliqués, le niveau d’accessibilité sera bon.
Nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport.

Nom du service numérique : CNAF
Date de l’audit : Mars - Avril 2021
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte    
Dérogations et éléments non testés    
Accessibilité du site    
2. Description des erreurs d’accessibilité  
Images  
Script
Eléments obligatoires
Formulaires
Navigation   
3. Conclusion    
Avis de l’auditeur

1. Introduction

Contexte

Le périmètre audité concerne le périmètre DAL Primo. Il s’agit d’un réaudit.
La version utilisée pour réaliser les tests est la version <4.1> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.1 (incluant les scripts), sauf quelques exceptions indiquées ci-dessous.

Dérogations et éléments non testés

Dérogations : 

Le critère 11.13 demandant le remplissage automatique des champs de saisie de formulaire via un autocomplete n’est pas audité car il est dérogé dans le contexte de la cnaf : les informations traitées étant très sensibles, la sécurité de ces données prévaut sur leur facilité d’accès.
Cette aide à l’auto-remplissage des champs (élément autocomplete) peut poser de graves brèches de sécurités en ce qui concerne la gestion des données personnelles des utilisateurs. Si une personne se connecte sur un réseau public sur le site de la CNAF et que l’autocomplete est implémentée, l’utilisateur suivant qui se connecterait sur le site de la CNAF bénéficierait, via le remplissage automatique, de l’ensemble des accès aux données personnelles de l’utilisateur précédent.
Cette situation critique est à éviter absolument, notamment en raison des exigences légales relatives à la gestion des données personnelles.
Ces enjeux ont été considérés comme supérieurs au gain en accessibilité que permettrait cette implémentation, la dérogation est donc accordée.

Eléments non testés :

-    Les critères 13.3 et 13.4 sur les documents bureautiques ne seront pas mis en non-conformité quand il y a présence desdits documents. Les équipes de la CNAF nous ont remonté que, pour l’instant, les fichiers PDF générés lors des démarches des utilisateurs ne sont pas accessibles. Ils ne sont donc pas réaudités dans ce périmètre.
-    Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9 et 13.12  n’ont ainsi pas pu être réalisés. De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés en raison de problèmes de connexion via VPN en environnement mobile, ce test ne peut donc pas être performé pour l’instant.
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 80.0.1 (64 bits)
- Google chrome : V 85.0.4183.83 (Build officiel) (64 bits)

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular

Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2

La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.1 :
-     Non visual Desktop Access (NVDA) ; Version 2020.
L’audit a porté sur un échantillon de 22 pages. 
 

2 grilles d’audit sont annexées à ce rapport, elles contiennent les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est globalement bon.

Le taux de conformité est d’environ 84% (calcul effectué sans la prise en compte du nombre de critère non-applicable). Nous constatons qu’une bonne partie des non-conformité est liée à l’évolution vers la version 4 du RGAA.
Nous précisons que les éléments relevant du thème des écrans ont été externalisés de cet audit, vers un fichier word annexé au présent document. Ces éléments, hors de la charge de l’équipe DAL primo, n’ont donc pas été intégrés dans les grilles et donc dans le taux de conformité de l’échantillon. 
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.1, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendant de l’implémentation de l’écran et de chacun de ses composant. N’étant pas voyant, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitait d’être détaillées en dehors de la seule grille d’audit.

Images

Dans les étapes de récapitulatif ou de fin où il y a des images lien représentant un crayon (pour modifier les données), l’alternative de la première image de crayon est collée à un passage de texte "Crayon" visible uniquement pour les lecteurs d'écran.
C'est une bonne idée, seulement le texte choisi manque de cohérence avec les alternatives des autres boutons de crayon, qui ne contiennent pas d’élément en commun.
Pour les personnes aveugles utilisant des lecteurs d’écran, cela va créer une confusion.
Il doit y avoir au moins un élément en commun entre ces alternatives qui permette aux personnes aveugles de comprendre qu'il s'agit effectivement du bouton de modification des données qu'elles retrouvent plus tard dans la page.

Scripts

Dans l’échantillon audité, il y a des problèmes en lien avec les scripts. 
Pour les boutons de passage aux pages suivantes ou précédentes, l’intitulé accessible n’est pas cohérent avec l’intitulé visible.
En effet, sur certaines pages, il y a un title cohérent aux boutons, mais un aria-label qui ne reprend pas au minimum le texte visible du bouton. 
Comme la propriété aria-label écrase la propriété title, si elle ne reprend pas au minimum le contenu visible du bouton, les utilisateurs naviguant via des commandes vocales par exemple peuvent avoir des problèmes de navigation.
Ils vont chercher à sélectionner le bouton en utilisant le texte de l’aria-label, mais leur outil ne trouvera pas le bouton demandé.
Faites-en sorte que l’aria-label dans ces cas reprenne au minimum l’intitulé visible du bouton.

Eléments obligatoires

Les titre des pages manquent de précision ou ne correspondent pas à la page. En effet, lorsque l’on est dans un processus, il est recommandé de préciser dans le title de la page l’étape à laquelle se situe l’utilisateur (et s’il y a plusieurs écrans dans une même étape, typiquement dans une étape de saisie, de numéroter ces écrans).
Les utilisateurs qui naviguent avec un lecteur d’écran ont des raccourcis leur permettant de restituer en cours de page le title de la page sur laquelle ils se situent. Cela leur permet de retrouver le contexte de leur navigation dans le site, à tout moment.  
Lorsque les titres ne sont pas pertinents, il y a une perte importante d’information pour l’utilisateur.

Un autre problème présent au niveau des éléments obligatoires est la rédaction de paragraphes dans des balises div ou des labels plutôt que des balises de paragraphe.
Dans le cas de balises div, elles ne vont pas être lues par les lecteurs d’écran.
Dans le cas des labels, bien qu’ils soient lus, leur implémentation diffère de l’utilisation habituelle pour les utilisateurs de lecteurs d’écran, ce qui va donc entrainer une confusion.
Mettez les textes dans des balises p.

Formulaires

Les champs obligatoires : 
Les formulaires de la CNAF contiennent de nombreux champs obligatoires. 
2 réflexes doivent donc être pris par les équipes de développement : indiquer les champs obligatoires par un message précédant le champ (ou le regroupement de champ) et bien relier les messages d’erreurs aux champs non remplis ou mal remplis. 
1/ l’indication que les champs sont obligatoires :
Cela permet aux utilisateurs voyants et aveugles de ne pas rester bloqués indéfiniment dans un écran à la recherche du champ obligatoire qu’ils n’auraient pas renseigné. 
Pour satisfaire cette obligation, il faut penser d’une part aux utilisateurs voyants et d’autre part aux utilisateurs non-voyants.
Pour les utilisateurs voyants : une indication visible des champs obligatoires doit être fournie. Elle peut concerner chaque champ obligatoire isolément, ou un regroupement de champ, ou même consister en une indication en haut de page lorsque tous les champs sont obligatoires. 
En arrivant sur l’écran, aucune mention ne précise qu’il faut choisir un des champs avant de cliquer sur le bouton continuer. Cet élément est pourtant crucial car le fait de cliquer sur les champs va permettre de déplier tous les champs de formulaires pertinents placés dans l’écran. 
En l’état, un utilisateur peut avoir l’impression qu’il peut passer la page en appuyant sur continuer, apparaîtra alors le message d’erreur, postérieurement à l’essai de validation du formulaire. 
Ici, les utilisateurs non-voyants, qui utilisent un lecteur d’écran reçoivent bien l’information que le champ est obligatoire en raison de l’implémentation de l’attribut required. Il serait toutefois préférable de relier aux champs le message indiquant aux utilisateurs voyant que les champs sont obligatoires.

2/ Bien relier les messages d’erreurs aux champs en erreur 
Ici, les utilisateurs impactés sont principalement les personnes aveugles, qui ne vont pas pouvoir accéder aux indications visuelles que nous avons lorsque nous ne remplissons pas ou que nous remplissons mal les champs obligatoires. Ils ne voient pas les messages d’erreurs ni les bordures rouges des champs. 
Il est donc primordial de bien relier chaque message d’erreur avec le champ effectivement en erreur.
Visuellement, il est évident que le texte en rouge se rapporte aux champs dont le contour est rouge. 
Pourtant, dans l’implémentation, l’Id du texte d’erreur n’est pas relié par la propriété aria-describedby aux champs en erreur. Les utilisateurs aveugles n’ont donc pas accès à cette information en temps utiles et de manière fonctionnelle. 
Puisque l’accès à l’écran suivant est conditionné par le fait de remplir correctement ces champs, il est très important de faciliter la compréhension des erreurs aux personnes utilisatrices d’un lecteur d’écran. 

Navigation

Dans certaines pages, comme la première page de saisie, les paragraphes de texte ont été implémentés avec un tabindex=0.
Cela force la tabulation sur ces textes.
C’est quelque chose qui n’est pas nécessaire, mais surtout, qui diverge de la navigation classique pour les lecteurs d’écrans. En effet, les personnes utilisant le lecteur d’écran à titre habituel ne cherchent pas les textes avec la tabulation mais avec des raccourcis spécifiques. Le fait que les passages de textes ne prennent pas le focus ne les prive pas de restitution.
Il faut noter qu’en restitution, un élément avec une propriété tabindex est retranscrit come ‘cliquable’. Ce qui n’est pas le cas des textes. Les tabindex doivent donc être utilisés seulement sur les éléments interactifs. 
En conclusion, la prise de focus inhabituelle des textes va induire en confusion l’utilisateur.
Retirez ces tabindex sur les paragraphes de textes.

3. Conclusion

Avis de l’auditeur

Globalement, l’accessibilité de cet échantillon est tout à fait satisfaisante.
Il reste quelques erreurs à corriger, parfois répétées dans plusieurs écrans, une correction générale devrait résoudre une partie des problématiques.
De nouvelles erreurs sont apparues suite à l’évolution du RGAA, elles n’avaient donc pas pu être révélées lors du 1er audit. 
Les efforts suite au premier passage ont été constatés par l’équipe d’audit. 
Nous avons externalisé les non-conformités remontées qui concernaient le thème du site, dans un fichier annexé au présent document. 
Si besoin, nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport.

Nom du service numérique : CNAF
Date de l’audit : Décembre 2020 – Février 2021
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte       
Accessibilité du site    
2. Description des erreurs d’accessibilité        
Formulaire     
Navigation     
3. Conclusion    
Avis de l’auditeur

1. Introduction

Contexte

Le périmètre audité concerne le périmètre AVI (Avantages Vieillesse et Invalidité).
La version utilisée pour réaliser les tests est la version <4.0> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.0 (incluant les scripts).

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 80.0.1 (64 bits)
- Google chrome : V 85.0.4183.83 (Build officiel) (64 bits)

Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9 et 13.12 n’ont ainsi pas pu être réalisés. 
De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés. 
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular

Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2

La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.0 :
- Non visual Desktop Access (NVDA) ; Version 2020.

L’audit a porté sur un échantillon de 5 pages. 
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est globalement bon.
Le taux de conformité est d’environ 86% (calcul effectué sans la prise en compte du nombre de critères non-applicables).
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.0, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendant de l’implémentation de l’écran et de chacun de ses composant. N’étant pas voyant, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitait d’être détaillées en dehors de la seule grille d’audit.

Scripts

Dans l’échantillon audité, il y a 2 problèmes principaux en lien avec les scripts. 

1/ Des boutons radio ne sont pas activables via les flèches du clavier.
Bien qu’ils soient activables individuellement via le bouton espace, les boutons radio doivent être activables via les flèches directionnelles du clavier, et que l’on puisse passer de l’un à l’autre de cette manière.
Cela va impacter les personnes naviguant au clavier, qu’elles utilisent un navigateur d’écran ou non, car elles vont avoir du mal à activer le composant souhaité.
Les input de type radio qui font partie du même groupement doivent avoir une propriété name avec la même valeur afin que les flèches de direction puisse fonctionner.

2/ La restitution des intitulés de ces boutons radio est faite 4 fois avec les lecteurs d’écran.
En effet, quand on utilise les boutons radio « Mensuel » ou « Trimestriel », le lecteur d’écran restitue respectivement : « mensuel mensuel mensuel mensuel bouton radio » puis l’état du bouton ou « trimestriel trimestriel trimestriel trimestriel bouton radio » puis l’état du bouton.
Cela provoque une surcharge pour l’utilisateur, et peut dont l’induire en erreur.

En regardant dans le code, rien de particulier ne semble expliquer ce problème, mais peut être que vos développeurs sauront trouver la source.

Elément obligatoire

Il y a des ID dupliqués dans les pages, cela impacte les utilisateurs de lecteur d’écran, et autres technologies d’assistance qui se basent sur les IDs pour gérer la navigation dans le contenu : des liaisons peuvent être rompue ou incorrecte.
Par exemple, avec une liaison aria-describedby, un message d’erreur relié à plusieurs champs comportant le même Id serait restitué sur l’ensemble des champs, même ceux qui ne sont pas en erreur. Cela provoquerait des difficultés pour le remplissage des champs en erreur
Retirer les doublons va donc permettre d’éviter ce genre de situations.
 
Présentation

Dans la page FIN_DEMANDE, en mode contrastes renforcés, les liens dans les textes sont mis en noir ce qui les rend non visibles.
Les personnes utilisant le mode renforcé ne verront pas qu’il y a des liens et ne pourront pas accéder au contenu et fonctionnalité associées. 

Formulaires

Les formulaires de la CNAF contiennent de nombreux champs obligatoires. 
2 réflexes doivent donc être pris par les équipes de développement : indiquer les champs obligatoires par un message précédant le champ (ou le regroupement de champ) et bien relier les messages d’erreurs aux champs non remplis ou mal remplis. 
1/ l’indication que les champs sont obligatoires :
Cela permet aux utilisateurs voyants et aveugles de ne pas rester bloqués indéfiniment dans un écran à la recherche du champ obligatoire qu’ils n’auraient pas renseigné. 
Pour satisfaire cette obligation, il faut penser d’une part aux utilisateurs voyant et d’autre part aux utilisateurs non-voyants.
Pour les utilisateurs voyants : une indication visible des champs obligatoire doit être fournie. Elle peut concerner chaque champ obligatoire isolément, ou un regroupement de champ, ou même consister en une indication en haut de page lorsque tous les champs sont obligatoires. 
En arrivant sur l’écran, aucune mention ne précise qu’il faut choisir un des champs avant de cliquer sur le bouton continuer. Cet élément est pourtant crucial car le fait de cliquer sur les champs va permettre de déplier tous les champs de formulaires pertinents placés dans l’écran. 
En l’état, un utilisateur peut avoir l’impression qu’il peut passer la page en appuyant sur continuer, apparaîtra alors le message d’erreur, postérieurement à l’essai de validation du formulaire. 
Ici, les utilisateurs non-voyants, qui utilisent un lecteur d’écran reçoivent bien l’information que le champ est obligatoire en raison de l’implémentation de l’attribut required. Il serait toutefois préférable de relier aux champs le message indiquant aux utilisateurs voyant que les champs sont obligatoires.

2/ Bien relier les messages d’erreurs aux champs en erreur 
Ici, les utilisateurs impactés sont principalement les personnes aveugles, qui ne vont pas pouvoir accéder aux indications visuelles que nous avons lorsque nous ne remplissons pas ou que nous remplissons mal les champs obligatoires. Ils ne voient pas les messages d’erreurs ni les bordures rouges des champs. 
Il est donc primordial de bien relier chaque message d’erreur avec le champ effectivement en erreur.
Visuellement, il est évident que le texte en rouge se rapporte aux champs dont le contour est rouge. 
Pourtant, dans l’implémentation, l’Id du texte d’erreur n’est pas relié par la propriété aria-describedby aux champs en erreur. Les utilisateurs aveugles n’ont donc pas accès à cette information en temps utiles et de manière fonctionnelle. 
Puisque l’accès à l’écran suivant est conditionné par le fait de remplir correctement ces champs, il est très important de faciliter la compréhension des erreurs aux personnes utilisatrices d’un lecteur d’écran. 

3. Conclusion

Avis de l’auditeur

Globalement, l’accessibilité de cet échantillon est très satisfaisante.
Il reste quelques erreurs à corriger, parfois répétées dans plusieurs écrans, une correction générale devrait résoudre une partie des problématiques.
Etant donné l’importance des formulaires dans ce périmètre, il semble pertinent de corriger en priorité les erreurs de cette thématique. 
Si besoin, nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport.

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte    
Accessibilité du site    
2. Description des erreurs d’accessibilité  
Couleurs
Scripts 
Formulaires    
Navigation    
3. Conclusion    
Avis de l’inspecteur

1. Introduction

Contexte

Le périmètre Demande d’ASF-Addendum est un audit complémentaire à l’audit du scenario principal Demande d’ASF, réalisé en août 2020 sur la base du RGAA3.

La version utilisée pour réaliser les tests de cet audit est la version 4.0 du RGAA.
Le thème du site n’a pas été audité pour ce périmètre, l’audit a porté sur le contenu principal des écrans.  
Cet audit comprend l’ensemble des rubriques et des critères du RGAA 4.0 (y compris les scripts).

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 80.0.1 (64 bits)
- Google chrome : V 85.0.4183.83 (Build officiel) (64 bits)

Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9 et 13.12 n’ont ainsi pas pu être réalisés. 
De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés. 
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular

Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2

La restitution des contenus avec les technologies d’assistance a été testée avec :
- Non Visual Desktop Access (NVDA) ; Version 2020.

L’audit a porté sur un échantillon de 5 pages.
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est globalement bon. 
Le taux moyen de conformité est d’environ 70%. Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.0, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme. 

Un taux de 70% est plutôt satisfaisant eu égard au fait qu’il s’agit du 1er audit utilisant le RGAA 4.0 comme référentiel (il y a donc naturellement eu de nouveaux critères ajoutés auxquels les développeurs n’ont pas encore l’habitude). De plus, nous avons audité les scripts que nous n’auditions pas auparavant. De nouvelles causes de non-conformités sont donc remontées avec cet audit. 

Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendant de l’implémentation de l’écran et de chacun de ses composant. N’étant pas voyant, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants. 
Les utilisateurs mal-voyants sont également impactés par certaines erreurs, notamment concernant les contrastes des composants graphiques et les éléments relatifs aux infobulles. 
    
2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitait d’être détaillées en dehors de la seule grille d’audit.

Couleurs

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.
Un nouveau critère est apparu avec le RGAA 4.0 : le nouveau critère 3.3 qui dispose que « Dans chaque page web, les couleurs utilisées dans les composants d'interface ou les éléments graphiques porteurs d'informations sont-elles suffisamment contrastées ? »
Alors qu’auparavant seuls étaient concernés par le contraste de couleurs les textes et leur arrière-plan, désormais, les éléments graphiques interactifs ou porteurs d’information doivent également avoir un ratio de contraste suffisant (3.1 au moins) avec leur arrière-plan. 
De plus, ces composants d’interface doivent être testés dans leurs différents états (inactif, survol, prise de focus, déjà visité pour les liens). 
Le passage d’un état de composant à un autre (typiquement l’activation, le focus) doit également être visible, en suivant un ratio de contraste de 3.1.
Les utilisateurs impactés vont être ceux qui ne distinguent pas bien les couleurs ou ceux qui ont une basse vision. Il va s’agir de s’assurer qu’ils perçoivent bien les composants de l’interface avec lesquels ils vont être amenés à interagir, et qu’ils sont en mesure de différencier les différents états des composants. 
Puisque la CAF a instauré un mécanisme de remplacement pour pallier l’insuffisance de ratio de la charte graphique normale, nous avons audité ce critère principalement en mode contrastes renforcés. 
L’image de l’infobulle quand le composant est inactif n’a pas un contraste suffisant avec le fond blanc du bouton sur lequel elle est placée. De la même manière, le point d’interrogation, qui renseigne les utilisateurs voyant sur le fait que le composant fournit de l’aide, n’a pas un contraste suffisant avec la couleur de l’image. 
Le ratio entre le blanc et le gris est de 2.14. Il devrait être de 3.1 au minimum. 
Ainsi, certains utilisateurs peuvent ne pas vraiment percevoir l’image ronde du bouton de l’infobulle, et/ou ne pas distinguer le point d’interrogation en son centre. Visuellement, cet utilisateur ne comprend pas la nature du composant. 
A gauche, le bouton est survolé, à droite il ne l’est pas. La différence d’état est quasi imperceptible. 
Ici, il faut regarder le ratio de contraste entre le noir et le gris très foncé. Elle est de 1.55. Il faudrait que le contraste soit de 3.1 au minimum afin que les utilisateurs puisse réellement voir le changement d’état. 

Scripts

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.
Dans l’échantillon audité, il y a 2 problèmes principaux en lien avec les scripts. 

1/ L’absence d’indication concernant le changement de contexte sur le bouton continuer.

Tout en bas chaque écran, il y a un bouton continuer permettant d’accéder à l’écran suivant du processus en cours.
Ce bouton est immédiatement précédé dans l’ordre de tabulation par 2 autres boutons : 
    Un bouton précédent dont le title est « Retour à la page précédente » 
    Un bouton Quitter dont le title est « Quitter l’application ».
Le bouton continuer a quant à lui « continuer » pour title.

Or, en appuyant sur ce bouton, l’utilisateur va être placé dans un nouvel écran, il y a donc changement du contexte dans lequel il se situe. 
Or, les utilisateurs aveugles ne sont pas en mesure de voir qu’une nouvelle page est affichée.
L’absence de précision quant à ce changement de contexte va ainsi éventuellement perturber les utilisateurs aveugles qui ne retrouveront pas les éléments de la page en cours.

Le fait que les 2 boutons précédents aient un title indiquant clairement le changement de contexte rend l’intitulé du bouton « Continuer » non pertinent.

Nous préconisons donc de remplacer le title actuel par « Continuer vers la page suivante », sur l’ensemble des pages du processus. 

La non-conformité de ce critère fait également écho au fait que les title des pages ne sont pas suffisamment précis. 
En effet, la non-conformité du critère 8.6 repose sur le fait que les différents écrans du périmètre se situent en cours d’un processus mais que l’endroit exact de situation de l’écran dans le processus n’est pas fourni par le title de la page (« CAF - Mon Compte - Demander une prestation »). 

Il faudrait préciser la nature de la prestation demandée ainsi que l’étape du processus en cours afin de permettre aux utilisateur aveugles de retrouver plus facilement du contexte lors des changements de page ou en cours de navigation (un raccourci clavier permet aux utilisateurs de lecteur d’écran de relire à tout moment le title de la page en cours).

2/ L’implémentation des infobulles.

Les infobulles présentes dans le périmètre ont des problématiques communes. 
 
L’intitulé des infobulles.
Chacune des infobulles de l’échantillon a pour intitulé l’alt de l’image : « Information supplémentaire ». Or, cet intitulé ne permet pas en soi de comprendre à quoi se rattachent les informations supplémentaires puisque le bouton des infobulles arrive avant le label des boutons principaux dans l’ordre de tabulation. 
Le lecteur d’écran restitue ainsi d’abord l’indication d’un élément intitulé « informations supplémentaires » avant de lire le label du bouton concerné. 
Les utilisateurs aveugles manquent donc de contexte pour comprendre la nature des informations qu’il trouvera en activant le bouton de l’infobulle.
Ici, l’intitulé du bouton est trop long pour être repris dans l’intitulé de l’infobulle. Il semble dès lors pertinent de demander à inverser l’ordre de tabulation pour que le label des boutons comprenant les infobulles soit restitué en premier. Cela permettra aux personnes aveugles utilisant un lecteur d’écran d’avoir un support de contexte pour comprendre la destination du bouton. 

L’absence de prise de focus dans les infobulles
Une fois activée, avec la touche espace ou entrée, l’infobulle s’affiche. Elle contient un bouton de fermeture ainsi qu’un texte. Ces éléments sont restitués au lecteur d’écran, à condition que l’utilisateur ne touche aucune touche à l’exception d’entrée et d’espace, et qu’il ne clique nulle part. 
Ainsi, alors qu’il y a un bouton à l’intérieur de l’infobulle, le focus n’y pénètre jamais. Il n’est donc pas possible aux utilisateurs de lecteur d’écran de naviguer entre les différents conteneurs de l’infobulle (le bouton et les éléments de la liste).
Il serait préférable de permettre au focus d’intégrer l’intérieur de l’infobulle afin de faciliter la navigation avec les lecteurs d’écran. 

L’événement d’ouverture de l’infobulle (critère 13.11)
Le dernier élément problématique avec les infobulles est que l’événement permettant l’ouverture de l’infobulle avec un dispositif de pointage (par exemple la souris) est l’événement descendant. 
Le nouveau critère 13.11, instauré avec le RGAA 4.0 dispose que « Dans chaque page web, les actions déclenchées au moyen d'un dispositif de pointage sur un point unique de l'écran peuvent-elles faire l'objet d'une annulation ».
Les utilisateurs protégés par ce critère sont ceux navigant avec une forte loupe d’écran, qui vont avoir tendance à se déplacer grâce à leur dispositif de pointage, ou bien encore les personnes atteintes d’un trouble de la motricité qui peuvent cliquer par mégarde sur des éléments de l’écran. 
L’idée est par principe d’implémenter les éléments interactifs de manière à ce que l’action se produise lorsque le dispositif de pointage est relâché ou relevé (concrètement, quand on relève le doigt de la souris). 
Usuellement, les utilisateurs qui cliquent par mégarde sur un bouton ou un lien et ne souhaite pas l’ouvrir, bougent le curseur en dehors de la zone de clic et ainsi n’activent pas le composant sur lequel le clic a été pressé. Cette stratégie est mise à l’honneur dans le RGAA 4.0.
Il existe néanmoins des cas particuliers, lorsque par exemple il est logique que l’interaction avec le composant se fasse quand le dispositif de pointage est posé ou pressé (ex : un clavier virtuel, un champ dans lequel on dessine, un champ de signature…).

Dans le cas qui nous intéresse des infobulles. L’implémentation choisie est celle d’un bouton. 
Pour l’ensemble des autres boutons de la page, l’action se produit bien lorsque le dispositif de pointage est relâché sur la zone d’activation du composant.
Le déclenchement des infobulles se fait quant à lui sur l’élément descendant. 
L’event choisi est mousedown. 
Il n’est d’ailleurs pas possible de faire une capture d’écran de ces infobulles car tout clic sur l’écran les fait disparaitre, ainsi que le fait de presser n’importe quelle touche en dehors d’entrée et d’espace. 
Sauf raison particulière qui nous aurait échappée, il ne nous apparait pas nécessaire d’avoir inversé pour ces infobulles le mode usuel d’activation avec dispositif de pointage.
Nous préconisons donc de revenir à une implémentation plus classique de bouton. Cela permettrait une navigation plus aisée pour les personnes à très basse vision utilisant une très forte loupe d’écran et ceux qui ont des problèmes de motricité.

Formulaires

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.
Les formulaires de la CNAF contiennent de nombreux champs obligatoires. 
2 réflexes doivent donc être pris par les équipes de développement : indiquer les champs obligatoires par un message précédant le champ (ou le regroupement de champs) et bien relier les messages d’erreur aux champs non remplis ou mal remplis. 
1/ l’indication que les champs sont obligatoires :
Cela permet aux utilisateurs voyants et aveugles de ne pas rester bloqués indéfiniment dans un écran à la recherche du champ obligatoire qu’ils n’auraient pas renseigné. 
Pour satisfaire cette obligation, il faut penser d’une part aux utilisateurs voyant et d’autre part aux utilisateurs non-voyants.
Pour les utilisateurs voyants : une indication visible des champs obligatoire doit être fournie. Elle peut concerner chaque champ obligatoire isolément, ou un regroupement de champ, ou même consister en une indication en haut de page lorsque tous les champs sont obligatoires. 

En arrivant sur l’écran, aucune mention ne précise qu’il faut choisir un des champs avant de cliquer sur le bouton continuer. Cet élément est pourtant crucial car le fait de cliquer sur les champs va permettre de déplier tous les champs de formulaire pertinents placés dans l’écran. 
En l’état, un utilisateur peut avoir l’impression qu’il peut passer la page en appuyant sur continuer, apparaîtra alors le message d’erreur, postérieurement à l’essai de validation du formulaire. 

Ici, les utilisateurs non voyants, qui utilisent un lecteur d’écran reçoivent bien l’information que le champ est obligatoire en raison de l’implémentation de l’attribut required. Il serait toutefois préférable de relier aux champs le message indiquant aux utilisateurs voyants que les champs sont obligatoires.
2/ Bien relier les messages d’erreur aux champs en erreur 
Ici, les utilisateurs impactés sont principalement les personnes aveugles, qui ne vont pas pouvoir accéder aux indications visuelles que nous avons lorsque nous ne remplissons pas ou que nous remplissons mal les champs obligatoires. Ils ne voient pas les messages d’erreur ni les bordures rouges des champs. 
Il est donc primordial de bien relier chaque message d’erreur avec le champ effectivement en erreur.
Visuellement, il est évident que le texte en rouge se rapporte aux champs dont le contour est rouge. 
Pourtant, dans l’implémentation, l’Id du texte d’erreur n’est pas relié par la propriété aria-describedby aux champs en erreur. Les utilisateurs aveugles n’ont donc pas accès à cette information en temps utile et de manière fonctionnelle. 
Puisque l’accès à l’écran suivant est conditionné par le fait de remplir correctement ces champs, il est très important de faciliter la compréhension des erreurs aux personnes utilisatrices d’un lecteur d’écran. 

Navigation

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.
Le thème de l’échantillon n’a pas été traité lors de ce complément d’audit.
Le principal problème ici est le fait que le lien d’évitement « aller au contenu » n’est pas actif. 
Ce lien est très important pour les personnes qui ne peuvent utiliser que leur clavier pour naviguer dans la page (notamment les aveugles avec un lecteur d’écran, ou les personnes avec une mobilité ne permettant pas d’utiliser une souris ou un dispositif de pointage). 
Ce lien permet d’éviter de tabuler sur l’ensemble du menu de navigation, pour arriver directement dans le contenu. 
Il est donc important de le rendre fonctionnel.  

3. Conclusion

Avis de l’inspecteur

Comme indiqué en introduction, l’accessibilité de cet échantillon est globalement bonne. 
En cours d’audit, les efforts faits pour se conformer au RGAA 3 ont été ressentis. Globalement les implémentations natives ont été respectées, et les modifications par l’utilisation de role ont été correctement gérées dans l’ensemble.  
Il reste quelques erreurs à corriger sans que les correctifs à apporter ne semblent particulièrement difficiles ou longs. De plus, les erreurs étant pour la majorité communes aux différents écrans, une vague de correction devrait être suffisante. 
De nouvelles non-conformités sont apparues du fait de l’ajout de nouveaux critères, il faudra sûrement encore un peu de temps avant que les équipes ne soit parfaitement au fait de ces évolutions mais la navigation dans l’échantillon permet d’être optimiste quant au fait d’atteindre rapidement ce résultat. 
Au vu de l’architecture générale du site, dans lequel les formulaires sont nombreux et variés, un soin tout particulier doit vraiment être apporté à la correction des erreurs dans cette rubrique. 

Si besoin, nous sommes ouverts à une discussion avec les équipes pour expliciter les recommandations de la grille d’audit ou les éléments contenus dans ce rapport d’audit. 

Nom du service numérique : CNAF
Date de l’audit : Février-Mars 2021
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte  
Dérogation et éléments non testés 
Accessibilité du site    
2. Description des erreurs d’accessibilité 
Scripts
Elément obligatoire
Structuration   
Formulaires    
Navigation    
3. Conclusion  
Avis de l'inspecteur 

1. Introduction

Contexte

Le périmètre audité concerne le périmètre des pages éditoriales ARIPA
La version utilisée pour réaliser les tests est la version <4.1> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.0 (incluant les scripts), sauf quelques exceptions indiquées ci-dessous.

Dérogations et éléments non testés

Dérogations :

Le critère 11.13 demandant le remplissage automatique des champs de saisie de formulaire via un autocomplete n’est pas audité car il est dérogé dans le contexte de la cnaf : les informations traitées étant très sensibles, la sécurité de ces données prévaut sur leur facilité d’accès.
Cette aide à l’auto-remplissage des champs (élément autocomplete) peut poser de graves brèches de sécurité en ce qui concerne la gestion des données personnelles des utilisateurs. Si une personne se connecte sur un réseau public sur le site de la CNAF et que l’autocomplete est implémentée, l’utilisateur suivant qui se connecterait sur le site de la CNAF bénéficierait, via le remplissage automatique, de l’ensemble des accès aux données personnelles de l’utilisateur précédent.
Cette situation critique est à éviter absolument, notamment en raison des exigences légales relatives à la gestion des données personnelles.
Ces enjeux ont été considérés comme supérieurs au gain en accessibilité que permettrait cette implémentation, la dérogation est donc accordée.

Eléments non testés :
Les critères 13.3 et 13.4 sur les documents bureautiques ne seront pas mis en non-conformité quand il y a présence desdits documents. Les équipes de la CNAF nous ont remonté que, pour l’instant, les fichiers PDF générés lors des démarches des utilisateurs ne sont pas accessibles. Ils ne sont donc pas réaudités dans ce périmètre.

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 80.0.1 (64 bits)
- Google chrome : V 85.0.4183.83 (Build officiel) (64 bits)

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular

Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2

La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.0 :
- Non visual Desktop Access (NVDA) ; Version 2020.

L’audit a porté sur un échantillon de 12 pages. 
 

	Pages	NC
1	Home	14
2	Actu	8
3	Je me sépare	5
4	1ères démarches	7
5	Pension alimentaire	7
6	Contacter	4
7	Demande de titre exécutoire (DTE) - page 1	4
8	DTE page 2	9
9	DTE page 3	7
10	DTE page 4	11
11	DTE page 5	12
12	DTE page 6	6

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est moyen.
Le taux de conformité est d’environ 77.58% (calcul effectué sans la prise en compte du nombre de critère non-applicable).
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.1, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendants de l’implémentation de l’écran et de chacun de ses composants. N’étant pas voyants, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitaient d’être détaillées en dehors de la seule grille d’audit.

Couleur

Certains contrastes de couleurs ont un ratio de contrastes insuffisant, notamment les couleurs du thème de la cnaf, comme les contrastes entre les différents bleus, le gris, le blanc.
Cela impacte fortement les personnes malvoyantes et ayant des problèmes de perception des contrastes et des couleurs.
Il faut que les contrastes entre les textes et leur arrière-plan soient de 4.5 au moins pour les textes sans effet de graisse et inférieurs à 24px en taille, ou inférieurs à 18.5 px en taille et gras.
Pour les textes sans effet de graisse supérieurs ou égaux à 24 px et les textes avec effet de graisse supérieurs ou égaux à 18.5, le rapport de contraste doit être de 3 au moins.
Une solution pertinente pour régler le problème serait d’implémenter la pop-up d’accessibilité et le mode contrastes renforcés, comme observé sur d’autres périmètres de la cnaf.

Elément obligatoire

2 éléments relatifs à cette rubrique ont posé problème : 

 1/ Il y a la présence d’une balise div entre le doctype et la balise head, sur toutes les pages.

Nous avons donc supprimé cette div avant de passer le code généré au validateur, afin d’avoir accès aux erreurs pertinentes de la page. 
La suppression de cette balise div corrigera un grand nombre d’erreurs remontées par le validateur.

2/ Les titre des pages manquent de précision. 

En effet, lorsque l’on est dans un processus, il est recommandé de préciser dans le title de la page l’étape à laquelle se situe l’utilisateur (et s’il y a plusieurs écrans dans une même étape, typiquement dans une étape de saisie, de numéroter ces écrans).
Les utilisateurs qui naviguent avec un lecteur d’écran ont des raccourcis qui leur permettent de restituer à tout moment le title de la page sur laquelle ils se situent. Cela leur permet de retrouver le contexte de leur navigation dans le site, à tout moment.  Lorsque les titres ne sont pas pertinents, il y a une perte importante d’information pour l’utilisateur.
Précisez les title de page de manière à ce que les utilisateurs sachent à quel écran du processus ils se situent.

Structuration

Au niveau de la structuration, deux erreurs majeures sont retrouvées.

Premièrement, le contenu principal de la page doit être dans une balise main. 
Sans cela, les aveugles, malvoyants et handicapés moteurs vont être impactés au niveau de leur accès à la navigation dans le contenu et aux accès rapides aux zones principales du contenu.

Deuxièmement, l’ensemble du périmètre est concerné par des erreurs de structuration des titres.
On retrouve notamment ce souci sur la première page du périmètre 
De là, on retrouve plusieurs problèmes :
Il y a un saut de niveaux dans les titres, c’est-à-dire qu’on passe d’un h1 à un h6 à un h3 pour des titres de même importance dans la page.
Il y a des titres vides.
Un titre (Ma pension alimentaire n’est pas payée) est implémenté en deux titres.
Le titre h6 « agence de recouvrement… » appartient à un carrousel, et donc change toutes les 5 secondes. Le titre disparait alors pour laisser place au titre de la slide suivante du carrousel, ce qui peut induire une grande confusion.
Tous ces problèmes vont impacter très fortement les utilisateurs de lecteur d’écran ou de plug-ins de navigation (notamment les personnes aveugles ou handicapées moteur), qui ne vont pas pouvoir utiliser la navigation par titre pour se déplacer dans le contenu de la page afin d’atteindre le contenu pertinent pour elles.
Pour corriger ces erreurs, supprimez les titres vides, implémentez les titres qui doivent être ensemble sur 1 seul titre, mais aussi : respectez une cohérence dans les titres. Un h1 doit mener à un h2, et ainsi de suite, sans saut.
Concernant les titres qui se trouvaient dans le carrousel, retirez-les du carrousel, et implémentez plutôt un titre avant le carrousel indiquant la présence de celui-ci. Ce titre permettra de sauter le carrousel, de ne pas induire en erreur l’utilisateur avec une structuration instable, et à conditions que le contenu des slides du carrousel soient implémentées de manière fonctionnelle et pertinente, il n’y aura pas de perte de contenu.

Formulaire

2 problèmes principaux sont à relever dans cette rubrique :

1/ Les champs de formulaire ne sont pas correctement reliés aux labels. 
Dans certains écrans, certains champs de formulaire n’ont pas de label (visuellement, il s’agit des labels mais ils ne sont pas correctement implémentés).

Ici, visuellement, il y a bien des labels de champs mais l’implémentation est défaillante. Les utilisateurs de lecteur d’écran n’ont pas accès à un contenu immédiatement intelligible. Réparez l’implémentation en utilisant des balises label. 

Dans d’autres écrans, les liaisons for/id ne sont pas correctement implémentées.

La valeur du for du label et de l’id de l’input doivent être identiques, à défaut la liaison ne se fait pas. Les utilisateurs de lecteur d’écran n’ont donc pas accès au label du champ.

2/ Certains formulaires auraient dû comporter des regroupements de champs. 
Dans certains écrans, il y a des champs identiques ou parfois des champs de même nature répétés mais non regroupés dans des fieldsets.

Les utilisateurs qui naviguent au lecteur d’écran sont très impactés par ce manque parce que les balises fieldset permettent d’apporter du contexte au formulaire, et de naviguer entre les différents conteneurs pour mieux appréhender la structure de la page. 
Ici, il faudrait a minima créer un fieldset pour chaque enfant. Chaque fielset devrait contenir une balise legend pertinente (ici, enfant 1 ; enfant 2 et enfant 3).

Navigation

Deux problèmes de navigation ont été détectés dans l’échantillon.

Premièrement, au niveau du burger d’accès au menu de navigation. On ne peut pas tabuler sur menu le bouton d’ouverture du menu de navigation. Cela impacte très fortement les utilisateurs naviguant au clavier, qui ne pourront donc pas accéder à ce menu.
Le problème est ici dû au fait que l’ouverture du menu ne soit pas implémentée en tant que bouton. L’ouverture du menu ne se fait que via un event click.
Ce problème concerne aussi les « flèches » permettant de dérouler le contenu dans les pages éditoriales, dans les différentes situations comme « je me sépare ».
La résolution de cette erreur est donc simplement d’implémenter l’ouverture du menu en tant que bouton.

Deuxièmement, une problématique de tabulation au niveau des tooltip/infobulles de la page. Elles ne prennent pas du tout le focus à la tabulation.
Cela va impacter les utilisateurs naviguant au clavier et de manière notable les utilisateurs de lecteur d’écran, qui n’auront pas accès à ces informations.
Veuillez rétablir la prise de focus sur les tooltip. 

3. Conclusion

Avis de l’auditeur

Globalement, l’accessibilité de cet échantillon est moyenne, elle pourra rapidement remonter en appliquant quelques correctifs clés. 

Il reste quelques erreurs à corriger, parfois répétées dans plusieurs écrans, une correction générale devrait résoudre une partie des problématiques.
Etant donné l’importance des formulaires dans ce périmètre, il semble pertinent de corriger en priorité les erreurs de cette thématique. 

Si besoin, nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport. 

Nom du service numérique : CNAF
Date de l’audit : Août 2021
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte  
Dérogations et éléments non testés 
Accessibilité du site    
2. Description des erreurs d’accessibilité 
Eléments obligatoires
Présentation   
3. Conclusion  
Avis de l'inspecteur 

1. Introduction

Contexte

Le périmètre audité concerne le périmètre ARIPA.
La version utilisée pour réaliser les tests est la version <4.1> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.1 (incluant les scripts), sauf quelques exceptions indiquées ci-dessous.

Dérogations et éléments non testés

Dérogations :

Le critère 11.13 demandant le remplissage automatique des champs de saisie de formulaire via un autocomplete n’est pas audité car il est dérogé dans le contexte de la cnaf : les informations traitées étant très sensibles, la sécurité de ces données prévaut sur leur facilité d’accès.
Cette aide à l’auto-remplissage des champs (élément autocomplete) peut poser de graves brèches de sécurité en ce qui concerne la gestion des données personnelles des utilisateurs. Si une personne se connecte sur un réseau public sur le site de la CNAF et que l’autocomplete est implémentée, l’utilisateur suivant qui se connecterait sur le site de la CNAF bénéficierait, via le remplissage automatique, de l’ensemble des accès aux données personnelles de l’utilisateur précédent.
Cette situation critique est à éviter absolument, notamment en raison des exigences légales relatives à la gestion des données personnelles.
Ces enjeux ont été considérés comme supérieurs au gain en accessibilité que permettrait cette implémentation, la dérogation est donc accordée.

Eléments non testés :

-    Les critères 13.3 et 13.4 sur les documents bureautiques ne seront pas mis en non-conformité quand il y a présence desdits documents. Les équipes de la CNAF nous ont remonté que, pour l’instant, les fichiers PDF générés lors des démarches des utilisateurs ne sont pas accessibles. Ils ne sont donc pas réaudités dans ce périmètre.
-    Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9, 13.10 et 13.12 n’ont ainsi pas pu être réalisés. De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés en raison de problèmes de connexion via VPN en environnement mobile, ce test ne peut donc pas être performé pour l’instant.
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 89.0 (64 bits)
- Google chrome : V91.0.4472.101 (Build officiel) (64 bits)

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular
Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2
La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.1 :

L’audit a porté sur un échantillon de 2 pages.
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est globalement bon.
Le taux de conformité sur l’échantillon globale est de 80,43% (calcul effectué sans la prise en compte du nombre de critère non-applicable). 
Le taux de conformité moyen par page est quant à lui d’environ 89,74%.
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.1, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilité relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendants de l’implémentation de l’écran et de chacun de ses composants. N’étant pas voyants, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitaient d’être détaillées en dehors de la seule grille d’audit.

Eléments obligatoires 
 
Non-conformité liée au critères 8.9 du RGAA 4.1 :

Dans l’échantillon nous avons rencontré des problèmes liés à l’utilisation des balises a des fins de présentation. 

Les aveugles et grands malvoyants utilisent des lecteurs d’écrans qui s’appuient sur la sémantique des balises, telle qu’elle est fournie par le navigateur, pour restituer le contenu et proposer des fonctionnalités de navigation dans le contenu.

Si l’utilisation des balises est détournée, la restitution peut devenir incompréhensible et les fonctionnalités de navigation dans les contenus inopérantes ou donner des résultats particulièrement inattendus.

Présentation

Non-conformité liée aux critères 10.4 du RGAA 4.1:

Dans l’échantillon nous avons rencontré des problèmes liés à l’affichage des contenus. 

Exemple n°1 :

Le bouton de déconnexion disparait lorsque que l’on augmente le zoom graphique.

Exemple n°2 :    

Lorsque les dimensions de la taille de l’écran sont modifiées les contenus à droite du menu mon compte disparaissent.

Certains utilisateurs, notamment les déficients visuels ou les grands malvoyants, ont besoin de personnaliser l’affichage des contenus pour pouvoir y accéder, par exemple en utilisant le zoom de l’écran.

L’ensemble des contenus doivent donc rester lisible lors de l’augmentation de la taille des caractères, mais aussi lors de certaines modifications de la taille de l’écran ou bien lors de l’augmentation de l’espacement entre les caractères.

3. Conclusion 

Avis de l’auditeur

Globalement, l’accessibilité de cet échantillon est bonne.

Il reste toutefois quelques non-conformités mais celles-ci ne sont pas très impactantes.

Une fois les correctifs appliqués l’échantillon atteindra un niveau de conformité très satisfaisant.

Nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport.

Nom du service numérique : CNAF
Date de l’audit : Juillet 2021
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte  
Dérogations et éléments non testés 
Accessibilité du site    
2. Description des erreurs d’accessibilité 
Couleurs
Présentation
Formulaires
Navigation 
Recommandation globale - "écran saisie autres financeurs" page 12
3. Conclusion  
Avis de l'inspecteur 

1. Introduction

Contexte

Le périmètre audité concerne le périmètre Adonis.
La version utilisée pour réaliser les tests est la version <4.1> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.1 (incluant les scripts), sauf quelques exceptions indiquées ci-dessous.

Dérogations et éléments non testés

Dérogations : 

Le critère 11.13 demandant le remplissage automatique des champs de saisie de formulaire via un autocomplete n’est pas audité car il est dérogé dans le contexte de la cnaf : les informations traitées étant très sensibles, la sécurité de ces données prévaut sur leur facilité d’accès.
Cette aide à l’auto-remplissage des champs (élément autocomplete) peut poser de graves brèches de sécurité en ce qui concerne la gestion des données personnelles des utilisateurs. Si une personne se connecte sur un réseau public sur le site de la CNAF et que l’autocomplete est implémentée, l’utilisateur suivant qui se connecterait sur le site de la CNAF bénéficierait, via le remplissage automatique, de l’ensemble des accès aux données personnelles de l’utilisateur précédent.
Cette situation critique est à éviter absolument, notamment en raison des exigences légales relatives à la gestion des données personnelles.
Ces enjeux ont été considérés comme supérieurs au gain en accessibilité que permettrait cette implémentation, la dérogation est donc accordée.

Eléments non testés :

- Les critères 13.3 et 13.4 sur les documents bureautiques ne seront pas mis en non-conformité quand il y a présence desdits documents. Les équipes de la CNAF nous ont remonté que, pour l’instant, les fichiers PDF générés lors des démarches des utilisateurs ne sont pas accessibles. Ils ne sont donc pas réaudités dans ce périmètre.
- Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9, 13.10 et 13.12 n’ont ainsi pas pu être réalisés. De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés en raison de problèmes de connexion via VPN en environnement mobile, ce test ne peut donc pas être performé pour l’instant.
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 89.0 (64 bits)
- Google chrome : V91.0.4472.101 (Build officiel) (64 bits)

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular
Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2
La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.1 :

L’audit a porté sur un échantillon de 13 pages.
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est globalement moyen.
Le taux de conformité sur l’échantillon globale est de 50% (calcul effectué sans la prise en compte du nombre de critère non-applicable). 
Le taux de conformité moyen par page est quant à lui d’environ 78 ,6%.
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.1, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilité relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendants de l’implémentation de l’écran et de chacun de ses composants. N’étant pas voyants, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitaient d’être détaillées en dehors de la seule grille d’audit.

Couleurs 

Non-conformité liée au critère 3.2 et 3.3 du RGAA 4.1 :

Dans l’échantillon nous avons rencontré des problèmes de contraste entre le texte et la couleur arrière-plan. 

Les utilisateurs impactés vont être ceux qui ne distinguent pas bien les couleurs ou ceux qui ont une basse vision.
Il va s’agir de s’assurer qu’ils perçoivent bien les textes, ainsi que les composants de l’interface, avec lesquels ils vont être amenés à interagir, et qu’ils soient en mesure de différencier les différents états des composants. 
II faut donc que le rapport de contraste des textes avec leurs arrière-plan soit de 4,5 :1 pour le texte et les texte en image restituée à 24px ou inférieur.

Les textes en image en gras restituée à 18,5px et pour les textes de taille égale ou supérieure, le ratio de contraste doit être au minimum de 3 :1.

Pour résoudre la majeure partie de ces problèmes de contraste, vous pouvez rajouter la feuille de style utilisée sur d’autre partie du site permettant d’activer le mode contraste renforcé.

Présentation 

Non-conformité liée au critère 10.7 du RGAA 4.1 :

Il y a dans les l’échantillon des problèmes concernant la visibilité du focus.

Dans plusieurs pages, la propriété « outline » de certains éléments focusables, surtout pour la plupart des champs de formulaire, est dégradé où supprimé. 

Les handicapés moteurs qui naviguent au clavier peuvent rencontrer des difficultés considérables à l’utilisation du contenu s’ils n’ont pas la capacité de repérer où se situe l’indication visuelle du focus et ses déplacements.

Pour réparer cela, il faut rétablir une valeur positive de l’outline ou bien vous pouvez laisser le navigateur gérer le focus.

Formulaires 

Non-conformité liée au critère 11.1 et 11.10 du RGAA 4.1 :

Dans plusieurs pages du périmètre, il y a des problèmes de liaison entre les champs de formulaire et leurs étiquettes, ainsi qu’avec les messages d’erreurs. 

-Etiquettes non-reliés au champ :
Les aveugles, les grands malvoyants et les déficients visuels, qui utilisent des lecteurs d’écrans ou des loupes vocalisées, rencontreront des difficultés majeures pour remplir le formulaire s'il contient des champs non correctement reliés à leur étiquette.  

Vous pouvez utiliser les attributs « for » et « id » pour une liaison conforme des étiquettes et des champs, il faut que l’ID soit identique au « for » placés sur la balise label.

-Message d’erreur non reliés au champ :
Sur certains écrans, plusieurs messages d’erreurs sont susceptibles d’apparaître en fonction des champs mal remplis. 

Lorsque que l’on valide la page, sans avoir rempli l’ensemble des champs de formulaire obligatoires, aucune information indiquant les champs à remplir n’est restituée par le lecteur d’écran.

Sans restitution de cette information, l’utilisateur peut ne pas comprendre quel champ de formulaires il doit remplir et pourrait se retrouver bloqué dans la page sans pouvoir accéder à l’étape suivante du processus. 

Pour corriger cela, vous pouvez replacer le focus sur le dernier champ en erreur et rendre restituable par les technologies d’assistance les messages d’erreur en les reliant correctement, par exemple en utilisant la propriété aria-describedby.

Au vus de l’impact chez l’utilisateur, il est important que les étiquettes et les messages d’erreurs soient bien reliés avec leur champ associé.

Navigation 

Non-conformité liée au critère 12.7 du RGAA 4.1 :

Dans l’ensemble de l’échantillon, le lien d’évitement, situé en haut de chaque page ne remplis pas correctement sa fonction.

En effet, il redirige l’utilisateur sur la page d’accueil et non sur le contenu principale (balises main) des différentes pages.

 Le lien d’évitement est présent pour aider les utilisateurs de lecteur d’écran à naviguer plus facilement dans les pages en évitant certains contenus.

 La redirection sur la page d’accueil entrainerait donc de l’incompréhension chez ces utilisateurs.

De plus l’échantillon comprend des processus de plusieurs écrans, la redirection est d’autant plus problématique car cela oblige l’utilisateur à recommencer depuis le départ sa démarche.

Il est donc primordial de réparer ce problème en faisant en sorte que le lien d’évitement amène bien sur le contenu principal des pages.

Recommandation globale – « écran saisie autre financeurs » page 12 

La structure de la page est complexe, elle est composée de beaucoup de champs de formulaire, des étiquettes non pertinentes mal reliées aux champs, et des données qui se croisent faisant ressembler le contenu à des tableaux 

En l’état, la page est presque totalement incompréhensible pour l’utilisateur de lecteur d’écran, car la plupart des champs de formulaire sont restitués comme étant des boutons rotatifs, mais sans information sur la valeur à remplir et la catégorie à laquelle correspond ces valeurs.

La page nécessite beaucoup de modifications pour être plus accessible, si vous souhaitez laisser l’implémentation actuelle, il faudra rajouter des étiquettes pertinentes au champs de formulaire ainsi qu’un bon nombre de regroupements de champs, ce qui permettra de rendre plus compréhensible son contenu et son fonctionnement aux utilisateurs de lecteurs d’écrans.

Tout de même, La solution paraissant la plus cohérente au vu de la structure de la page, serait d'implémenter des tableaux de données, cela permettrait une meilleure compréhension de ces éléments pour l’utilisateur.

3. Conclusion

Avis de l’auditeur

Globalement, l’accessibilité de cet échantillon est moyenne.

Il y a pas mal d’erreurs sur chacune des pages, certaines minimes et d’autres très impactantes,

Il s’agit ici principalement de soucis d’implémentation de certains composants rendant la compréhension du contenu de la page assez difficile.

Les correctifs prioritaires sont indiqués en rouge dans la grille d’audit. 

Une fois ces correctifs appliqués, le niveau d’accessibilité sera bon.

Nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport.

Nom du service numérique : CNAF
Date de l’audit : Juillet 2021
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte  
Dérogations et éléments non testés 
Accessibilité du site    
2. Description des erreurs d’accessibilité 
Présentation
Formulaires
Navigation 
3. Conclusion  
Avis de l'inspecteur 

1. Introduction

Contexte

Le périmètre audité concerne le périmètre AFAS RAM et ALSH.
La version utilisée pour réaliser les tests est la version <4.1> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.1 (incluant les scripts), sauf quelques exceptions indiquées ci-dessous.

Dérogations et éléments non testés

Dérogations :

Le critère 11.13 demandant le remplissage automatique des champs de saisie de formulaire via un autocomplete n’est pas audité car il est dérogé dans le contexte de la cnaf : les informations traitées étant très sensibles, la sécurité de ces données prévaut sur leur facilité d’accès.
Cette aide à l’auto-remplissage des champs (élément autocomplete) peut poser de graves brèches de sécurité en ce qui concerne la gestion des données personnelles des utilisateurs. Si une personne se connecte sur un réseau public sur le site de la CNAF et que l’autocomplete est implémentée, l’utilisateur suivant qui se connecterait sur le site de la CNAF bénéficierait, via le remplissage automatique, de l’ensemble des accès aux données personnelles de l’utilisateur précédent.
Cette situation critique est à éviter absolument, notamment en raison des exigences légales relatives à la gestion des données personnelles.
Ces enjeux ont été considérés comme supérieurs au gain en accessibilité que permettrait cette implémentation, la dérogation est donc accordée.

Eléments non testés :

- Les critères 13.3 et 13.4 sur les documents bureautiques ne seront pas mis en non-conformité quand il y a présence desdits documents. Les équipes de la CNAF nous ont remonté que, pour l’instant, les fichiers PDF générés lors des démarches des utilisateurs ne sont pas accessibles. Ils ne sont donc pas réaudités dans ce périmètre.
- Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9, 13.10 et 13.12 n’ont ainsi pas pu être réalisés. De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés en raison de problèmes de connexion via VPN en environnement mobile, ce test ne peut donc pas être performé pour l’instant.
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 90.0.1 (64 bits)
- Google chrome : V91.0.4472.164 (Build officiel) (64 bits)

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular
Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2
La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.1 :

L’audit a porté sur un échantillon de 11 pages.
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables. 

Accessibilité du site

L’échantillon audité est globalement moyen.
Le taux de conformité sur l’échantillon globale est de 55,74% (calcul effectué sans la prise en compte du nombre de critère non-applicable). 
Le taux de conformité moyen par page est quant à lui d’environ 77,34%. 
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.1, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendants de l’implémentation de l’écran et de chacun de ses composants. N’étant pas voyants, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitaient d’être détaillées en dehors de la seule grille d’audit.

Présentation 

Non-conformité liée au critère 10.4 du RGAA 4.1 :

Nous avons rencontré dans l’échantillon des problèmes concernant l’affichage des contenus

Certains utilisateurs, notamment les déficients visuels ou les grands malvoyants, ont besoin de personnaliser l’affichage des contenus pour pouvoir y accéder, par exemple en utilisant le zoom de l’écran.

L’ensemble des contenus doivent donc rester lisibles lors de l’augmentation de la taille des caractères, mais aussi lors de certaines modifications de la taille de l’écran ou bien lors de l’augmentation de l’espacement entre les caractères.

Non-conformité liée au critère 10.7 du RGAA 4.1 :

Il y a dans l’échantillon des problèmes concernant la visibilité du focus.

Dans plusieurs pages, la propriétés « outline » de certains éléments focusables, surtout pour la plupart des champs de formulaire, est dégradé où supprimer. 

Les handicapés moteurs qui naviguent au clavier peuvent rencontrer des difficultés considérables à l’utilisation du contenu s’ils n’ont pas la capacité de repérer où se situe l’indication visuelle du focus et ses déplacements.

Pour réparer cela, assurez-vous que la prise de focus soit visible sur l’ensemble des éléments focusables ou bien laisser le navigateur gérer la visibilité de la prise de focus

Formulaires 

Non-conformité liée aux critères 11.1 du RGAA 4.1 :

Dans certaines pages de l’échantillon, il y a des problèmes de liaison entre les étiquettes et leurs champs de formulaire associés. 

Les aveugles, les grands malvoyants et les déficients visuels, qui utilisent des lecteurs d’écrans ou des loupes vocalisées, rencontreront des difficultés majeures pour remplir le formulaire s'il contient des champs non correctement reliés à leur étiquette.  

Pour une liaison conforme des étiquettes et des champs de formulaires, vous pouvez utiliser des attributs « for » sur les balises <label> et des « ID » sur les champs associés. Il faut que l’« id » et l’attribut « for » soient identiques.

Non-conformité liée au critère 11.4 du RGAA 4.1 :

Dans l’échantillon certaines étiquettes ne sont pas accolées à leur formulaire associé. 

Les déficients visuels qui ne perçoivent qu’une partie limitée de l’écran pourraient rencontrer des difficultés lors de la saisie si les étiquettes ne sont pas visuellement accolées aux champs de saisie.

Il faut donc que les champs et les étiquettes soient accolés pour éviter une perte d’information chez certains utilisateurs.

Non-conformité liée au critère 11.10 du RGAA 4.1 :

Dans l’échantillon certains messages d’erreur ne sont pas restitués par les technologies d’assistance car ils ne sont pas bien reliés aux champs en erreur. 

Ici, les utilisateurs impactés sont principalement les personnes aveugles, qui ne vont pas pouvoir accéder aux indications visuelles que nous avons lorsque nous ne remplissons pas ou que nous remplissons mal les champs obligatoires. Ils ne voient pas les messages d’erreurs ni les bordures rouges des champs. 
Il est donc primordial de bien relier chaque message d’erreur avec le champ effectivement en erreur.
Pour cela, vous pouvez utiliser la propriété « Aria-describedby » sur le champ, relié par un « ID » positionner sur le message d’erreur correspondant.

Navigation 

Non-conformité liée au critère 12.7 du RGAA 4.1 :

Dans l’ensemble de l’échantillon, le lien d’évitement, situé en haut de chaque page ne remplis pas correctement sa fonction.

En effet, il redirige l’utilisateur sur la page d’accueil et non sur le contenu principale (balises main) des différentes pages.

Le lien d’évitement est présent pour aider les utilisateurs de lecteur d’écran à naviguer plus facilement dans les pages en évitant certains contenus.

La redirection sur la page d’accueil entrainerait donc de l’incompréhension chez ces utilisateurs.

De plus l’échantillon comprend des processus de plusieurs écrans, la redirection est d’autant plus problématique car cela oblige l’utilisateur à recommencer depuis le départ sa démarche.

Il est donc primordial de réparer ce problème en faisant en sorte que le lien d’évitement amène bien sur le contenu principal des pages.

Consultation :
Non-conformité liée au critère 13.1 du RGAA 4.1 :

Il n’y a pas d’indication prévenant l’utilisateur que la limite de temps a été atteinte et qu’il sera rediriger vers la page de login lors par exemple d’un simple rafraichissement de la page. 

Cela touchera notamment les aveugle et les personnes avec un déficit d’attention.

Il faut donc prévenir que la limite de temps est bientôt atteinte et laisser à l’utilisateur la possibilité de modifier cette limite et d’en augmenter la durée.

3. Conclusion

Avis de l’auditeur

Globalement, l’accessibilité de cet échantillon est moyenne.

Les erreurs relevées en cours d’audit sont souvent les mêmes répétées le long des pages du processus, donc l’application des correctifs ne devrait pas poser trop de difficultés aux équipes. 

Les correctifs prioritaires sont indiqués en rouge dans la grille d’audit. 

Une fois ces correctifs appliqués, le niveau d’accessibilité sera bon.

Nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport.

Nom du service numérique : CNAF
Date de l’audit : Février 2021
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte  
Dérogations et éléments non testés 
Accessibilité du site    
2. Description des erreurs d’accessibilité 
Tableaux
Eléments obligatoires
Formulaires
Consultation 
3. Conclusion  
Avis de l'inspecteur

1. Introduction

Contexte

Le périmètre audité concerne la déclaration de ressources annuelle.
La version utilisée pour réaliser les tests est la version <4.0> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.0 (incluant les scripts), sauf quelques exceptions indiquées ci-dessous.

Dérogations et éléments non testés

Dérogations :

Le critère 11.13 demandant le remplissage automatique des champs de saisie de formulaire via un autocomplete n’est pas audité car il est dérogé dans le contexte de la cnaf : les informations traitées étant très sensibles, la sécurité de ces données prévaut sur leur facilité d’accès.
Cette aide à l’auto-remplissage des champs (élément autocomplete) peut poser de graves brèches de sécurités en ce qui concerne la gestion des données personnelles des utilisateurs. Si une personne se connecte sur un réseau public sur le site de la CNAF et que l’autocomplete est implémentée, l’utilisateur suivant qui se connecterait sur le site de la CNAF bénéficierait, via le remplissage automatique, de l’ensemble des accès aux données personnelles de l’utilisateur précédent.
Cette situation critique est à éviter absolument, notamment en raison des exigences légales relatives à la gestion des données personnelles.
Ces enjeux ont été considérés comme supérieurs au gain en accessibilité que permettrait cette implémentation, la dérogation est donc accordée.

Eléments non testés :

Les critères 13.3 et 13.4 sur les documents bureautiques ne seront pas mis en non-conformité quand il y a présence desdits documents. Les équipes de la CNAF nous ont remonté que, pour l’instant, les fichiers PDF générés lors des démarches des utilisateurs ne sont pas accessibles. Ils ne sont donc pas réaudités dans ce périmètre.
Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9 et 13.12  n’ont ainsi pas pu être réalisés. De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés en raison de problèmes de connexion via VPN en environnement mobile, ce test ne peut donc pas être performé pour l’instant.
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés. 

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 80.0.1 (64 bits)
- Google chrome : V 85.0.4183.83 (Build officiel) (64 bits)

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular
Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2
La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.0 :
- Non visual Desktop Access (NVDA) ; Version 2020.

L’audit a porté sur un échantillon de 6 pages. 
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est globalement bon.
Le taux de conformité est d’environ 80% (calcul effectué sans la prise en compte du nombre de critère non-applicable).
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.1, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendant de l’implémentation de l’écran et de chacun de ses composant. N’étant pas voyant, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2. Description des erreurs d’accessibilité

Tableaux

Les tableaux des écrans de récapitulatif ne sont pas accessibles à la tabulation, cela impacte les utilisateurs navigants au clavier et ceux navigant au lecteur d’écran qui n’ont pas accès au contenu/information des tableaux.
Nous avons constaté des différences entre votre implémentation et celle présentée dans le WCAG : https://www.w3.org/TR/wai-aria-practices/examples/table/table.html).
Ainsi, à la lecture de la norme, les éléments ayant un role=row doivent être regroupés dans des balises div ayant un role=rowgroup. Ainsi, la div contenant les role=columnheader devrait être dans une div role=row, elle-même dans une div role =rowgroup. De même pour le corps du tableau, les balises contenant un role=cell et un role=columnheader sont des span et non des div. 
Il faudra donc vérifier si les correctifs permettent bien de faire entrer le focus dans les différents tableaux.
Si ca n’est pas le cas, il faudra forcer la prise de focus avec des attributs tabindex. 

Eléments obligatoires

Le titre de page des pages du processus n’est pas assez précis. On ne connait pas l’étape dans laquelle on se trouve.
Cela va poser un problème majeur pour les personnes aveugles. En effet, ce sont des utilisateurs qui ont un besoin important de contexte pour pouvoir naviguer sur des sites, notamment dans le cadre de processus comptant plusieurs étapes et parfois plusieurs pages par étapes.
Une page dont le titre ne sera pas pertinent va induire une confusion chez l’utilisateur, qui peut par exemple ne pas savoir qu’il se trouve sur une nouvelle page, ou son avancée dans le processus.
Pour corriger cela, indiquez l’étape active du processus dans le title de la page, ainsi que le numéro de page lorsque l’étape du processus comporte plusieurs pages. 

Formulaires

Les champs obligatoires : 

Les formulaires de la CNAF contiennent de nombreux champs obligatoires. 
2 réflexes doivent donc être pris par les équipes de développement : indiquer les champs obligatoires par un message précédant le champ (ou le regroupement de champ) et bien relier les messages d’erreurs aux champs non remplis ou mal remplis. 
1/ l’indication que les champs sont obligatoires :
Cela permet aux utilisateurs voyants et aveugles de ne pas rester bloqués indéfiniment dans un écran à la recherche du champ obligatoire qu’ils n’auraient pas renseigné. 
Pour satisfaire cette obligation, il faut penser d’une part aux utilisateurs voyant et d’autre part aux utilisateurs non-voyants.

2/ Bien relier les messages d’erreurs aux champs en erreur 
Ici, les utilisateurs impactés sont principalement les personnes aveugles, qui ne vont pas pouvoir accéder aux indications visuelles que nous avons lorsque nous ne remplissons pas ou que nous remplissons mal les champs obligatoires. Ils ne voient pas les messages d’erreurs ni les bordures rouges des champs. 
Il est donc primordial de bien relier chaque message d’erreur avec le champ effectivement en erreur.
Visuellement, il est évident que le texte en rouge se rapporte aux champs dont le contour est rouge. 
Pourtant, dans l’implémentation, l’Id du texte d’erreur n’est pas relié par la propriété aria-describedby aux champs en erreur. Les utilisateurs aveugles n’ont donc pas accès à cette information en temps utiles et de manière fonctionnelle. 
Puisque l’accès à l’écran suivant est conditionné par le fait de remplir correctement ces champs, il est très important de faciliter la compréhension des erreurs aux personnes utilisatrices d’un lecteur d’écran.

Restitution des messages généraux d'erreurs : 

Lorsque l’on ne remplit aucun des champs après avoir sélectionné des types de ressources, un message général d’erreur est généré (et le focus repositionné dessus).
Visuellement, ces messages comportent des listes. Ces listes ont une propriété aria-hidden=true et ne sont donc pas restitués au lecteur d’écran. Vous avez implémenté des textes reprenant ces messages d’erreur, positionnés hors écran (sr-only).
Or, ces textes restitués uniquement au lecteur d’écran ne sont pas structurés comme étant des listes, mais des balises p successives.
Cela crée une perte de structuration pour les personnes utilisant des lecteurs d’écrans. La navigation par liste permet de savoir le nombre d’élément en erreur et de naviguer plus facilement entre eux. 
Il serait préférable de maintenir, surtout pour les utilisateurs de lecteur d’écran, une structuration sous forme de liste. 

Regroupement : 

Faire des regroupements quand cela est possible (balise fieldset).
Les regroupements permettent aux personnes navigant au lecteur d’écrans ou tous utilisateur se servant de raccourci pour naviguer entre les diffèrent conteneur de remettre du contexte au champs qu’ils remplissent sans surcharge auditive.
Exemple page « Personne suivante ressources mensuelles ». 

Consultation

Dans cette rubrique il y a 2 problématiques

1/ Les infobulles sont déclenchées par un click descendant ce qui empêche l’annulation de leur ouverture, de plus elle s’ouvre dès la prise de focus. 
Les utilisateurs protégés par ce critère sont ceux navigant avec une forte loupe d’écran, qui vont avoir tendance à se déplacer grâce à leur dispositif de pointage, ou bien encore les personnes atteintes d’un trouble de la motricité qui peuvent cliquer par mégarde sur des éléments de l’écran. 
L’idée est par principe d’implémenter les éléments interactifs de manière à ce que l’action se produise lorsque le dispositif de pointage est relâché ou relevé (concrètement, quand on relève le doigt de la souris). 
Usuellement, les utilisateurs qui cliquent par mégarde sur un bouton ou un lien et ne souhaite pas l’ouvrir, bougent le curseur en dehors de la zone de clic et ainsi n’active pas le composant sur lequel le clic a été pressé. 
Il existe néanmoins des cas particuliers, lorsque par exemple il est logique que l’interaction avec le composant se fasse quand le dispositif de pointage est posé ou pressé (ex : un clavier virtuel, un champ dans lequel on dessine, un champ de signature…).
Dans le cas qui nous intéresse des infobulles. L’implémentation choisie est celle d’un bouton. 
Pour l’ensemble des autres boutons de la page, l’action se produit bien lorsque le dispositif de pointage est relâché sur la zone d’activation du composant.
Le déclenchement des infobulles se fait quant à lui sur l’élément descendant. 
L’event choisi est mousedown. 
Nous préconisons donc de revenir à une implémentation plus classique de bouton. Cela permettrait une navigation plus aisée pour les personnes à très basse vision utilisant une très forte loupe d’écran et ceux qui ont des problèmes de motricité

2/ Dans les différentes pages du périmètre il y a la présence de « ? » a la place d’autre caractères
Cela crée visuellement un effet cryptique non désiré qui rend le contenu difficilement compréhensible pour les voyants et mal restituer pour les non-voyants.
Les caractères spéciaux ont été remplacés par des « ? » dans le code même de la page

3. Conclusion

Avis de l'auditeur

Globalement, l’accessibilité de cet échantillon est satisfaisante.

Les erreurs relevées en cours d’audit sont souvent les mêmes répétées le long des pages du processus, donc l’application des correctifs ne devrait pas poser trop de difficultés aux équipes. 
Nous constatons une amélioration dans l’accessibilité générale des écrans, même si des non-conformités persistent.

Si besoin, nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport.

Nom du service numérique : CNAF, Service SI portails et autres canaux 
Date de l’audit : 23 octobre 2020
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte   
Accessibilité du site    
2. Description des erreurs d’accessibilité 
Scripts
Formulaires
Navigation
3. Conclusion  
Avis de l'inspecteur

1. Introduction

Contexte

Le périmètre Demande de RSA-CMU-C est un audit du périmètre précédemment audité en RGAA 3.
La version utilisée pour réaliser les tests est la version <4.0> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.0 (incluant les scripts).
Les navigateurs employés pour tester les pages sont : 
Mozzilla firefox (à titre principal) : V 80.0.1 (64 bits)
Google chrome : V 85.0.4183.83 (Build officiel) (64 bits)
Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9 et 13.12 n’ont ainsi pas pu être réalisés. 
De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés. 
Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular
Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2
La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.0 :
- Non visual Desktop Access (NVDA) ; Version 2020.
L’audit a porté sur un échantillon de 18 pages de demandes de RSA et 7 pages de demande de CMU.
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site

L’échantillon audité est globalement bon.
Le taux de conformité est d’environ 77% (calcul effectué sans la prise en compte du nombre de critères non-applicables).
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.0, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendant de l’implémentation de l’écran et de chacun de ses composant. N’étant pas voyant, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants. D’autre part, les utilisateurs mal-voyants sont également impactés par certaines des erreurs, notamment liées aux contrastes des composants d’interface et les éléments relatifs aux infobulles.

2. Description des erreurs d’accessibilité

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitait d’être détaillées en dehors de la seule grille d’audit.

Scripts

Dans l’échantillon audité, il y a 2 problèmes principaux en lien avec les scripts. 

1/ L’absence d’indication concernant le changement de contexte sur le bouton continuer.
Tout en bas chaque écran, il y a un bouton continuer permettant d’accéder à l’écran suivant du processus en cours.
Ce bouton est immédiatement précédé dans l’ordre de tabulation par 2 autres boutons : 
Un bouton précédent dont le title est « Retour à la page précédente » 
Un bouton Quitter dont le title est « Quitter l’application ».
Le bouton continuer a quant à lui « continuer » pour title.

Or, en appuyant sur ce bouton, l’utilisateur va être placé dans un nouvel écran, il y a donc changement du contexte dans lequel il se situe. 
Or, les utilisateurs aveugles ne sont pas en mesure de voir qu’une nouvelle page est affichée.
L’absence de précision quant à ce changement de contexte va ainsi éventuellement perturber les utilisateurs aveugles qui ne retrouveront pas les éléments de la page en cours.

Le fait que les 2 boutons précédents aient un title indiquant clairement le changement de contexte rend l’intitulé du bouton « Continuer » non pertinent.

Nous préconisons donc de remplacer le title actuel par « Continuer vers la page suivante », sur l’ensemble des pages du processus. 

La non-conformité de ce critère fait également écho au fait que les title des pages ne sont pas suffisamment précis. 
En effet, la non-conformité du critère 8.6 repose sur le fait que les différents écrans du périmètre se situent en cours d’un processus mais que l’endroit exact de situation de l’écran dans le processus n’est pas fourni par le title de la page (« CAF - Mon Compte - Demander une prestation »). 

Il faudrait préciser la nature de la prestation demandée ainsi que l’étape du processus en cours afin de permettre aux utilisateur aveugles de retrouver plus facilement du contexte lors des changements de page ou en cours de navigation (un raccourci clavier permet aux utilisateurs de lecteur d’écran de relire à tout moment le title de la page en cours).

2/ L’implémentation des infobulles.
Les infobulles présentes dans le périmètre ont des problématiques communes. 
L’intitulé des infobulles.
Chacune des infobulles de l’échantillon a pour intituler l’alt de l’image : « Information supplémentaire ». Or, cet intitulé ne permet pas en soi de comprendre à quoi se rattachent les informations supplémentaires puisque le bouton des infobulles arrive avant le label des boutons principaux dans l’ordre de tabulation. 
Le lecteur d’écran restitue ainsi d’abord l’indication d’un élément intitulé « informations supplémentaires » avant de lire le label du bouton concerné. 
Les utilisateurs aveugles manquent donc de contexte pour comprendre la nature des informations qu’il trouvera en activant le bouton de l’infobulle.
Ici, l’intitulé du bouton est trop long pour être repris dans l’intitulé de l’infobulle. Il semble dès lors pertinent de demander à inverser l’ordre de tabulation pour que le label des boutons comprenant les infobulles soit restitué en premier. Cela permettra aux personnes aveugles utilisant un lecteur d’écran d’avoir un support de contexte pour comprendre la destination du bouton. 

L’absence de prise de focus dans les infobulles
Une fois activée, avec la touche espace ou entrée, l’infobulle s’affiche. Elle contient un bouton de fermeture ainsi qu’un texte. Ces éléments sont restitués au lecteur d’écran, à condition que l’utilisateur ne touche aucune touche à l’exception d’entrée et d’espace, et qu’il ne clique nulle part. 
Ainsi, alors qu’il y a un bouton à l’intérieur de l’infobulle, le focus n’y pénètre jamais. Il n’est donc pas possible aux utilisateurs de lecteur d’écran de naviguer entre les différents conteneurs de l’infobulle (le bouton et les éléments de la liste).
Il serait préférable de permettre au focus d’intégrer l’intérieur de l’infobulle afin de faciliter la navigation avec les lecteurs d’écran. 

Formulaires

Les formulaires de la CNAF contiennent de nombreux champs obligatoires. 
2 réflexes doivent donc être pris par les équipes de développement : indiquer les champs obligatoires par un message précédant le champ (ou le regroupement de champ) et bien relier les messages d’erreurs aux champs non remplis ou mal remplis. 
1/ l’indication que les champs sont obligatoires :
Cela permet aux utilisateurs voyants et aveugles de ne pas rester bloqués indéfiniment dans un écran à la recherche du champ obligatoire qu’ils n’auraient pas renseigné. 
Pour satisfaire cette obligation, il faut penser d’une part aux utilisateurs voyant et d’autre part aux utilisateurs non-voyants.
Pour les utilisateurs voyants : une indication visible des champs obligatoire doit être fournie. Elle peut concerner chaque champ obligatoire isolément, ou un regroupement de champ, ou même consister en une indication en haut de page lorsque tous les champs sont obligatoires. 
En arrivant sur l’écran, aucune mention ne précise qu’il faut choisir un des champs avant de cliquer sur le bouton continuer. Cet élément est pourtant crucial car le fait de cliquer sur les champs va permettre de déplier tous les champs de formulaires pertinents placés dans l’écran. 
En l’état, un utilisateur peut avoir l’impression qu’il peut passer la page en appuyant sur continuer, apparaîtra alors le message d’erreur, postérieurement à l’essai de validation du formulaire. 
Ici, les utilisateurs non-voyants, qui utilisent un lecteur d’écran reçoivent bien l’information que le champ est obligatoire en raison de l’implémentation de l’attribut required. Il serait toutefois préférable de relier aux champs le message indiquant aux utilisateurs voyant que les champs sont obligatoires.
2/ Bien relier les messages d’erreurs aux champs en erreur 
Ici, les utilisateurs impactés sont principalement les personnes aveugles, qui ne vont pas pouvoir accéder aux indications visuelles que nous avons lorsque nous ne remplissons pas ou que nous remplissons mal les champs obligatoires. Ils ne voient pas les messages d’erreurs ni les bordures rouges des champs. 
Il est donc primordial de bien relier chaque message d’erreur avec le champ effectivement en erreur.
Visuellement, il est évident que le texte en rouge se rapporte aux champs dont le contour est rouge. 
Pourtant, dans l’implémentation, l’Id du texte d’erreur n’est pas relié par la propriété aria-describedby aux champs en erreur. Les utilisateurs aveugles n’ont donc pas accès à cette information en temps utiles et de manière fonctionnelle. 
Puisque l’accès à l’écran suivant est conditionné par le fait de remplir correctement ces champs, il est très important de faciliter la compréhension des erreurs aux personnes utilisatrices d’un lecteur d’écran. 

Navigation

Le principal problème dans ce critère est le placement du focus, dans deux utilisations différentes :
1. Pour tous les champs de la page possédants des infobulles, le focus passe d’abord par l’infobulle puis par le champ. 
Cela pose un problème pour les utilisateurs de lecteur d’écran aveugles, ils ont l’information supplémentaire avant de savoir à quel champ cela se rapporte.
Doublé du problème de l’alternative des infobulles non pertinent (les lecteurs d’écran lisent « informations supplémentaires » uniquement), l’utilisateur n’a aucune idée du champ auquel les informations se rapportent.
Cela peut se corriger en réparant l’ordre de tabulation (faire lire l’intitulé du champ avant son infobulle), ainsi qu’en mettant une alternative pertinente à l’infobulle.
2. Le focus n’est pas replacé au bon endroit lorsqu’on clique sur le bouton continuer pour atteindre la suite du processus.
Les utilisateurs aveugles qui utilisent le lecteur d’écran ne savent pas qu’ils sont sur une nouvelle page, puisque le focus n’est pas replacé sur le titre h1 ou en haut de page. L’utilisateur va penser qu’il est toujours sur la même page (puisque son focus est sur le bouton continuer).
D’autre part, s’il se rend compte qu’il est dans une nouvelle page, il doit naviguer à travers toute la page pour remonter sur les premiers éléments de celle-ci.
Il est donc important de corriger cela, en replaçant correctement le focus.

3. Conclusion

Avis de l’inspecteur

Globalement, l’accessibilité de cet échantillon est satisfaisante.

Lors de l’audit, on peut remarquer des évolutions par rapport aux précédents audits, tant sur les nouveaux critères du RGAA 4 que pour respecter les anciens critères du RGAA 3. 
Les implémentations natives sont, dans l’ensemble, respectées, et les modifications apportées avec les rôles et les ARIA sont bien implémentées dans la globalité.

Il reste toutefois quelques erreurs à corriger, souvent communes à un ensemble d’écrans du processus, une correction générale devrait résoudre une bonne partie des problématiques.
Les corrections à apporter sont dans l’ensemble minimes.

Du fait de l’ajout de nouveaux critères par le biais du RGAA 4, il faudra encore un peu de temps d’adaptation aux nouvelles normes, mais il semble qu’elles sont déjà relativement bien appliquées dans leur globalité, et lorsqu’elles sont problématiques, sont relativement minimes en termes d’impacts utilisateurs concrets.

Au vu de l’importance des formulaires sur le périmètre, il semble important d’en prioriser la correction des problèmes.

Si besoin, nos équipes restent ouvertes à la communication afin d’expliquer les différents éléments des grilles d’audit ou de ce rapport.

À cette fin, elle met en œuvre la stratégie et les actions suivantes :
- Notre schéma d’accessibilité numérique 2020-2022 
- Notre plan annuel d’accessibilité 2021 

Cette déclaration d’accessibilité s’applique à la démarche en ligne de l’espace bailleur du caf.fr.

État de conformité
La demande de complément mode de garde est partiellement conforme avec le référentiel général d’amélioration de l’accessibilité (RGAA), version 4 en raison des non-conformités et des dérogations énumérées ci-dessous.

Résultats des tests
L’audit de conformité réalisé par nom de l’entité qui a réalisé l’audit révèle que :
- Le taux moyen de conformité du site s’élève à 66,7 %

Établissement de cette déclaration d’accessibilité
Cette déclaration a été établie le 21/12/2021.

Retour d’information et contact
Si vous n’arrivez pas à accéder à un contenu ou à un service, vous pouvez contacter le responsable de l’espace bailleur du caf.fr pour être orienté vers une alternative accessible ou obtenir le contenu sous une autre forme.
- Envoyer un message à accessibilite-numerique@cnaf.fr
- Contacter la Caisse nationale des Allocations familiales (Cnaf) 32, avenue de la Sibelle, 75685 PARIS CEDEX 14

Voies de recours
Si vous constatez un défaut d’accessibilité vous empêchant d’accéder à un contenu ou une fonctionnalité du site, que vous nous le signalez et que vous ne parvenez pas à obtenir une réponse de notre part, vous êtes en droit de faire parvenir vos doléances ou une demande de saisine au Défenseur des droits.
Plusieurs moyens sont à votre disposition :
- Écrire un message au Défenseur des droits
- Contacter le délégué du Défenseur des droits dans votre région
- Envoyer un courrier par la poste (gratuit, ne pas mettre de timbre)
Défenseur des droits
Libre réponse 71120
75342 Paris CEDEX

Nom du service numérique : CNAF
Date de l’audit : Juin 2021
Audit réalisé par : Avencod

Le modèle de rapport d’audit est bâti à partir de celui de la DINUM, novembre 2019 (https://www.numerique.gouv.fr/uploads/rgaa/rgaa4-2019-modele-rapport-aud...).

Table des matières :
1. Introduction    
Contexte  
Dérogations et éléments non testés 
Accessibilité du site    
2. Description des erreurs d’accessibilité
Tableau 
Scripts
Formulaires
Navigation

1. Introduction

Contexte

Le périmètre audité concerne le périmètre DTR-PPA
La version utilisée pour réaliser les tests est la version <4.1> du RGAA.
Le thème du site a été audité une fois sur le premier écran du périmètre, les autres écrans se sont concentrés sur le contenu principal des écrans.
Cet audit comprend l’ensemble des rubriques et critères du RGAA 4.1 (incluant les scripts), sauf quelques exceptions indiquées ci-dessous.

Dérogations et éléments non testés

Dérogations : 

Le critère 11.13 demandant le remplissage automatique des champs de saisie de formulaire via un autocomplete n’est pas audité car il est dérogé dans le contexte de la cnaf : les informations traitées étant très sensibles, la sécurité de ces données prévaut sur leur facilité d’accès.
Suite à des discussions avec la DSI de la CNAF, l’équipe en charge des audits d’accessibilité a décidé d’accorder une dérogation à la CNAF sur ce critère.
Cette aide à l’auto-remplissage des champs (élément autocomplete) peut poser de graves brèches de sécurités en ce qui concerne la gestion des données personnelles des utilisateurs. Si une personne se connecte sur un réseau public sur le site de la CNAF et que l’autocomplete est implémentée, l’utilisateur suivant qui se connecterait sur le site de la CNAF bénéficierait, via le remplissage automatique, de l’ensemble des accès aux données personnelles de l’utilisateur précédent.
Cette situation critique est à éviter absolument, notamment en raison des exigences légales relatives à la gestion des données personnelles.
Ces enjeux ont été considérés comme supérieurs au gain en accessibilité que permettrait cette implémentation, la dérogation est donc accordée.

Éléments non testés :

- Les critères 13.3 et 13.4 sur les documents bureautiques ne seront pas mis en non-conformité quand il y a présence desdits documents. Les équipes de la CNAF nous ont remonté que, pour l’instant, les fichiers PDF générés lors des démarches des utilisateurs ne sont pas accessibles. Ils ne sont donc pas réaudités dans ce périmètre.
- Il n’a pas été possible de tester les écrans en environnement mobile, les critères 13.9 et 13.12 n’ont ainsi pas pu être réalisés. De même, les tests de restitution en environnement mobile n’ont pas pu être réalisés en raison de problèmes de connexion via VPN en environnement mobile, ce test ne peut donc pas être performé pour l’instant.

Nous vous informons qu’en raison de l’opération de transcodage entre le site en version desktop et celui en version mobile, des disparités peuvent exister. Il n’y a qu’en testant la version mobile en environnement mobile que ces écarts peuvent être véritablement détectés.  

Les navigateurs employés pour tester les pages sont : 
- Mozzilla firefox (à titre principal) : V 89.0 (64 bits)
- Google chrome : V91.0.4472.101 (Build officiel) (64 bits)

Les technologies utilisées sur le site sont les suivantes :
- HTML5
- CSS
- Framework angular

Les outils suivants ont été utilisés pour vérifier l’accessibilité :
- WCAG Contrast checker _ V 3.5.4
- Axe (extension mozzilla) _ V 4.5.3
- HeadingsMap – V 3.8.2

La restitution des contenus avec les technologies d’assistance a été testée conformément à l’environnement de test décrit dans le RGAA 4.1 :
L’audit a porté sur un échantillon de 10 pages.
 

Une grille d’audit est annexée à ce rapport, elle contient les résultats du contrôle de chaque page de l’échantillon au regard des critères de contrôle RGAA applicables.

Accessibilité du site 

L’échantillon audité est globalement moyen.
Le taux de conformité sur l’échantillon globale est d’environ 62 ,7% (calcul effectué sans la prise en compte du nombre de critère non-applicable). 
Le taux de conformité moyen par pages est quant à lui de 82,6%.
Sur une déclaration d’accessibilité, le site serait alors réputé « partiellement conforme » puisqu’avec le RGAA 4.1, pour être déclaré conforme, un site ne doit avoir aucune non-conformité.
De 50% à 100%, un site est réputé partiellement conforme. En dessous de 50%, il est non conforme.
Les principaux utilisateurs impactés par les erreurs d’accessibilités relevées dans l’échantillon sont logiquement les utilisateurs aveugles, puisqu’ils sont entièrement dépendant de l’implémentation de l’écran et de chacun de ses composant. N’étant pas voyant, il faut toujours leur fournir du contexte supplémentaire par rapport aux utilisateurs voyants.

2 . Description des erreurs d'accessibilité 

NB : ce rapport n’a pas vocation à présenter les non-conformités de manière exhaustive. Ne sont relevées que les plus impactantes pour les utilisateurs, celles reposant sur les nouveaux critères du RGAA 4.0 ainsi que celles qui nécessitait d’être détaillées en dehors de la seule grille d’audit.

Tableau 

Non-conformités correspondant au critères 5.7 du RGAA 4.1 :

Le page récapitulatif a dans son tableau de donnée l’attribut scope=’’row’’ sur les cellules interne au tableau (qui ne sont pas des titres de lignes) :

Les utilisateurs de lecteur d’écran sont les plus impactés, car les technologies d’assistance restituent à l’utilisateur qu’il est dans une en-tête de tableau, alors qu’il se trouve dans ces cellules interne.  
Cela qui peut engendrer une complication de la compréhension des données du tableau.

Script 

Non-conformités correspondant au critères 7.1 du RGAA 4.1 :

Il y a des problèmes concernant les scripts dans le périmètre,

1-Dans l’écran « revenus de remplacement », la page contient des calendriers.

Il n’est pas nécessaire que l’utilisateur puisse naviguer dans ces calendriers qui ne sont pas accessibles, cela rend le remplissage de la date plus complexe.

De plus, ces calendriers possèdent une alternative : un champ de formulaire permettant de rentrer la date manuellement.

Les utilisateurs de lecteur d’écran ainsi que les personnes ayant des problèmes de compréhension dus à un handicap mental sont impactées, car la navigation dans le tableau est difficile.

Vous devez donc « cacher » ces calendriers aux lecteurs d’écran à l’aide d’un attribut Aria-hidden= true ainsi qu’un

Tabindex -1 permettant d’empêcher l’accès à la tabulation.

2-Dans l’écran « mes ressources », il y a un tableau possédant des liens comprenant une image représentant un point d’interrogation.

Ces liens ouvrent une nouvelle fenêtre, leur contenu donne des informations supplémentaires sur la rubrique associée. 

Il serait plus pertinent de changer cette implémentation, en transformant ces composant en de véritables infobulles, ayant pour intitulés l’alternative de l’image qui serait information supplémentaire + le nom de la rubrique associé.

Si vous conservez l’implémentation de base, il faut au minimum prévenir l’utilisateur de l’ouverture d’une nouvelle fenêtre sinon certains utilisateurs, par exemple des personnes ayant un handicap mental ou cognitif peuvent ne pas avoir la capacité de comprendre ce changement de contexte s’ils ne sont pas informés préalablement.

Formulaires 

Non-conformité correspondant au critères 11.10 du RGAA 4.1 :

Dans plusieurs écrans du périmètre, il y a un problème concernant le contrôle de saisie des formulaires.

Lorsque l’utilisateur valide le formulaire, sans avoir rempli l’ensemble des champs obligatoires, la page est repositionnée visuellement au niveau d’un message d’erreur (effet de scroll).

Ce message d’erreur n’est pas restitué par les technologies d’assistance car le focus n’est pas replacé dessus. 

Il faut que l’information soit restituée à l’utilisateur de manière pertinent. 
Pour ce faire, vous pouvez replacer le focus sur le dernier champ en erreur ou bien rendre restituable par les technologies d’assistance. Vous pouvez relier le message d’erreur à la checkbox, par exemple en utilisant la propriété aria-describedby.

Les utilisateurs de lecteur d’écran sont les plus impacté par cette non-conformité. Sur certains écrans, plusieurs messages d’erreurs sont susceptibles d’apparaître en fonction des champs mal remplis. 

Sans restitution de cette information, l’utilisateur peut ne pas comprendre quel champ de formulaires il doit remplir et pourrait se retrouver bloqué dans la page sans pouvoir accéder à l’étape suivante du processus.

Navigation 

Non-conformité correspondant au critères 12.8 du RGAA 4.1 :

Dans plusieurs écrans du périmètre, l’implémentation des champs de formulaires modifie l’ordre de la tabulation d’une façon qui n’est pas cohérente.

En effet, les champs possèdent des attributs tabindex avec des valeurs positives, ce qui priorise l’accès à la tabulation de ces champs.
Ils sont donc les premiers éléments de l’écran à prendre le focus. 

L’ordre de tabulation créé à l’aide de ces attribut tabindex rend la compréhension de la page plus difficile, surtout quand les champs de formulaires concernés sont dans des tableaux. En effet, les champs sont restitués avant même le menu de navigation. Lorsque l’utilisateur arrive enfin au tableau dans la page et accède aux entêtes du tableau, ils n’ont plus accès aux champs de formulaires, restitués très en amont. Cela rend le remplissage très fastidieux et peu intuitif pour les personnes aveugles navigant au clavier.

Il faut supprimer les valeurs positives des tabindex pour pouvoir rétablir un ordre de tabulation cohérent et une meilleure compréhension de la page pour les utilisateurs de lecteurs d’écran. Pour garantir l’ordre dans lequel les éléments recevront le focus, implémentez les cases consécutivement à l’entête de chaque ligne. Ainsi, le focus sera ordonné de manière linéaire et horizontale, ligne après ligne dans le tableau.