import {Meta} from '@storybook/blocks';
import '../../styles/shared.css';
Pré-audit d'accessibilité
Vérifiez la conformité de votre service web avant l'audit officiel ou pendant les phases de développement.
Objectif:
L'Objectif du pré-audit est d'atteindre en semi-autonomie un premier palier de conformité de votre service web avant de convenir d'un réel audit RGAA. La procédure se fait en autonomie par l'équipe de développement du produit. Le relevé des non-conformités relève de la responsabilité de l’équipe de développement, ce kit étant conçu pour guider l’auto-évaluation.
Pour prouver ce palier et être éligible à la demande d'audit complet vous devez compléter ce fichier qui mentionne les exigences requises par la vérification assistée des outils automatisés et la vérification manuelle.
Les tests ci dessous permettent aussi de vérifier tout au long des phases de développement, qu’un niveau intermédiaire d’accessibilité est bien respecté.
Contact et assistance
Dans le cas où vous rencontrez une difficulté avec un test, un critère ou un outil n'hésitez pas à nous contacter via l'adresse valentin.becquet@assurance-maladie.fr (cette adresse évoluera prochainement).
Pour demander un audit, contactez également cette adresse. L'acceptance de la demande est soumise à la démonstration de l'effort engagé par l'équipe-produit. Cette appréciation fera l'objet d'une discussion.
Rappel important : Avant de lancer votre pré-audit, vous devez définir l'échantillon de votre audit. Vous trouverez toutes les informations associées ici.
Vérification assistée des outils automatisés
Utilisation de Tanaguru
Lancez Tanaguru sur chaque page de l'échantillon de test. Vous pouvez retrouver une documentation d'utilisation de Tanaguru ici.
Capacité de l'outil : Tanaguru peut contrôler 158 tests sur les 258 du RGAA.
Les exigences du pré-audit sont respectées dès lors que vous atteignez un minimum d'erreur en lançant les tests automatisés avec Tanaguru. Ce seuil est volontairement sujet à discussion pour ne pas bloquer les produits en cas de grande complexité. Pour être considéré comme conforme au pré-audit, le projet doit corriger les tests invalidés et contrôler les tests indéterminés. Ce dernier type de test doit faire l'objet d'un contrôle manuel par un opérateur humain puisqu'il relève généralement d'une notion d'interprétation (ex : subjectivité, ordre de tabulation, pertinence du contenu éditorial). Dans le cas où un test est présenté en résultat "non conforme" pour la demande d'audit, une justification devra être apportée pour motiver l'éligibilité du produit.
Vérification manuelle
L'Objectif est de vérifier chacun des 8 points suivants pour chaque page de l'échantillon de test. Nous recommandons vivement, au préalable, de naviguer sur la totalité de la page via le lecteur d'écran car il s'agit d'un moyen concret de vérifier si le code sémantique et la navigation au clavier sont réellement conformes. Vous pouvez consulter notre mode d'emploi sur les lecteurs d'écran.
Notation : Au sein de la rapport de pre-audit, il faudra choisir entre "Conforme", "Non conforme", "Non applicable", "Dérogé" ou "Non testé" pour chacun des critères.
Il est possible d'ajouter un commentaire pour expliciter les erreurs relevées, des recommandations ou d'éventuelles questions.
1. Navigation au clavier
Objectif:
S'assurer que toutes les parties sont entièrement navigables au clavier
Méthode de test:
- Naviguer via la touche Tab pour se déplacer, Shift+Tab pour revenir en arrière, Entrée/Espace/Flèches/etc. en fonction des composants.
- Tester tous les éléments interactifs : menus, menus déroulants, formulaires, liens, boutons, carrousels, fenêtres modales, etc. Concernant le comportement clavier pour les composants d'interface, se renseigner via les patterns du W3C.
- S'assurer que l'ordre de tabulation est cohérent.
- S'assurer que le focus du clavier reste visible et possède un contraste minimum de 3:1.
- Vérifier qu'aucun piège au clavier n'existe (boucle, etc.).
Outil éventuel:
Aucun
Exemple :
- Vérifiez si un utilisateur peut remplir un formulaire de contact en utilisant uniquement les touches de tabulation.
- S'assurer que la navigation via les touches de tabulation reste uniquement au sein de la boîte de dialogue.
2. Éléments visuels et déclenchements automatiques
Objectif:
Vérifier que les animations, transitions et autres éléments visuels peuvent être arrêtés, mis en pause ou désactivés par l'utilisateur.
Méthode de test:
- Identifier tous les éléments animés, qui clignotent ou se mettent à jour automatiquement sur votre site.
- Vérifier que ces éléments peuvent être arrêtés ou mis en pause par l'utilisateur.
- S'assurer que la durée du mouvement est inférieure ou égale à 5 secondes s'il n'existe aucun moyen d'arrêter ou de masquer le contenu.
Outil éventuel:
Aucun
Exemple : Un carrousel d'images doit pouvoir être arrêté par l'utilisateur.
3. Pertinence des libellés et textes alternatifs
Objectif:
Les libellés et textes alternatifs des images, liens, boutons doivent être explicite, clair et contextuel, en évitant les termes génériques comme "Logo", "Cliquez ici" ou "En savoir plus".
Méthode de test:
- Inspecter les images porteuses d'information et s'assurer qu'elles contiennent un alt pertinent (ou legend pour les balises picture)
- À l'inverse, s'assurer que seules les images de décoration sont ignorées par les technologies d'assistance (ex: aria-hidden="true")
- Vérifier que chaque lien ou bouton a un intitulé qui décrit clairement sa fonction ou sa destination.
Outil éventuel:
Pour les images, le plugin Assistant RGAA permet de mettre en évidence les images considérées avec ou sans alternative textuelle (catégorie 1). La catégorie 6 du même plugin permet de mettre en évidence les liens et liens images.
Exemple :
- Au lieu de "Cliquez ici", préférer "Télécharger le formulaire d'inscription (PDF, 1,2 Mo)"
- Pour une image d'un graphique présentant des données, l'attribut alt pourrait être :
alt="Graphique montrant l'évolution des ventes de 2019 à 2023 avec une augmentation de 20% en 2023"
- Ajouter un
`Fermer le panier` au sein du bouton de l'icône croix de la boîte de dialogue.
4. Formulaires
Objectif:
Assurez-vous que tous les éléments d'un formulaire sont accessibles et compréhensibles pour les utilisateurs, y compris ceux qui utilisent des technologies d'assistance (lecteurs d'écran, commandes vocales, etc.).
Méthode de test: :
1. Labels associés aux champs
- Vérifier que chaque champ de formulaire a un label explicite et associé correctement, en utilisant les balises
<label> avec l'attribut for correspondant à l'id du champ de saisie. Ce label ne devra pas disparaître au remplissage.
- Consulter le critère RGAA 11.2 pour en savoir plus sur la pertinence d'une étiquette associée à un champ de formulaire.
- S'assurer que les étiquettes de champ sont accolées au champ, immédiatement au-dessous ou à droite pour les champ de type `checkbox` ou `radio`, immédiatement au-dessus ou à gauche pour les autres (cas d'un sens de lecture de langue de gauche à droite).
Exemple : Pour un champ de saisie de nom, assurez-vous qu'il est bien associé à un label : <label for="nom">Nom :</label> <input type="text" id="nom">.
2. Aide à la saisie, messages d'erreur et validation
- S'assurer que l'indication de champ obligatoire est visible et qu'il existe un attribut `required` (ou `aria-requied="true"`).
- Vérifier que les aides à la saisie et messages d'erreur sont clairement associés aux champs en cas de saisie incorrecte (annoncé au lecteur d'écran via un `aria-describedby` + ajout de la balise `aria-invalid="true"`).
- Tester que ces messages d'erreur sont visibles, compréhensibles et bien positionnés. Si nécessaire, le message d'erreur devra posséder une suggestion.
3. Groupes de champs
- Vérifier que les champs de même nature sont regroupés via un `fieldset` ou un `role="group"` (par exemple, champs de type `checkbox` ou `radio`, numéro de sécurité social en 2 champs, etc.)
- S'assurer qu'une légende existe et est pertinente (`legend` si `fielset`; `aria-label` ou `aria-describedby` si `role="group"`).
4. Retour après soumission du formulaire
- Tester la soumission du formulaire et vérifier le comportement en cas de succès. L'utilisateur doit être informé (changement de page, message de statut, etc.).
- Tester la soumission du formulaire et vérifier le comportement en cas d'erreur. L'utilisateur devra être redirigé, soit vers le premier champ en erreur, soit sur un message d'erreur global situé tout en haut du formulaire.
5. Remplissage automatique
- Inspecter les champs de formulaire afin de vérifier la présence de l'attribut `autocomplete` et sa pertinence (s'appuyer sur la liste des valeurs possibles pour l’attribut autocomplete du site officiel RGAA)
- Tester la soumission du formulaire et vérifier le comportement en cas d'erreur. L'utilisateur devra être redirigé, soit vers le premier champ en erreur, soit sur un message d'erreur global situé tout en haut du formulaire.
Outil éventuel:
Utilisation du lecteur d'écran pour vérifier la navigation et l'accessibilité des formulaires, tel que l'indication du caractère obligatoire du champ, la liaison du champ aux aides à la saisie ainsi qu'aux messages d'erreurs, le comportement à la soumission du formulaire, etc.
Ressources
Concepts des formulaires
5. Tableaux
Objectif:
Vérifier que les tableaux de données sont bien structurés
Méthode de test:
- S'assurer que les titres des tableaux de données sont sémantiquement rattachés au tableau et sont pertinents.
- S'assurer que tableaux de données complexes (en-têtes n'étant pas qu'en une seule ligne ou une seule colonne) possèdent un résumé pertinent.
- Vérifiez que les cellules d'en-tête sont correctement déclarées avec des balises
<th> et non des balises <td> stylisées.
- Assurez-vous que les tableaux complexes ont des attributs
scope ou des associations entre cellules d'en-tête et cellules de données.
Outil éventuel:
Inspecteur de code
Exemple :
- Le tableau a un titre visible pertinent "Effectif et densité de professionnels de santé libéraux par région - 2016 à 2023" qui est rattaché sémantiquement au tableau via la balise `caption` (ou l'attribut `aria-labelledby`).
- Les en-têtes de colonnes des tableaux utilisent des balises `th` avec l'attribut `scope="col"`.
Ressources
Concepts des tableaux
6. Langue
Objectif:
Permettre aux lecteurs d’écran d’utiliser la bonne prononciation.
Méthode de test:
- Inspectez le code source de la page (clic droit > "Inspecter" dans le navigateur) et vérifiez que l’attribut `lang="fr"` (ou la langue correspondante) est bien présent dans l’élément ``. S’il s’agit d’une autre langue, elle doit être pertinente ([voir documentation MDN sur l’attribut lang](https://developer.mozilla.org/fr/docs/Web/HTML/Global_attributes/lang))
- Repérer les mots/phrases dans une autre langue au sein de la page et vérifier l'existence et la valeur de l’attribut
lang.
Outil éventuel:
Inspecteur de code
Exemple : Si votre site est en français, l'élément `` devrait être : ``.
7. Titre de la page et hiérarchie des titres
Objectif:
Vérifier que la page possède un titre descriptif, unique et pertinent. De plus, s'assurer que la structure des titres au sein de la page est cohérente.
Méthode de test:
- Identifier si le titre affiché dans l'onglet du navigateur est pertinent.
- Le contenu de la page devra avoir au moins un titre.
- Analyser les balises de
h1 à h6 en vérifiant la pertinence et la structure (aucun saut de niveau).
- S'assurer que les titres sont sémantiquement correctes (présence d'une balise
hx ou balises role="heading" aria-level="x"
Outil éventuel:
Extension HeadingsMap (voir la page des outils)
Exemple :
- Le titre de la page sur un annuaire pourrait être "Annuaire (page 1 sur 5) - [Nom du service]" et non "Page 1".
- Les titres "Logement", "Véhicule" et "Emploi" doivent être un sous-niveau du titre "Aides financières".
8. Contenus multimédia
Objectif:
Vérifier que les vidéos et autres contenus multimédia temporels possèdent, si nécessaire, une transcription textuelle, une audiodescription synchronisée et/ou des sous-titres synchronisés. Concernant les médias non temporels, s'assurer qu'ils possèdent une alternative ou sont accessibles par le clavier et tout dispositif de pointage.
Méthode de test:
- Écouter les vidéos sans regarder l’écran et statuer sur la pertinence de l'audiodescription.
- Lire une vidéo avec sous-titres activés et statuer sur leur pertinence.
- Vérifier que toute transcription textuelle exprime tout ce qui est retranscrit oralement et suivent la chronologie du média.
- S'assurer que tout son déclenché automatiquement peut, soit être stoppé, soit contrôlé indépendemment du volume, soit possède une durée inféreure ou égale à 3 secondes.
Outil éventuel:
Aucun
Ressources
Concepts des contenus multimédia
Conclusion
En suivant ces vérifications manuelles et automatisées, vous pourrez atteindre un premier niveau de conformité d'accessibilité pour votre service web. N'hésitez pas à documenter vos résultats et à solliciter de l'aide si nécessaire.