@cnamts/synapse 0.0.10-alpha → 0.0.12-alpha

package/src/stories/Accessibilite/KitDePreAudit/Echantillonnage.mdx

@@ -0,0 +1,40 @@
+import {Meta} from '@storybook/addon-docs/blocks';
+
+<Meta title="Accessibilité/Kit de pré-audit/Échantillonnage"/>
+
+# Échantillonnage
+
+Le RGAA exige que l’audit d’accessibilité soit effectué sur un ensemble représentatif de pages et des fonctionnalités de votre service. Il serait difficile et très chronophage de tester l’intégralité des contenus. La définition d’un périmètre est un compromis pertinent pour auditer efficacement un service et respecter les exigences légales.
+
+L’objectif est donc de que vous déterminiez quels pages seront concernées par l’audit (et ce pré-audit).
+
+La règlementation indique que l’audit doit être réalisé sur les pages suivantes si elles existent :
+
+- Accueil
+- Contact
+- Mentions légales
+- Page “accessibilité” (comprenant la déclaration d’accessibilité)
+- Plan du site (si présent)
+- Aide
+- Authentification
+- Au moins 1 page pertinente pour chaque type de service fourni (ex: rubriques de 1er niveau), y compris la fonctionnalité de recherche et ses pages de résultat
+- Au moins 1 document téléchargeable pertinent
+- L’ensemble des pages constituant un processus (ex: un formulaire sur plusieurs pages)
+- Des exemples de pages ayant un aspect sensiblement distinct ou présentation un type de contenu différent (ex : page contenant des tableaux de données, des éléments multimédias, des illustrations, des formulaires, etc.)
+
+Le nombre de visiteurs par page peut notamment être pris en compte lors de la constitution de l’échantillon. S’ajoute à l’échantillon des pages sélectionnées au hasard représentant à minima 10% de l’échantillon.
+
+Certains contenus sont exemptés de l’obligation d’accessibilité et se situent hors champ de l’obligation légale :
+
+1. Les fichiers disponibles dans des formats bureautiques publiés avant le 23 septembre 2018, sauf s’ils sont nécessaires à l’accomplissement d’une démarche administrative relevant des tâches effectuées par l’organisme concerné ;
+2. Les contenus audio et vidéo préenregistrés, y compris ceux comprenant des composants interactifs, publiés avant le 23 septembre 2020 ;
+3. Les contenus audio et vidéo diffusés en direct, y compris ceux comprenant des composants interactifs ;
+4. Les cartes et les services de cartographie en ligne, sous réserve que, s’agissant des cartes destinées à fournir une localisation ou un itinéraire, les informations essentielles soient fournies sous une forme numérique accessible ;
+5. Les contenus de tiers qui ne sont ni financés ni développés par l’organisme concerné et qui ne sont pas sous son contrôle ;
+6. Les reproductions de pièces de collections patrimoniales qui ne peuvent être rendues totalement accessibles en raison ;
+ - Soit de l’incompatibilité des exigences en matière d’accessibilité avec la préservation de la pièce concernée ou l’authenticité de la reproduction notamment en termes de contraste ;
+ - Soit de l’indisponibilité de solutions automatisées et économiques qui permettraient de transcrire facilement le texte de manuscrits ou d’autres pièces de collections patrimoniales et de le restituer sous la forme d’un contenu compatible avec l’obligation d’accessibilité ;
+7. Les contenus des intranets et des extranets publiés avant le 23 septembre 2019, jusqu’à ce que ces sites fassent l’objet d’une révision en profondeur ;
+8. Les contenus des sites internet et des applications mobiles qui ne sont ni nécessaires à l’accomplissement d’une démarche administrative active ni mis à jour ou modifiés après le 23 septembre 2019, notamment les archives.
+
+Il existe un système de dérogation dans la mise en conformité d’un service numérique à l’accessible : la charge disproportionnée. Elle permet de déroger à certaines règles d'accessibilité lorsque leur mise en œuvre engendre une charge excessive pour l'organisation. Cela peut inclure des contraintes techniques, financières ou temporelles qui rendent la conformité à une norme spécifique difficile ou irréalisable. L’absence de priorité, le manque de temps ou de connaissance ne sont pas des circonstances légitimes de dérogations. Cette dérogation doit être justifiée, documentée et nécessite un accord auprès de la DSI de la CNAM. De plus, des solutions alternatives doivent être proposées pour garantir un accès maximal aux utilisateurs en situation de handicap.

