247 lines
7.9 KiB
Markdown
247 lines
7.9 KiB
Markdown
# RGAA - Audit initial et roadmap de mise en conformite
|
|
|
|
## Contexte
|
|
|
|
Ce document formalise une **premiere passe RGAA** sur le portail `portail-association973.com`, croisee avec le code local et la structure actuelle de l'application.
|
|
|
|
Ce n'est **pas** une certification RGAA complete ni un audit legal exhaustif.
|
|
En revanche, c'est une base serieuse pour prioriser les corrections les plus utiles et structurer la trajectoire d'accessibilite.
|
|
|
|
Date de reference : **15 aout 2026**
|
|
|
|
## Perimetre observe
|
|
|
|
- page d'accueil publique ;
|
|
- structure applicative React / Vite ;
|
|
- dashboard association ;
|
|
- composants de navigation laterale ;
|
|
- composants de formulaire et de dialogue ;
|
|
- theme et comportements visuels generaux.
|
|
|
|
## Lecture generale
|
|
|
|
Le portail dispose deja d'un socle utile :
|
|
|
|
- `lang="fr"` defini dans [client/index.html](/Users/selecta/Documents/portail-associations/client/index.html)
|
|
- composants UI avec nombreuses gestions `focus-visible`
|
|
- labels caches (`sr-only`) presents sur plusieurs composants
|
|
- structure de boutons et controles deja assez riche
|
|
- plusieurs zones admin et dashboard deja pensees en navigation clavier
|
|
|
|
Mais il reste plusieurs chantiers importants pour atteindre un niveau RGAA plus solide et plus defendable.
|
|
|
|
## Constats principaux
|
|
|
|
### 1. Absence apparente de lien d'evitement
|
|
|
|
Je n'ai pas trouve de lien de type :
|
|
|
|
- `Aller au contenu`
|
|
- `Aller a la navigation`
|
|
|
|
Ce point est prioritaire pour l'accessibilite clavier et lecteur d'ecran.
|
|
|
|
Zones concernees :
|
|
|
|
- [client/src/App.tsx](/Users/selecta/Documents/portail-associations/client/src/App.tsx)
|
|
- [client/src/pages/Home.tsx](/Users/selecta/Documents/portail-associations/client/src/pages/Home.tsx)
|
|
- [client/src/pages/Dashboard.tsx](/Users/selecta/Documents/portail-associations/client/src/pages/Dashboard.tsx)
|
|
|
|
### 2. Landmarks et structure semantique encore incomplets
|
|
|
|
Le socle React route bien les pages, mais il reste a verifier et renforcer :
|
|
|
|
- presence systematique de `<main>`
|
|
- structure des `<header>`, `<nav>`, `<footer>`
|
|
- region principale unique par page
|
|
- titres de page coherents
|
|
|
|
Aujourd'hui, plusieurs vues semblent surtout composees de `div` structurelles.
|
|
|
|
### 3. Navigation mobile publique a clarifier
|
|
|
|
Dans [client/src/pages/Home.tsx](/Users/selecta/Documents/portail-associations/client/src/pages/Home.tsx), le bouton mobile du menu ouvre une `Sheet`, mais le declencheur icone n'expose pas clairement de libelle explicite dans le code visible.
|
|
|
|
Il faut consolider :
|
|
|
|
- `aria-label`
|
|
- annonce claire du menu
|
|
- ordre de tabulation
|
|
- retour du focus a la fermeture
|
|
|
|
### 4. Cohabitation riche visuelle / lisibilite
|
|
|
|
Le portail a beaucoup progresse visuellement, mais l'habillage immersif peut exposer plusieurs risques RGAA si non cadres :
|
|
|
|
- contrastes insuffisants selon certains fonds
|
|
- surcharge visuelle sur mobile
|
|
- decor trop present autour des CTA ou cartes
|
|
- lisibilite variable selon voile, blur, image et mode de presentation
|
|
|
|
Le module Apparence doit donc rester borne par des garde-fous accessibilite.
|
|
|
|
### 5. Gestion des erreurs et aides de formulaire a renforcer
|
|
|
|
Le code montre deja des `aria-invalid` sur certains champs, ce qui est bon.
|
|
|
|
Mais il reste a systematiser :
|
|
|
|
- `aria-describedby` pour rattacher aide + erreur
|
|
- messages d'erreur explicites en texte
|
|
- regroupement logique des champs
|
|
- annonce claire des etapes et validations
|
|
|
|
### 6. Composants interactifs a auditer par famille
|
|
|
|
Le design system interne parait plutot bien parti, mais il faut verifier de facon methodique :
|
|
|
|
- boutons icones
|
|
- toggles
|
|
- menus deroulants
|
|
- panneaux lateraux
|
|
- dialogues
|
|
- onglets et filtres
|
|
- cartes cliquables
|
|
|
|
En RGAA, les problemes viennent souvent des composants reutilises partout.
|
|
|
|
### 7. Motion, scroll et confort utilisateur
|
|
|
|
Le portail contient des transitions et micro-interactions utiles.
|
|
|
|
Il faut toutefois verifier :
|
|
|
|
- respect du `prefers-reduced-motion`
|
|
- absence de blocage au scroll
|
|
- absence d'animations perturbantes
|
|
- confort tactile et clavier equivalent
|
|
|
|
## Niveau de priorite recommande
|
|
|
|
### P1 - A traiter rapidement
|
|
|
|
- lien d'evitement global
|
|
- vrai `<main id="main-content">` sur toutes les vues
|
|
- labels explicites pour les boutons icones critiques
|
|
- focus management des sheets, menus et dialogues
|
|
- verification contraste CTA / textes / badges sur fonds dynamiques
|
|
|
|
### P2 - A traiter dans la passe suivante
|
|
|
|
- systematisation des aides et erreurs formulaire
|
|
- coherences des titres H1/H2/H3
|
|
- nettoyage des zones tres decoratives sur mobile
|
|
- controle des composants collapsibles, onglets et cartes cliquables
|
|
|
|
### P3 - A industrialiser
|
|
|
|
- matrice RGAA par composant
|
|
- checks visuels recurrents
|
|
- procedure de recette accessibilite preprod / prod
|
|
- revue continue du module Apparence avec garde-fous UX + accessibilite
|
|
|
|
## Roadmap d'execution
|
|
|
|
### Phase 1 - Socle semantique
|
|
|
|
- ajouter un lien d'evitement global
|
|
- ajouter une region principale unique par page
|
|
- verifier les `aria-label` manquants sur boutons icones critiques
|
|
- verifier la logique clavier du header public et des sidebars
|
|
|
|
### Phase 2 - Navigation et composants
|
|
|
|
- auditer `Sheet`, `Dialog`, `DropdownMenu`, `Tabs`, `Sidebar`
|
|
- renforcer la restitution du focus
|
|
- homogeneiser les intitules d'action
|
|
- verifier les zones cliquables et les cartes interactives
|
|
|
|
### Phase 3 - Formulaires et retours utilisateur
|
|
|
|
- rattacher chaque aide a son champ
|
|
- rattacher chaque erreur a son champ
|
|
- annoncer clairement succes, echec et etape
|
|
- verifier les parcours association les plus utilises
|
|
|
|
### Phase 4 - Apparence et confort visuel
|
|
|
|
- poser des seuils de contraste minimaux
|
|
- encadrer les reglages de voile / blur / fonds immersifs
|
|
- limiter les cas ou l'image parasite la lecture
|
|
- verifier le rendu mobile reel
|
|
|
|
### Phase 5 - Industrialisation
|
|
|
|
- checklist RGAA par release
|
|
- controles manuels desktop/mobile
|
|
- documentation courte "avant mise en prod"
|
|
- tableau de suivi par composant critique
|
|
|
|
## Checklist CSS / front
|
|
|
|
### Structure
|
|
|
|
- [ ] ajouter un lien `Aller au contenu`
|
|
- [ ] ajouter `id="main-content"` sur la region principale
|
|
- [ ] garantir un seul `<main>` par page
|
|
- [ ] verifier un H1 clair sur chaque vue majeure
|
|
|
|
### Navigation
|
|
|
|
- [ ] chaque bouton icone a un nom accessible
|
|
- [ ] chaque menu mobile restitue le focus proprement
|
|
- [ ] chaque sidebar est utilisable au clavier
|
|
- [ ] les liens actifs sont identifies visuellement et semantiquement
|
|
|
|
### Formulaires
|
|
|
|
- [ ] chaque champ obligatoire est annonce clairement
|
|
- [ ] chaque message d'erreur est relie au champ
|
|
- [ ] chaque aide utile est reliee via `aria-describedby`
|
|
- [ ] les validations sont comprehensibles sans couleur seule
|
|
|
|
### Visuel / CSS
|
|
|
|
- [ ] contraste texte / fond valide sur CTA principaux
|
|
- [ ] contraste badges / statuts valide
|
|
- [ ] focus visible partout
|
|
- [ ] aucun `outline: none` sans remplacement fort
|
|
- [ ] habillage immersif borne par des regles de contraste
|
|
- [ ] transparences limitees sur les zones fonctionnelles
|
|
- [ ] contenu lisible avec zoom navigateur
|
|
|
|
### Motion / confort
|
|
|
|
- [ ] prise en charge de `prefers-reduced-motion`
|
|
- [ ] transitions non bloquantes
|
|
- [ ] pas de scroll piege
|
|
- [ ] pas d'information transmise uniquement par animation
|
|
|
|
### Mobile
|
|
|
|
- [ ] navigation publique lisible sur petit ecran
|
|
- [ ] boutons CTA empiles sans collision
|
|
- [ ] sidebar admin mobile avec comportement propre
|
|
- [ ] calendrier mobile lisible et operable
|
|
|
|
## Recommandation produit
|
|
|
|
La bonne strategie ici n'est pas de "faire un audit RGAA a la fin".
|
|
La bonne strategie est de faire du **RGAA par couches** :
|
|
|
|
1. socle semantique
|
|
2. composants partages
|
|
3. parcours critiques
|
|
4. garde-fous visuels sur Apparence
|
|
5. verification continue
|
|
|
|
## Definition de fini raisonnable
|
|
|
|
On pourra considerer la passe RGAA serieuse lorsque :
|
|
|
|
- le portail a un lien d'evitement global ;
|
|
- les vues principales ont une region `<main>` fiable ;
|
|
- les composants critiques passent en navigation clavier ;
|
|
- les formulaires critiques ont erreurs + aides rattachees ;
|
|
- les reglages immersifs sont encadres par la lisibilite ;
|
|
- une checklist de recette accessibilite est jouee avant publication.
|