Accessibilité du site akiani.fr

Partiellement conforme au RGAA 4.1.2, par alignement volontaire. Le site n'est pas soumis à l'obligation légale (article 47 de la loi n° 2005-102, qui vise les organisations à plus de 250 millions d'euros de chiffre d'affaires). On publie quand même cette déclaration et le schéma pluriannuel ci-dessous, parce qu'on conçoit des produits numériques pour des organisations qui, elles, y sont soumises. Pratiquer ce qu'on prêche est plus solide que de le défendre en plaquette commerciale.

Méthode

Audit interne avec axe-core 4.11, jeu de règles WCAG 2.1 niveau AA, sur 186 pages au 28 mai 2026. Le site en compte 474 au 14 août 2026, dont 237 en français : l'audit automatique est à relancer sur ce périmètre, et il figure au plan d'action ci-dessous. On a aussi mené un audit dédié à l'ordre de tabulation et au focus visible (RGAA 10.7, 12.7, 12.8, 12.9) sur 10 gabarits desktop représentatifs. La vérification manuelle critère par critère n'a pas été menée sur l'ensemble du site, et il n'y a pas d'audit tiers.

Ce qu'on ne peut pas encore afficher, c'est le taux de conformité, autrement dit le pourcentage des 106 critères du RGAA 4.1.2 qui sont respectés. On ne l'affiche pas parce qu'on ne l'a pas mesuré : le calculer suppose l'évaluation manuelle critère par critère, qui est justement ce qui reste à faire. L'état « partiellement conforme » qu'on revendique s'appuie sur l'audit automatique et sur l'audit clavier décrits ici, pas sur les 106 critères. Le taux apparaîtra sur cette page quand l'audit manuel des parcours-clés sera terminé.

Résultats

182 pages sur 186 sans violation détectée par l'outil. axe-core couvre environ un tiers du RGAA, celui des règles automatisables. Sur ce périmètre et hors iframes tierces, le site ne remonte aucune violation.

Contenus non conformes. Aucune violation WCAG 2.1 AA détectée par l'audit automatique en dehors des iframes tierces. Les écarts que l'audit manuel révélera seront listés ici, critère par critère.

Contenus exemptés. Quatre pages portent des violations situées à l'intérieur d'une iframe fournie par un tiers : Spline 3D, INA Fresques, un embed Facebook et le lecteur TED. C'est du code envoyé par ces éditeurs, qu'on ne maîtrise pas. Si le contenu de l'une de ces iframes vous est inaccessible, écrivez‑nous et on vous le transmet sous une autre forme.

Dérogations pour charge disproportionnée. Aucune à ce jour.

Corrections passées pendant cette campagne

Token de contraste sur le fil d'Ariane des études de cas (61 pages).
Attribut title sur l'iframe YouTube de l'article Weezdays, pour qu'elle porte un nom accessible.
Attribut title ajouté à 5 iframes tierces non-YouTube.
aria-hidden remplacé par inert sur le CTA scroll-piloté de la page identité.
aria-label défensif et saut des sections vides dans les sommaires d'articles construits en JavaScript.
Trois liens vides supprimés sur d'anciens articles WordPress (deux liens ne contenant qu'un <br>, un lien entourant une image décorative).
Audit clavier sur 10 gabarits desktop : skip link en tête de tabulation, pas de piège, pas de tabindex positif, focus visible sur tous les éléments interactifs.

Établissement de cette déclaration

Déclaration établie le 27 mai 2026, mise à jour le 14 août 2026.

Technologies utilisées sur le site : HTML, CSS, JavaScript et SVG.

Outils d'évaluation : axe-core 4.11 avec le jeu de règles WCAG 2.1 niveau AA, exécuté en Chrome sans interface sur la version de production, et un audit clavier manuel sur 10 gabarits desktop. Le test au lecteur d'écran n'a pas encore eu lieu : il figure au plan d'action 2026, pas ici.

Pages testées pour l'audit clavier : l'accueil, notre identité, savoir-faire, nos valeurs, notre équipe, le sommaire du blog, l'article « 3 leçons UX tirées des ransomwares », la définition « arborescence » du glossaire, l'étude du Lab « UXDevil », et cette page.

Une réserve sur la trame qu'on reprend : elle prévoit des voies de recours devant le Défenseur des droits, qui existent pour les organismes soumis à l'obligation. On n'en fait pas partie, donc ce recours ne s'applique pas à nous. Ça ne change rien à l'engagement de la section Contact : un écart signalé reçoit une réponse.

Limites

La vérification manuelle critère par critère et le test au lecteur d'écran sur l'ensemble du site restent à mener, comme l'audit par un tiers indépendant. L'audit clavier porte pour l'instant sur le desktop. Le menu mobile et le comportement du focus dans les états ouverts (modales, filtres dépliés) restent à vérifier.