package/src/stories/Accessibilite/KitDePreAudit/Introduction.mdx

@@ -0,0 +1,32 @@
+import {Meta} from '@storybook/addon-docs/blocks';
+
+<Meta title="Accessibilité/Kit de pré-audit/Introduction"/>
+
+# Pré-audit web conformité à l’accessibilité
+
+## Objectif
+
+L’objectif du pré-audit est d’obtenir un premier avis sur le taux 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.
+#
+La restitution consiste à s’assurer que toutes les exigences du pré-audit sont remplies et que vous ayez un minimum d’erreur en lançant les tests automatisés avec Tanaguru.
+Vous pouvez nous solliciter pour un accompagnement si vous rencontrez des difficultés techniques à résoudre les non-conformités relevées par Tanaguru.
+
+## Environnement de test
+
+- Système d’exploitation : Windows
+- Navigateur : Firefox (mentionner la version)
+- Lecteur d’écran : NVDA (dernière version)
+
+Si l’outil cible un public utilisant des terminaux mobile, utiliser l’environnement de test suivant en supplément :
+
+- Système d’exploitation : Android
+- Navigateur : Chrome (mentionner la version)
+- Lecteur d’écran : TalkBack (dernière version)
+
+## Livrable
+
+- La Check-list du pré-audit qui comprend :
+  - contexte du projet (responsabilités)
+  - résultat de l’échantillon de test
+  - résultat du pré-audit manuel complété avec 1 onglet / page
+- En annexe et pour chaque page, il sera demandé de restituer un rapport Tanaguru

package/src/stories/Accessibilite/KitDePreAudit/Outils/Introduction.mdx

