Déclaration d'accessibilité

Établie le 19 mai 2026 · Mise à jour le 13 septembre 2026 (audit des interfaces construites en JavaScript)

Wilder Labs s'engage à rendre son site Sallia accessible conformément à l'article 47 de la loi n° 2005-102 du 11 février 2005.

À cette fin, nous mettons en œuvre la stratégie et les actions suivantes : plan d'action ci-dessous.

Cette déclaration d'accessibilité s'applique à https://sallia.fr (portail habitant, espace association, tableau de bord administrateur).

État de conformité

Sallia est partiellement conforme au référentiel général d'amélioration de l'accessibilité (RGAA) version 4.1.

Cette déclaration repose sur une auto-évaluation interne initiale du 19 mai 2026, complétée par un audit intégral interne le 28 mai 2026 (cf. page Sécurité & transparence). Les non-conformités d'accessibilité identifiées par cet audit ont été corrigées et déployées sous 24 h ; le statut « partiellement conforme » est conservé en attente de la validation par un cabinet certifié indépendant.

Un audit RGAA AA par un cabinet certifié est planifié au 3^e trimestre 2026 et donnera lieu à une publication officielle du taux de conformité selon le modèle de déclaration RGAA publié par la DINUM (voir plan d'amélioration).

Résultats des tests

Synthèse au 28 mai 2026 (auto-évaluation cumulée des deux audits internes) :

• Critère 7.3 — Composants fonctionnels avec intitulé : conforme (100 %)
• Critère 11.1 — Étiquettes des champs de formulaire : partiellement conforme. La mesure du 28 mai 2026 (« 178/178 ») ne portait que sur le HTML statique et omettait les formulaires construits en JavaScript, qui ne s'affichent qu'après ouverture d'une fenêtre ou dépliage d'un bloc. Un audit ciblé du 13 septembre 2026 y a trouvé une quarantaine de champs dont l'étiquette visible n'était associée à aucun contrôle : elle s'affichait sans jamais être annoncée par un lecteur d'écran. Corrigés le jour même — l'espace famille passe de 29 à 65 champs correctement étiquetés, et le formulaire public de gestion du bureau associatif génère désormais l'association qui lui manquait. Les deux libellés désignant un groupe de cases (allergènes, jours d'ouverture) ont reçu un conteneur role="group" nommé, puisqu'un for ne peut viser qu'un seul champ. Les cas restants sont listés en « Contenus non accessibles ».
• Critère 10.7 — Focus visible : conforme (focus-visible appliqué via tokens.css, et explicitement sur les boutons du calendrier de réservation et la fermeture des modales)
• Critère 12.8 — Ordre de tabulation : conforme
• Critère 9.1 — Hiérarchie des titres : conforme (h1 unique par page, hiérarchie respectée)
• Critère 3.2 — Contraste des couleurs : conforme — audit manuel des tokens du 13 mai 2026, complété le 28 mai (cellule « aucun tarif » remontée de #cbd5e1 à #94a3b8 → 3.2 : 1). Paires principales texte/fond toutes ≥ 4.5 : 1 (AA)
• Critère 4.1.2 / 13.7 — Composants atteignables au clavier : partiellement conforme. Le calendrier de réservation l'est depuis le 28 mai (vraies balises <button type="button"> focusables, jours indisponibles en <div aria-disabled>). Mais l'audit du 13 septembre 2026 a établi que l'ajout d'une photo était impossible au clavier : les deux déclencheurs étaient des <label>, non focalisables, et le champ de fichier qu'ils commandaient était retiré de l'ordre de tabulation. Corrigé le jour même — ce sont désormais de vrais boutons. Un audit équivalent reste à mener sur les autres composants construits en JavaScript.
• Critère 2.5.5 — Taille des cibles tactiles (44 × 44 px min) : conforme depuis le 28 mai — boutons de fermeture de modales remontés de 36 à 44 px
• Critère 12.6 — Liens d'évitement (skip-links) : conforme — présents sur toutes les pages publiques (landing, aide, fonctionnalités, mentions légales, CGU, sécurité), avec style focus géré en CSS (et non en attribut onfocus=) pour compatibilité avec la CSP stricte
• Critère 10.6 — Liens identifiables : conforme depuis le 28 mai — liens de footer du portail dotés d'une couleur d'accent distinguable, soulignement au survol/focus
• Critère 8.9 / 8.10 — Internationalisation : conforme (lang="fr" sur toutes les pages)

Contenus non accessibles

Les non-conformités identifiées lors de l'audit du 28 mai 2026 ont été corrigées sous 24 h (cf. rapport public). Un audit complémentaire du 13 septembre 2026, portant cette fois sur les interfaces construites en JavaScript — celles qui n'apparaissent qu'après ouverture d'une fenêtre ou dépliage d'un bloc, et qu'aucun contrôle automatique ne parcourait — a mis au jour des non-conformités que la déclaration précédente ne pouvait pas connaître. Elles sont énoncées ici sans détour :

• Corrigé le 13 septembre — une quarantaine de champs de formulaire sans nom accessible (espace famille, espace association public). L'étiquette était affichée mais n'était associée à aucun champ.
• Corrigé le 13 septembre — l'ajout d'une photo était impossible au clavier : les déclencheurs n'étaient pas focalisables et le champ de fichier était hors de l'ordre de tabulation.
• Corrigé le 13 septembre — sept indicateurs « Connexion requise » du portail public portaient un nom accessible sur un élément qui ne peut pas en recevoir, et étaient donc ignorés par certains lecteurs d'écran.
• Corrigé le 13 septembre — 48 éléments des écrans d'administration portaient un nom accessible sur une balise qui ne peut pas en recevoir. Chacun a été examiné individuellement, car le bon correctif dépend du contenu : l'attribut a été retiré là où il masquait un texte visible (27 cas), remplacé par un rôle d'image là où l'élément n'est qu'un symbole ou une icône (14 cas), ou par un rôle de conteneur pour les régions d'annonce et les groupes dont le repère visuel est masqué (7 cas). Un contrôle automatique interdit désormais leur réapparition.
• Corrigé le 13 septembre — plusieurs boutons et liens dont le nom accessible ne commençait pas par leur libellé visible, ce qui empêchait de les activer à la voix. Le titre principal de l'espace d'administration était dans ce cas et, plus gênant, son libellé masquait le nom de la commune : l'utilisateur n'était plus informé de l'espace sur lequel il travaillait.

Restent à faire vérifier par un audit externe :

• Validation tierce de la conformité des contrastes via outils automatisés (axe-core, Wave, Lighthouse a11y).
• Tests utilisateurs avec lecteurs d'écran (NVDA, VoiceOver, JAWS).
• Audit fin des composants dynamiques complexes (plan 2D interactif, scanner QR, modale d'état des lieux multi-onglets).
• Parcours complet des écrans accessibles après interaction — c'est précisément l'angle mort que l'audit du 13 septembre a révélé, et il ne peut être levé qu'en ouvrant chaque fenêtre et chaque formulaire.
• Vérification de l'audit typographique français complet (espaces insécables avant : ; ? !) — les chaînes principales sont conformes, un passage exhaustif reste à faire.

Plan d'amélioration

• ✅ 28 mai 2026 : audit interne intégral (4 sous-audits parallèles) — toutes les non-conformités d'accessibilité identifiées corrigées et déployées en production. Tests E2E Playwright ajoutés en CI pour garantir la non-régression (CSP nonces, scripts inline fonctionnels, calendrier clavier).
• Q3 2026 : publication de la déclaration officielle selon le modèle RGAA de la DINUM.
• Q3 2026 : audit RGAA AA tiers externe (cabinet certifié) — validation indépendante avec mesure de taux officiel.
• Q3 2026 : audit typographique français exhaustif (NBSP avant : ; ? ! sur l'ensemble des chaînes serveur-rendered).
• Q4 2026 : passage en revue annuel + mise à jour du présent document.
• Continu : tout nouveau composant intègre les patterns d'accessibilité dès la conception (helpers a11y.js, focus-trap modales, aria-modal automatique, sprite SVG icons.svg, CSP nonces sur scripts inline).

Établissement de cette déclaration

Cette déclaration a été établie le 19 mai 2026.

Technologies utilisées pour la réalisation du site : HTML5, CSS3, JavaScript (ES2020+).

Tests effectués sur Chrome 125 + Firefox 126 (desktop et mobile), avec inspection manuelle DevTools accessibility tree.

Référent accessibilité

Conformément à l'article 47 de la loi n° 2005-102 du 11 février 2005, un référent accessibilité numérique est identifié :

• G. Richard, responsable accessibilité numérique, Wilder Labs (entrepreneur individuel)
• Par e-mail : accessibilite@sallia.fr
• Par e-mail (général) : contact@sallia.fr

Si vous n'arrivez pas à accéder à un contenu ou à un service, n'hésitez pas à nous le signaler. Nous nous engageons à répondre sous 5 jours ouvrés.

Voies de recours

Si vous constatez un défaut d'accessibilité vous empêchant d'accéder à un contenu ou une fonctionnalité du site, que vous nous le signalez et que vous ne parvenez pas à obtenir une réponse de notre part, vous êtes en droit de saisir le Défenseur des droits.

Plusieurs moyens sont à votre disposition :

• Écrire un message : formulaire.defenseurdesdroits.fr
• Contacter un délégué : defenseurdesdroits.fr/saisir/delegues
• Envoyer un courrier : Défenseur des droits — Libre réponse 71120 — 75342 Paris CEDEX 07