@cnamts/synapse 0.0.9-alpha → 0.0.11-alpha

package/src/composables/useFilterable/useFilterable.ts

@@ -0,0 +1,196 @@
+import { ref, watch, type Ref } from 'vue'
+import type { ChipItem } from '@/components/ChipList/types'
+import slugify from 'slugify'
+import { deepCopy } from '@/utils/functions/deepCopy'
+
+export type FilterItem = {
+	name: string
+	value?: unknown
+	formatChip?: (value: unknown) => ChipItem[]
+	chipOverflowLimit?: number
+	title?: string
+}
+
+export type FilterProp = FilterItem[]
+
+export default function useFilterable(model: Ref<FilterProp>, emits) {
+	const filters = ref<FilterProp>([])
+
+	watch(model, (newFilters) => {
+		filters.value = deepCopy(newFilters)
+	}, { deep: true, immediate: true })
+
+	function getFilterCount(filter: FilterItem): number {
+		return getChips(filter).length
+	}
+
+	function formatFilterName(name: string): string {
+		return slugify(name, { lower: true })
+	}
+
+	function getChips(toto: FilterItem): ChipItem[] {
+		const { value, formatChip } = toto
+
+		if (value !== undefined && formatChip) {
+			return formatChip(value)
+		}
+
+		const isString = typeof value === 'string'
+		const isNumber = typeof value === 'number'
+		const isObject = typeof value === 'object' && value !== null
+		const isArray = Array.isArray(value)
+
+		if (isString || isNumber) {
+			if (value === '') {
+				return []
+			}
+
+			return [
+				{
+					text: value.toString(),
+					value: value,
+				},
+			]
+		}
+
+		if (isArray) {
+			return value.map((item) => {
+				if (typeof item !== 'object') {
+					return {
+						text: item.toString(),
+						value: item,
+					}
+				}
+
+				return {
+					text: item.text || item.value.toString(),
+					value: item,
+				}
+			})
+		}
+
+		if (isObject) {
+			// eslint-disable-next-line @typescript-eslint/no-explicit-any
+			const typedValue = value as Record<string, any>
+			const isPeriodField
+				= typedValue.from !== undefined && typedValue.to !== undefined
+
+			if (isPeriodField) {
+				if (typedValue.from === null || typedValue.to === null) {
+					return []
+				}
+
+				return [
+					{
+						text: `${typedValue.from} – ${typedValue.to}`,
+						value: typedValue,
+					},
+				]
+			}
+
+			// Any object
+			return Object.keys(typedValue).map((key) => {
+				// Use text property if it exists, else use value property or default to key value
+				const text
+					= typedValue[key].text
+						|| typedValue[key].value?.toString()
+						|| typedValue[key].toString()
+
+				return {
+					text,
+					value: typedValue[key],
+				}
+			})
+		}
+
+		return []
+	}
+
+	function removeChip(filter: FilterItem, chip: ChipItem): void {
+		const value = filter.value
+		const isString = typeof value === 'string'
+		const isNumber = typeof value === 'number'
+		const isObject = typeof value === 'object' && value !== null
+		const isArray = Array.isArray(value)
+
+		if (isString || isNumber) {
+			filter.value = undefined
+		}
+
+		if (isArray) {
+			// eslint-disable-next-line @typescript-eslint/no-explicit-any
+			const typedValue = value as any[]
+			// eslint-disable-next-line @typescript-eslint/no-explicit-any
+			const chipValue = chip.value as any
+
+			const filteredValue = typedValue.filter((item) => {
+				if (Array.isArray(chipValue)) {
+					return !chipValue.includes(item)
+				}
+
+				if (typeof item === 'object') {
+					return item.value !== chipValue.value
+				}
+
+				return item !== chipValue
+			})
+
+			const newValue = filteredValue.length
+				? filteredValue
+				: undefined
+
+			filter.value = newValue
+			updateValue()
+
+			return
+		}
+
+		if (isObject) {
+			// eslint-disable-next-line @typescript-eslint/no-explicit-any
+			const typedValue = value as Record<string, any>
+			// eslint-disable-next-line @typescript-eslint/no-explicit-any
+			const chipValue = chip.value as any
+			const isPeriodField
+				= typedValue.from !== undefined && typedValue.to !== undefined
+
+			if (isPeriodField) {
+				filter.value = undefined
+				updateValue()
+
+				return
+			}
+
+			delete typedValue[chipValue]
+			filter.value = typedValue
+		}
+		updateValue()
+	}
+
+	function resetFilter(filter: FilterItem): void {
+		filter.value = undefined
+		updateValue()
+	}
+
+	function resetAllFilters(): void {
+		filters.value.forEach((filter) => {
+			filter.value = undefined
+		})
+
+		updateValue()
+	}
+
+	function updateValue(): void {
+		emits('update:modelValue', filters.value)
+	}
+
+	return {
+		filters,
+		updateValue,
+		removeChip,
+		resetFilter,
+		resetAllFilters,
+		getChips,
+		getFilterCount,
+		formatFilterName,
+	}
+}