On reprend la trame DINUM utilisée par les organismes soumis à l'article 47, pour deux raisons. D'abord, c'est plus simple de parler la même langue que nos clients qui, eux, y sont soumis. Ensuite, un schéma pluriannuel oblige à écrire ce qu'on va faire dans trois ans, et donc à le faire. Le schéma couvre le site akiani.fr et nos pratiques internes (méthode projet, formation, livrables clients).

Politique d'accessibilité

Le site akiani.fr vise la conformité WCAG 2.1 AA. Sur les projets qu'on mène pour des clients, on intègre l'accessibilité dès la conception, à la mesure de ce qui est commandé. Ce n'est pas toujours explicite dans le devis, mais c'est toujours dans la méthode.

Ressources affectées

L'équipe interne porte la démarche (UX research, UX/UI design, intégration). On ne s'est pas payé un consultant accessibilité dédié, mais on a prévu un audit tiers en 2027 pour confronter notre travail à un regard extérieur.

Organisation

L'accessibilité est outillée dans le dépôt du site. On a un guide de conception qui passe par sept perspectives usagers (du déficient visuel à la personne avec un trouble cognitif), un audit axe-core qui se relance sur la version de production, et une vingtaine de garde-fous d'intégration documentés à partir des erreurs qu'on a déjà commises. Sébastien Klifa est référent accessibilité numérique. Il coordonne les audits, la formation de l'équipe et le suivi des signalements, et porte le sujet dans les projets clients.

Prise en compte de l'accessibilité dans les projets

Sur akiani.fr, tout ajout de composant interactif (modale, dropdown, carrousel) passe par un cadrage avant écriture, puis par un audit automatique après. Sur les projets clients, on intègre progressivement l'accessibilité dans les phases qu'on prend en charge : un brief qui pose la question, une recherche qui inclut des personnes en situation de handicap quand le sujet s'y prête, des wireframes qui pensent au lecteur d'écran, une recette qui vérifie.

Formation des équipes

On monte en compétence en continu sur le RGAA, les patterns ARIA et le test au lecteur d'écran. On vise une session par an pour toute l'équipe, tracée dans le bilan annuel.

Recours à des compétences externes

L'audit tiers indépendant est planifié en 2027. On fait appel ponctuellement à des compétences extérieures quand le sujet l'exige : un test avec un utilisateur sur une déficience rare, une expertise sur une norme métier qu'on ne maîtrise pas.

Tests utilisateurs

On inclut des personnes en situation de handicap dans les recherches utilisateurs des projets clients quand le produit s'adresse à elles ou que le sujet l'appelle. Sur akiani.fr, un test au lecteur d'écran (VoiceOver, NVDA) est programmé sur les parcours-clés en 2026.

Agenda des audits

Audit axe-core, à chaque mise en production significative.
Audit manuel critère par critère, sur les parcours-clés en 2026 puis sur l'ensemble du site en 2027.
Audit tiers indépendant en 2027.

Ordre des corrections

Les corrections suivent l'audience : les parcours-clés d'abord (accueil, savoir-faire, études de cas, contact), puis les pages les plus consultées, puis le reste. Un écart qui empêche l'usage passe devant, quelle que soit l'audience de la page.

Accessibilité renforcée

On ne prévoit ni traduction en langue des signes ni version en langage simplifié sur akiani.fr. C'est un site de présentation, et cet effort a plus de valeur sur les services publics qu'on conçoit pour nos clients que sur nos propres pages. Sur demande, on transmet un contenu sous une autre forme.

Traitement des retours utilisateurs

Si vous signalez un écart à hello@akiani.fr, on répond sous 5 jours ouvrés en disant ce qu'on va faire et quand. Les écarts qui empêchent l'usage passent en priorité, les autres rejoignent le plan en cours.

Audit axe-core complet sur les 186 pages publiées au 28 mai 2026 (fait). À relancer sur les 474 pages du site (à venir).
Correction de toutes les violations WCAG AA détectées hors iframes tierces (fait).
Outillage interne : guide accessibilité par perspectives utilisateurs + agent d'audit automatique (fait).
Audit manuel critère par critère sur les parcours-clés (accueil, savoir-faire, études de cas, contact) (en cours), volet clavier et focus (RGAA 10.7, 12.7, 12.8, 12.9) couvert sur 10 gabarits desktop.
Test lecteur d'écran (VoiceOver, NVDA) sur 10 pages représentatives (à venir).
Formalisation d'une fiche pratique « accessibilité dans les projets Akiani » à usage interne (à venir).
Première session de formation accessibilité de l'équipe (à venir).

Plan d'action 2027 (prévisionnel)

Audit tiers indépendant de conformité RGAA 4.1.2.
Audit manuel critère par critère étendu à l'ensemble du site.
Intégration systématique d'un volet accessibilité dans les devis projet.
Production des livrables clients (présentations, rapports) en format accessible par défaut.
Bilan public de l'année 1 publié sur cette page.