Accessibilité du site Psychaventure

Le site Psychaventure a été conçu avec le souci d’une accessibilité maximale, dans les limites techniques de l’environnement de publication utilisé (Blocs App, Volt CMS et PHP).
Nous avons porté une attention particulière à la clarté de la structure HTML, à l’usage des balises sémantiques, aux liens d’évitement (skip links), au contraste des textes et à la navigation au clavier.

Cependant, malgré ces efforts, certains composants générés automatiquement (comme les menus ou panneaux latéraux) peuvent poser des problèmes aux lecteurs d’écran ou à la navigation strictement clavier.
Ces limitations tiennent à la manière dont certains éléments interactifs sont rendus par les outils de conception, et échappent partiellement à notre contrôle.

Nous avons choisi de ne pas masquer ces défauts, mais au contraire de les documenter, de les comprendre et de les rendre visibles dans notre processus de développement.

⸻

Une démarche plus qu’un label

Nous ne revendiquons pas une conformité stricte aux normes d’accessibilité (type WCAG 2.1), que peu de sites respectent réellement — y compris ceux conçus par des professionnels.
Le site de Psychaventure n’est clairement pas totalement accessible, malgré tous les efforts déployés. Nos compétences et nos contraintes nous ont orientés vers des outils logiciels adaptés à notre projet éditorial, mais qui ne permettent pas une accessibilité complète.

Nous revendiquons donc une démarche transparente, lucide et perfectible, dans laquelle l’accessibilité n’est ni une case à cocher, ni une promesse commerciale, mais une exigence éthique.

⸻

Problèmes d’accessibilité connus

Voici la liste des limitations actuellement identifiées sur ce site, en cours de documentation ou de correction progressive (ces soucis peuvent apparaître différemment selon le navigateur que vous utilisez et les options que vou y avez activées) :

1. Menus et offcanvas (panneaux latéraux)
•Le bouton de fermeture () n’a pas de rôle explicite (role="button") ni de tabindex, ce qui le rend inaccessible à la navigation clavier seule.
•Le focus n’est pas géré correctement lors de l’ouverture ou fermeture du menu mobile (notamment le menu « Nos précédentes newsletters »).
•Certains boutons interactifs ne sont pas annoncés comme tels par les lecteurs d’écran.

Origine probable : composants générés par Blocs App ou par certains addons (brics), avec du HTML non optimisé pour l’accessibilité.

⸻

2. Comportement du focus
•Le focus ne revient pas de manière logique après la fermeture d’une modale ou d’un menu.
•Aucun piège clavier détecté, mais la navigation peut être désorientante, notamment avec VoiceOver sur Mac.
•Certains éléments ne reçoivent pas de focus visible selon les navigateurs.

⸻

3. Aria et rôles redondants ou mal interprétés
•Des balises role="main" sont utilisées en redondance avec la balise , en raison d’une contrainte structurelle propre à Blocs App. Ce n’est pas bloquant, mais ce serait inutile si le HTML était sémantiquement correct de manière native.
•Certains lecteurs d’écran interprètent mal ou ignorent certaines structures, malgré un balisage valide.

⸻

4. Icônes décoratives mal exposées
•Les icônes sociales ou décoratives (flèches, chevrons, croix) ne sont pas toutes cachées aux technologies d’assistance (aria-hidden="true" manquant).
•Ces icônes font partie de composants intégrés aux logiciels utilisés ; nous ne pouvons pas les modifier directement.
•Certaines sont lues à tort comme du contenu informatif sans signification.

⸻

5. Skip links non toujours visibles
•Les liens d’évitement (skip to main content) sont présents dans le code mais pas toujours visibles, selon le navigateur ou le moment de chargement.
•VoiceOver ne les lit pas systématiquement, malgré leur présence technique.

⸻

6. Tests manuels : VoiceOver et navigation clavier
•VoiceOver sur Safari Mac ne permet pas une navigation fluide : sauts de sections, répétition de blocs, absence de retour vocal sur les changements de contexte.
•La navigation au clavier seule est possible, mais peu agréable à cause de la gestion approximative du focus sur certains éléments dynamiques.

⸻

En résumé

Ces limites sont connues, suivies et — autant que possible — atténuées à chaque évolution du site. Elles tiennent principalement :
•aux comportements par défaut de certains brics ou composants de Blocs App,
•à la structure HTML générée automatiquement,
•à l’absence d’API ou d’outils natifs pour l’accessibilité dans Volt CMS ou Blocs App.
Il faut également noter que structurellement le web n’a pas été pensé pour l’accessibilité. Le chantier de l’adaptation est en cours, nous le suivons et mettrons à jour notre site à chaque amélioration apportée.

⸻

Limitations et cadre réaliste

Certaines interactions ou structures du site peuvent encore poser problème à certains outils d’assistance (lecteurs d’écran, navigation clavier stricte, etc.).
Ces limitations techniques tiennent en grande partie aux outils de publication utilisés, et ne peuvent pas toutes être contournées sans compromettre la stabilité générale du site.

Nous en avons conscience, et nous avons choisi de documenter ces limites plutôt que les dissimuler.
Le site reste en évolution, et chaque amélioration possible en matière d’accessibilité est intégrée dès qu’elle devient techniquement réalisable dans notre cadre de développement.