package/src/constants/icons.ts

@@ -0,0 +1,5 @@
+import { mdiCheck, mdiLink, mdiClose } from '@mdi/js'
+
+export const checkIcon = mdiCheck
+export const croixIcon = mdiClose
+export const linkICon = mdiLink

package/src/designTokens/tokens/cnam/cnamLightTheme.ts

@@ -29,10 +29,10 @@ export const cnamLightTheme = {
 	backgroundMain: cnamSemanticTokens.colors.background.main,
 	backgroundSurface: cnamSemanticTokens.colors.background.surface,
 	backgroundSurfaceAlt: cnamSemanticTokens.colors.background.surfaceAlt,
-	backgroungMainAlt: cnamSemanticTokens.colors.background.mainAlt,
-	backgroungRaised: cnamSemanticTokens.colors.background.raised,
+	backgroundMainAlt: cnamSemanticTokens.colors.background.mainAlt,
+	backgroundRaised: cnamSemanticTokens.colors.background.raised,
 	backgroundAccent: cnamSemanticTokens.colors.background.accent,
-	backgroungAccentContrasted: cnamSemanticTokens.colors.background.accentContrasted,
+	backgroundAccentContrasted: cnamSemanticTokens.colors.background.accentContrasted,
 	backgroundAccentAlt: cnamSemanticTokens.colors.background.accentAlt,
 	backgroundInfo: cnamSemanticTokens.colors.background.info,
 	backgroundInfoSubdued: cnamSemanticTokens.colors.background.infoSubdued,

package/src/stories/Accessibilite/Aculturation/SensibilisationAccessibilite.mdx

@@ -0,0 +1,63 @@
+import {Meta} from '@storybook/addon-docs/blocks';
+
+<Meta title="Accessibilité/Aculturation/Sensibilisation à l’accessibilité numérique"/>
+
+# 1. L’accessibilité concerne tout le monde
+## **1.1 La CNAM doit respecter le RGAA**
+
+En tant que personne morale de droit public, nous avons l'obligation légale de concevoir les composants de notre Design System en respectant les enjeux d’accessibilité. En conformité avec la Direction Interministérielle du Numérique (DINUM), il est demandé de respecter le   Référentiel Général d'Amélioration de l'Accessibilité (RGAA) pour le desktop et Référentiel d’Accessibilité des Applications Mobiles (RAAM) pour le mobile. 
+#
+
+## 1.2 Une diversité de handicap
+
+Bien que l’accessibilité concerne tout le monde, il est particulièrement pertinent pour l’inclusion des personnes avec des **handicaps qu’ils soient** 
+
+- **visuels** (ex: les aveugles ou les malvoyants)
+- **auditifs** (ex: les sourds ou les malentendants)
+- **moteurs** (ex: ceux qui ont des difficultés à bouger à cause de maladies ou d'accidents)
+- **cognitifs** (ex: ceux avec des troubles de l'apprentissage ou des troubles psychiques).
+
+L’enjeu de l’accessibilité est de s'assurer que les sites web, les applications et autres outils numériques soient **faciles à utiliser pour tout le monde, peu importe leurs capacités.**
+
+## 1.3 Nous outils s’adressent à tous (assurés, agents, professionnels de santé), une partie significative de nos utilisateurs sont donc concernés.
+
+En France, 14% de la population, soit 7,6 millions de personnes de 15 ans ou plus, sont en situation de handicap. Cependant, l'accessibilité ne concerne pas seulement ces personnes. Toute situation où l'environnement n'est pas adapté aux capacités d'une personne peut créer un handicap. 
+
+Par exemple, une personne en fauteuil roulant n'est pas en situation de handicap dans un environnement accessible. 
+De plus, certaines personnes peuvent ne pas se considérer comme handicapées même si elles rencontrent des difficultés. Ainsi, tous nos utilisateurs peuvent être concernés par des situations de handicap, qu'elles soient permanentes ou temporaires.
+<img alt="handicap" src={'/handicap1.jpg'} style={{ padding: '10px',  border: '1px solid rgba(0, 0, 0, 0.05)', boxShadow: 'rgba(0, 0, 0, 0.10) 0 1px 3px 0'}} />
+
+<aside>
+
+Tester la navigation du point de vue des utilisateurs en situation de handicap
+
+- [Atalan Simulateur](https://www.atalan.fr/agissons/fr/daltonisme.html)
+- [Inria Simulateur de vision sur une interface](https://simulation-accessibilite.inria.fr/public/fr/daltonisme.html)
+</aside>
+# 2. Comment mettre en place l’accessibilité ?
+
+On dit souvent que l’accessibilité ce n’est pas pour tel ou tel service car cela serait trop long, couteux ou encore qu’on n’a pas l’expertise. Pourtant de nombreuses actions sont faciles et à portée de main pour initier une démarche d’accessibilité. 
+<img alt="processusAccessibilite" src={'/processusAccessibilite.jpg'} style={{ padding: '10px',  border: '1px solid rgba(0, 0, 0, 0.05)', boxShadow: 'rgba(0, 0, 0, 0.10) 0 1px 3px 0'}} />
+
+## **2.1 L’accessibilité s’intègre tout au long de votre processus de conception**
+
+Etre accessible est un travail en continu qui s’intègre à plusieurs niveaux de votre processus de conception. C’est un travail de collaboration qui mêlent plusieurs expertises, chef de projet, designer et développeurs. 
+
+## 2.2 Vous pouvez pré-auditer un service
+
+Un pré-audit est une évaluation préparatoire réalisée par les équipes-produits pour vérifier la conformité d'un produit aux critères du RGAA. À l'aide d’outil et de méthodologie, ces équipes peuvent identifier la moitié des critères requis avant un audit complet. Ces équipes peuvent compter sur un accompagnement pour la prise en main de cet outil ainsi que du conseil pour la résolution des défauts constatés. L’objectif premier du pré-audit est de réduire la quantité de correctif relevée par l’audit complet en donnant un meilleur contrôle aux produits sur leur gestion de projet.
+
+**[Guide du pré-audit](/docs/accessibilité-kit-de-pré-audit-pré-audit--docs)**
+
+## 2.3 Prêt pour soumettre une demande d’audit  ?
+
+**Vous avez fait votre pré audit et vous êtes prêts à le soumettre ?** 
+
+Une fois le pré-audit effectué, un audit complet est réalisé par une équipe dédiée à la Filière Digital sur la totalité des critères évalués sur les pages retenues. Le résultat de cet audit donne à la fois les correctifs à apporter et le taux de conformité. En complément l’équipe FD délivre un template de déclaration d’accessibilité à compléter par le produit selon les correctifs réalisés. Les correctifs sont à réaliser par l’équipe-produit. Il est demandé à cette dernière de publier la page de déclaration d’accessibilité dès qu’elle en a les moyens.
+
+Pour demander un audit complet de votre site web, vous devez compléter <a href="/documents/Checklist_pre-audit_CNAM_NOM_DU_PRODUIT.xlsx" target="_blank">ce fichier</a> et le soumettre à [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.
+
+
+
+

package/src/stories/Accessibilite/Audit/RGAA.mdx

@@ -0,0 +1,29 @@
+import {Meta} from '@storybook/addon-docs/blocks';
+
+<Meta title="Accessibilité/Audit/RGAA"/>
+
+## Le RGAA, le référentiel français d’accessibilité numérique
+
+Le RGAA est un outil méthodologique de certification permettant d'assurer par le respect de ses critères une manipulation des produits numériques dans le domaine du Web de manière égale entre chaque citoyen, qu'il soit ou non en situation de handicap (visuel, auditif, moteur, trouble dys...). Basé sur les travaux du W3C Web Accessibility Initiative (WAI) il vise à garantir quatre indices de performance : **la bonne perceptibilité de l'information**, une **manipulation efficiente dans la navigation**, une **bonne compréhension** et une **robustesse efficace** dans l'usage des produits numériques. Actuellement le RGAA (version 4) est constitué de 106 critères répartis dans 13 catégories
+
+[En savoir plus sur le RGAA](https://www.numerique.gouv.fr/publications/rgaa-accessibilite/#contenu)
+
+[En savoir plus sur le W3C WAI](https://www.w3.org/WAI/fundamentals/)
+
+[Accéder à la liste des critères du RGAA](https://www.numerique.gouv.fr/publications/rgaa-accessibilite/methode-rgaa/criteres/#contenu)
+
+### Résultats
+
+ 
+La conduite d'une évaluation pour attester de la conformité du produit numérique avec le RGAA peut être menée par un audit en auto-évaluation ou par un organisme tiers. Au terme de cette évaluation vous recevez un score et des informations complémentaires permettant de définir l'état de conformité de votre produit. Il existe 3 états:
+
+- **Conformité totale :** si tous les critères de contrôle du RGAA sont respectés
+- **Conformité partielle :** si au moins 50 % des critères de contrôle du RGAA sont respectés
+- **Non-conformité :** s'il n'existe aucun résultat d'audit en cours de validité permettant de mesurer le respect des critères ou si moins de 50 % des critères de contrôle du RGAA sont respectés
+
+Vous garantissant d'un respect de ces critères, l'usage sans modification de notre Design System vous assure d'abord un gain de temps dans le développement mais surtout une augmentation du pourcentage de succès dans l'évaluation de votre produit.
+
+<aside>
+- [En savoir plus sur les obligations légales françaises](https://accessibilite.numerique.gouv.fr/obligations/)
+- [En savoir plus sur les recommandations web de Orange](https://a11y-guidelines.orange.com/fr/web/)
+</aside>

package/src/stories/Accessibilite/Introduction.mdx

@@ -0,0 +1,27 @@
+import {Meta} from '@storybook/addon-docs/blocks';
+
+<Meta title="Accessibilité/Introduction"/>
+
+
+# Accessibilité numérique
+
+Pour répondre aux objectifs de mise en conformité des interfaces utilisateurs avec les normes réglementaires de l’accessibilité numérique, la Filière Digital propose une offre accessibilité numérique basée sur trois éléments clés :
+
+- la mise à disposition d’un Design System performant pour des produits web embarquant déjà ce qui peut l'être à un niveau design system
+- une documentation spécifique d’aide à la conception comportant des outils d’autocontrôle
+- un accompagnement des équipes-produits sur le sujet
+
+Face à l’ampleur du parc numérique de la Cnam et pour atteindre puis maintenir dans la durée la conformité requise par la DINUM nous pensons que la prise de conscience des enjeux de l’accessibilité numérique doit être partagé entre tous les acteurs de la conception à la fabrication des produits numériques.<br/>
+C'est pourquoi et sauf exception motivée, toute nouvelle demande d'audit d'accessibilité numérique sera soumise à la validation de critères d'éligibilité définis dans le kit de pré-audit.<br/>
+L'objectif ici est d'anticiper les erreurs et diluer l'effort de mise en conformité tout au long du processus de fabrication afin de ne pas attendre le résultat de l'audit pour réécrire le produit.<br/>
+Une fois le produit éligible, l'équipe experte de la Filière Digital réalise un audit et communique à l'équipe-produit un rapport comportant des recommandations. Si le produit utilise le DS CNAM et que des problèmes sont identifiés associés à ce dernier, les évolutions seront portés directement par la Filière Digital, en cas contraire il est demandé à l'équipe-produit de corriger les anomalies et de mettre à jour en autonomie le rapport d'audit pour atteindre la pleine conformité.
+
+Conscient que tous les produits ne peuvent pas utiliser dans l’immédiat le Design System thème Cnam ou thème Portail Agent, nous avons conçu le kit de pré-audit pour qu’il puisse fonctionner en autonomie.<br/>
+Si vous avez besoin d’un accompagnement sur le sujet, merci de prendre contact avec valentin.becquet@assurance-maladie.fr.
+
+Vous trouverez dans ce dossier 3 principales rubriques :
+
+- [Sensibilisation à l'accessibilité numérique](/docs/accessibilité-aculturation-sensibilisation-à-l-accessibilité-numérique--docs)
+- [Kit du Pré-Audit](/docs/accessibilité-kit-de-pré-audit-introduction--docs)
+- [Audit](/docs/accessibilité-audit-rgaa--docs)
+

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} />