@@ -0,0 +1,33 @@
+import {Meta} from '@storybook/addon-docs/blocks';
+
+<Meta title="Accessibilité/Kit de pré-audit/Outils/Introduction"/>
+
+# Outils
+
+Dans le cadre du pré-audit et de l’audit, il existe des outils automatisés pour vérifier certains critères de conformité en matière d'accessibilité.
+
+<b>Voici les outils requis pour le pré-audit :</b>
+
+1. [**Tanaguru webext RGAA (Extension Firefox)**](https://addons.mozilla.org/fr/firefox/addon/tanaguru-webext/) :
+Tanaguru Webext RGAA est une extension de navigateur conçue pour faciliter l'audit d'accessibilité des sites web selon le **Référentiel Général d'Amélioration de l'Accessibilité (RGAA)**. Elle permet aux utilisateurs de vérifier, directement depuis leur navigateur, la conformité de pages web aux critères d'accessibilité du RGAA, en offrant une évaluation rapide des problèmes d'accessibilité tels que les contrastes, les alternatives textuelles manquantes, la structure des balises HTML, etc. Cette extension fonctionne comme un outil d'audit instantané pour les développeurs et les testeurs d'accessibilité, en affichant directement les erreurs et en proposant des suggestions pour améliorer l'accessibilité du site. Attention, ce service ne permet pas d’évaluer l’ensemble des 106 critères du RGAA, uniquement ceux qui sont automatisable. Sur les 258 tests du RGAA, Tanaguru estime qu’environ 100 tests ne sont pas automatisés.
+2. [**PDF Accessibility Checker (PAC)**](https://pac.pdf-accessibility.org/en) :
+PDF Accessibility Checker (PAC) est un logiciel Windows dédié à l'audit de l'accessibilité des documents PDF. Il permet de vérifier la conformité d'un fichier PDF aux normes d'accessibilité, telles que les WCAG et les directives PDF/UA (PDF Universal Accessibility). PAC analyse la structure du document, y compris les titres, les balises, les liens, les tables et les éléments multimédia, pour s'assurer que le contenu est correctement organisé et peut être interprété par des technologies d'assistance comme les lecteurs d'écran.
+3. [**NVDA (NonVisual Desktop Access)**](https://www.nvda.fr/c2) :
+Lecteur d’écran bureau - NVDA est un lecteur d'écran open-source conçu pour les personnes malvoyantes ou aveugles. Il permet de rendre accessibles les interfaces graphiques des ordinateurs Windows en lisant à haute voix les éléments affichés à l'écran. NVDA prend en charge plusieurs applications et navigateurs web, et il est utilisé pour tester la compatibilité des sites web et des applications avec les technologies d'assistance. Cet outil est particulièrement apprécié pour son accessibilité gratuite et sa capacité à détecter des erreurs de conception qui peuvent nuire à l'expérience des utilisateurs ayant des déficiences visuelles.
+4. (Si pré-audit sur mobile) [**TalkBack**](https://www.notion.so/Pr-audit-web-conformit-l-accessibilit-18c4ee4a529d80e2ab27cadba4829e37?pvs=21) :
+Lecteur d’écran mobile - TalkBack est une fonctionnalité d'accessibilité déjà intégrée aux appareils Android qui fournit des retours vocaux sur les éléments affichés à l'écran. Ce lecteur d'écran permet à l'utilisateur d'interagir avec son appareil sans avoir besoin de visionner l'écran. En utilisant des gestes tactiles spécifiques, l'utilisateur peut naviguer à travers les applications, lire des messages, envoyer des e-mails ou encore interagir avec des contenus multimédia. TalkBack offre également des options de personnalisation pour ajuster la vitesse de la voix, le volume et d'autres paramètres en fonction des besoins de l'utilisateur. Il prend en charge une large gamme de contenus accessibles et est régulièrement mis à jour pour améliorer son efficacité et sa compatibilité avec les dernières versions d'Android. Cet outil est essentiel pour garantir que les utilisateurs en situation de handicap visuel peuvent utiliser pleinement leurs appareils Android.
+
+En complément, voici d’autres outils optionnels qui pourraient vous être utiles :
+
+- [**Assistant RGAA (extension Firefox)**](https://addons.mozilla.org/fr/firefox/addon/assistant-rgaa/) :
+L'Assistant RGAA est un outil français destiné à vérifier la conformité des sites web aux critères d’accessibilité définis par le Référentiel Général d'Amélioration de l'Accessibilité (RGAA). Il permet d’effectuer des audits sur des sites en ligne pour identifier et corriger les problèmes d'accessibilité.
+- [**WAVE (extension Firefox)**](https://addons.mozilla.org/fr/firefox/addon/wave-accessibility-tool/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search) :
+WAVE est un outil d'évaluation de l'accessibilité des sites web. Il analyse les pages pour identifier les erreurs d'accessibilité et fournit des rapports détaillés afin d'aider les développeurs à corriger les problèmes de conformité aux normes d'accessibilité.
+- [**WCAG Contrast Checker (extension Firefox)**](https://addons.mozilla.org/fr/firefox/addon/wcag-contrast-checker/) :
+Un outil en ligne qui permet de vérifier si le contraste entre le texte et son arrière-plan respecte les exigences des WCAG (Web Content Accessibility Guidelines). Il aide à garantir une lisibilité suffisante pour les utilisateurs malvoyants.
+- [**Colour Contrast Analyser**](https://www.tpgi.com/color-contrast-checker/) :
+Outil permettant de tester le contraste des couleurs dans les interfaces numériques pour s'assurer qu'il respecte les normes d'accessibilité, notamment celles des WCAG. Il aide à garantir que le texte est lisible pour les personnes ayant des troubles visuels.
+- [**Stark**](https://www.getstark.co/) :
+Stark est un plugin pour des outils de conception comme Figma, Sketch et Adobe XD. Il permet de tester l'accessibilité des designs, en particulier en vérifiant la conformité du contraste des couleurs et en fournissant des suggestions pour améliorer l'accessibilité visuelle.
+- [**Check-list du designer (de Design Accessible)**](https://design-accessible.fr/checklist) :
+Checklist d'accessibilité disponible sur le site Design Accessible. Elle propose une liste de critères à vérifier pour garantir l’accessibilité des sites web en conformité avec les normes d’accessibilité.

package/src/stories/Accessibilite/KitDePreAudit/Outils/Tanaguru.mdx

@@ -0,0 +1,33 @@
+import {Meta} from '@storybook/addon-docs/blocks';
+
+<Meta title="Accessibilité/Kit de pré-audit/Outils/Tanaguru"/>
+
+# Utilisation de Tanaguru
+
+**1. Analyse d’une page d’ameli.fr , [https://www.ameli.fr/assure/adresses-et-contacts/l-obtention-d-un-document/obtenir-une-attestation](https://www.ameli.fr/assure/adresses-et-contacts/l-obtention-d-un-document/obtenir-une-attestation)**
+
+<img alt="UtilisationTanaguruEtape1" src={'tanaguruetape1.png'} style={{ padding: '10px',  border: '1px solid rgba(0, 0, 0, 0.05)', boxShadow: 'rgba(0, 0, 0, 0.10) 0 1px 3px 0'}} />
+
+**2. Installation de l’extension de navigateur **Tanaguru webext.****
+
+**3. Ouvrir les outils de développement ou faire F12, et aller jusqu’à l’onglet **Tanaguru webtext RGAA4****
+
+<img alt="UtilisationTanaguruEtape2" src={'/tanaguruetape2.png'} style={{ padding: '10px',  border: '1px solid rgba(0, 0, 0, 0.05)', boxShadow: 'rgba(0, 0, 0, 0.10) 0 1px 3px 0'}} />
+
+**4. Par défaut, laisser les éléments tel quel, et cochez la case **Statuts invalidés**.**
+
+Cliquez ensuite sur **Analyser cette page**
+
+<img alt="UtilisationTanaguruEtape3" src={'/tanaguruetape3.png'} style={{ padding: '10px',  border: '1px solid rgba(0, 0, 0, 0.05)', boxShadow: 'rgba(0, 0, 0, 0.10) 0 1px 3px 0'}} />
+
+**5. Les éléments sur la gauche, correspondent aux thématiques du RGAA**
+
+<img alt="UtilisationTanaguruEtape4" src={'/tanaguruetape4.png'} style={{ padding: '10px',  border: '1px solid rgba(0, 0, 0, 0.05)', boxShadow: 'rgba(0, 0, 0, 0.10) 0 1px 3px 0'}} />
+
+**6. Exemple: **Eléments obligatoires** 3 erreurs qui correspondent a plusieurs éléments dans notre page. Dont l’erreur est “**propriété ARIA non autorisées sur leur élément**”.**
+
+On va chercher dans la thématique **Eléments obligatoires** du RGAA, les critères qui pourraient correspondre à l’erreur de Tanaguru.
+
+<img alt="UtilisationTanaguruEtape5" src={'/tanaguruetape5.png'} style={{ padding: '10px',  border: '1px solid rgba(0, 0, 0, 0.05)', boxShadow: 'rgba(0, 0, 0, 0.10) 0 1px 3px 0'}} />
+1. La loupe permet de localiser le problème dans le code ( /!\ cet élément n’est pas toujours accessible).
+2. Bou de code ou on retrouve généralement les propriétés ou les éléments en erreur.

package/src/stories/Accessibilite/KitDePreAudit/Preaudit.mdx

@@ -0,0 +1,100 @@
+import {Meta} from '@storybook/addon-docs/blocks';
+
+<Meta title="Accessibilité/Kit de pré-audit/Pré-audit"/>
+
+# Pré-audit
+
+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. Pour prouver ce palier et être éligible à la demande d'audit complet vous devez compléter <a href="/documents/Checklist_pre-audit_CNAM_NOM_DU_PRODUIT.xlsx" target="_blank">ce fichier</a> qui mentionne les exigences requises par la vérification assistée des outils automatisés et la vérification manuelle. 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](mailto:valentin.becquet@assurance-maladie.fr) (cette adresse évoluera prochainement).
+
+Pour demander un audit merci de contacter [valentin.becquet@assurance-maladie.fr](mailto:valentin.becquet@assurance-maladie.fr). 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.
+
+Pour rappel, avant de lancer votre pré-audit vous devez définir l'échantillon de votre audit. Vous trouverez toutes les informations associées [ici](/docs/accessibilit%C3%A9-kit-de-pr%C3%A9-audit-%C3%A9chantillonnage--docs).
+
+## Vérification assistée des outils automatisés
+
+Lancer Tanaguru sur chaque page de l’échantillon de test. Vous pouvez retrouver une documentation d’utilisation de Tanaguru [ici](/docs/accessibilit%C3%A9-kit-de-pr%C3%A9-audit-outils-tanaguru--docs).
+
+L'outil Tanaguru a la capacité de 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é. 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. Vous pouvez nous solliciter pour un accompagnement si vous rencontrez des difficultés techniques à résoudre les non-conformités relevées par Tanaguru.
+
+## Vérification manuelle
+
+L’objectif est de vérifier chacun des 8 points suivants pour chaque page de l’échantillon de test. Au sein de la check-list, il faudra choisir entre “Conforme”, “Non conforme”, “Non applicable”, “Dérogé” ou “Non testé” pour chacun des critères suivants. Il est possible d’ajouter un commentaire pour expliciter les erreurs relevées, des recommandations ou d’éventuelles questions.
+
+**1. Navigation au clavier** :
+
+- Testez que toutes les parties de votre site sont entièrement navigables à l’aide du clavier (touche Tab pour se déplacer, Shift+Tab pour revenir en arrière, Entrée pour activer un élément, Espace pour les actions interactives comme les boutons).
+  - **Vérification manuelle** :
+  - Naviguez sur toutes les sections du site uniquement avec le clavier.
+  - Testez tous les éléments interactifs : menus, formulaires, liens, boutons, carrousels, fenêtres modales, etc.
+  - Assurez-vous que les menus déroulants s'ouvrent avec le clavier et que vous pouvez accéder à tous les champs de formulaire et boutons sans difficulté.
+  - Vérifiez qu’aucun piège au clavier n’existe (boucle, etc.)
+  - Exemple : Vérifiez si un utilisateur peut remplir un formulaire de contact en utilisant uniquement les touches de tabulation
+
+**2. Éléments visuels (animations, transitions, etc.) et déclenchement automatiques** :
+
+- Assurez-vous que les animations et transitions ne causent pas de problèmes pour les personnes souffrant de troubles comme l’épilepsie photosensible et qu’un contrôle est possible sur les éléments qui se déclenchent automatiquement.
+  - **Vérification manuelle** :
+  - Testez les animations sur le site (bannières, carrousels, transitions de pages).
+  - Vérifiez que la durée d’une animation est inférieure ou égale à 5 secondes
+  - Vérifiez que l’utilisateur peut arrêter, relancer, afficher et masquer une animation
+  - Pour les contenus clignotants ou avec effet de flash, assurez-vous que la fréquence d’effet est inférieure à 3 par seconde et la surface cumulée inférieure à inférieure à 21824 pixels.
+  - Exemple : Si un carrousel d’images se déclenche automatiquement, vérifiez qu’il peut être mis en pause ou que l'utilisateur peut le contrôler avec le clavier ou la souris.
+
+**3. Pertinence des liens et des boutons** :
+
+- Le texte des liens et des boutons doit être explicite, clair et contextuel, en évitant les termes génériques comme "Cliquez ici" ou "En savoir plus".
+  - **Vérification manuelle** :
+  - Lisez tous les textes des liens et boutons du site. Vérifiez qu’ils décrivent clairement ce qu'ils ouvrent ou accomplissent, et qu'ils sont compréhensibles même hors contexte.
+  - [Voir le critère RGAA 6.1 pour en savoir plus sur les liens explicites.](https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/#6.1)
+  - Exemple : Remplacer un lien "En savoir plus" par un lien plus descriptif comme "Voir les services proposés" ou "Découvrir les détails de notre offre".
+
+**4. Formulaires** :
+
+- 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.).
+  - **Vérification manuelle** :
+  1. **Labels associés aux champs** :
+ - Vérifiez 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. Cela permet aux utilisateurs de lecteurs d'écran d'identifier la fonction de chaque champ.
+  - [Voir le critère RGAA 11.2 pour en savoir plus sur la pertinence d’une étiquette associée à un champ de formulaire](https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/#11.2)
+ - **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. **Messages d'erreur et validation** :
+ - Vérifiez que des messages d'erreur sont clairement associés aux champs en cas de saisie incorrecte (par exemple, email mal formé, champ obligatoire non rempli).
+ - Testez que ces messages d’erreur sont visibles, compréhensibles et bien positionnés. Vérifiez également qu’ils sont annoncés par le lecteur d'écran.
+ - **Exemple** : Si un utilisateur laisse le champ "Email" vide ou entre un format incorrect, un message comme "Veuillez entrer une adresse email valide" doit s'afficher à proximité du champ concerné, et ce message doit être lisible pour les technologies d'assistance.
+  3. **Groupes de champs et aide contextuelle** :
+ - Vérifiez que les champs sont regroupés de manière logique, avec des titres ou des instructions claires pour chaque section (par exemple, "Informations personnelles" ou "Adresse de facturation").
+ - Assurez-vous que des indices ou des descriptions contextuelles sont fournis pour aider l’utilisateur à comprendre ce qui est attendu dans chaque champ.
+ - **Exemple** : Si un champ de formulaire demande un "numéro de carte de crédit", assurez-vous qu'une aide contextuelle est présente pour indiquer le format attendu.
+  4. **Focus visuel** :
+ - Testez que le focus visuel (le cadre ou l’indication de l’élément sélectionné) est bien visible lorsqu’un utilisateur navigue au clavier entre les champs du formulaire. Cela permet de garantir une navigation fluide pour les personnes malvoyantes.
+ - **Exemple** : Lorsque vous appuyez sur la touche Tab, assurez-vous que chaque champ de saisie est bien mis en surbrillance pour indiquer où le focus est situé.
+
+**5. Tableaux accessibles** :
+
+- Vérifiez que les tableaux de données sont bien structurés avec des balises `<th>` pour les en-têtes et des descriptions de colonnes et lignes claires, permettant une navigation facile pour les utilisateurs de lecteurs d'écran.
+  - **Vérification manuelle** :
+  - Inspectez les tableaux sur le site pour vérifier que les en-têtes de colonnes et lignes utilisent les balises `<th>` et que des attributs `scope` sont utilisés pour clarifier la structure du tableau.
+  - Vérifiez que des descriptions sont disponibles pour les tableaux complexes ou que des alternatives sont fournies.
+  - Exemple : Si un tableau contient des données financières, assurez-vous que les en-têtes de colonnes comme "Date" et "Montant" sont bien définis et que l'ordre des colonnes est logique pour les utilisateurs de lecteurs d’écran.
+
+**6. Langue de la page** :
+
+- Vérifiez que la langue du contenu principal de la page est correctement définie avec l’attribut `lang` dans l'élément `<html>`, ce qui permet aux technologies d’assistance de prononcer le texte dans la langue correcte.
+  - **Vérification manuelle** :
+  - 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 `<html>`. 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))
+  - Exemple : Si votre site est en français, l'élément `<html>` devrait être : `<html lang="fr">`.
+
+**7. Titre de la page** :
+
+- Le titre de chaque page (`<title>`) doit être descriptif, unique et pertinent par rapport au contenu de la page.
+  - **Vérification manuelle** :
+  - Ouvrez chaque page du site et lisez le titre affiché dans l'onglet du navigateur.
+  - Vérifiez que le titre est spécifique à la page (par exemple, "Page d'accueil" pour la page d'accueil, "Contactez-nous" pour la page de contact).
+  - Exemple : Le titre de la page sur un annuaire pourrait être "Annuaire - [Nom du service]" et non "Page 1".
+
+**8. Accès aux contenus multimédia** :
+
+- Vérifiez que les vidéos et autres contenus multimédia sont accessibles, notamment en fournissant des sous-titres, des transcriptions ou d’autres alternatives textuelles.
+  - **Vérification manuelle** :
+  - Testez les vidéos du site pour vérifier si elles proposent des sous-titres ou des transcriptions disponibles.
+  - Assurez-vous que les lecteurs vidéo permettent l’activation des sous-titres et que ces derniers sont synchronisés avec le contenu audio.
+  - Exemple : Si une vidéo présente une interview, vérifiez qu’une transcription complète ou des sous-titres sont fournis pour les utilisateurs sourds ou malentendants.

package/src/stories/{Guidelines → Accessibilite}/Vuetify/Vuetify.mdx

@@ -3,7 +3,7 @@ import * as AccessStories from './Vuetify.stories.ts';
 
 <Meta of={AccessStories} />
 
-Vuetify & Accessibilité
+Vuetify
 =============
 
 <Story of={AccessStories.Legende} />

package/src/stories/{Guidelines → Accessibilite}/Vuetify/Vuetify.stories.ts

@@ -9,7 +9,7 @@ const linkICon = mdiLinkVariant
 const iconAlert = mdiAlertCircleOutline
 
 export default {
-	title: 'Guidelines/Vuetify',
+	title: 'Accessibilité/Vuetify',
 }
 
 export const VuetifyPanel: StoryObj = {

package/src/stories/Components/Components.mdx

@@ -0,0 +1,8 @@
+import { Story, Meta } from '@storybook/blocks';
+import * as ComponentsStories from './Components.stories';
+
+<Meta of={ComponentsStories} />
+
+<Story of={ComponentsStories.Header} />
+
+<Story of={ComponentsStories.ComponentsList} />