Le rapport d'audit est-il à la marque de mon agence ?

Oui. Vous chargez votre modèle (logo, couleurs, mentions) et le rapport est généré dedans, éditable et prêt à livrer. Inclusible n'apparaît pas dans le document remis à votre client.

L'IA peut-elle remplacer un auditeur RGAA certifié ?

L'IA réalise l'essentiel de l'analyse (déterministe, navigation clavier, lecture de l'arbre d'accessibilité, jugement sémantique), mais c'est l'agence qui valide et signe le rapport. La revue met en avant les cas à faible confiance.

Qui est concerné par l'obligation d'accessibilité RGAA ?

Depuis le 28 juin 2025, l'obligation s'étend au secteur privé : entreprises de plus de 10 salariés ou réalisant plus de 2 millions d'euros de chiffre d'affaires. Les sanctions atteignent 50 000 € pour non-conformité technique, renouvelables tous les 6 mois.

Combien coûte un audit d'accessibilité RGAA avec Inclusible ?

La tarification est à l'usage : 89 € par rapport plus 2,90 € par page analysée. Pas d'abonnement ni d'engagement — vous payez uniquement les audits que vous produisez, et vous fixez librement votre prix de revente à votre client.

Quelle est la différence entre le RGAA et les WCAG ?

Les WCAG sont le standard international d'accessibilité web du W3C. Le RGAA est le référentiel français qui décline ces exigences en 106 critères concrets et vérifiables, répartis en 13 thématiques, avec une méthode de test officielle. Se conformer au RGAA revient à respecter les WCAG niveau AA.

Combien de temps prend un audit d'accessibilité avec Inclusible ?

L'analyse automatisée d'un site prend quelques minutes : capture des pages, tests déterministes (axe-core), navigation clavier, lecture de l'arbre d'accessibilité et jugement sémantique par IA. L'agence relit ensuite les cas signalés à faible confiance et valide le rapport avant livraison.

Technique

Accessibilité des applications React : les pièges des SPA

Changement de route sans rechargement, focus perdu, contenus dynamiques muets : les défauts d'accessibilité propres aux applications monopages, et comment les corriger.

30 octobre 2026

Le problème structurel des SPA

Dans une application monopage, la navigation ne recharge pas la page. Pour un lecteur d'écran, rien ne s'est passé : pas de nouveau titre annoncé, pas de focus réinitialisé. L'utilisateur reste sur un contenu qui a disparu. C'est le défaut le plus caractéristique — et le plus souvent ignoré — des applications React, Vue ou Angular.

Les quatre corrections essentielles

Annoncer le changement de route : mettre à jour le title du document et déplacer le focus sur le titre principal de la nouvelle vue ;
Gérer le focus des modales : le piéger volontairement à l'intérieur tant qu'elle est ouverte, et le restituer à l'élément déclencheur à la fermeture ;
Annoncer les contenus dynamiques : chargements, résultats filtrés, notifications de succès — via une région aria-live dimensionnée pour ne pas être bavarde ;
Utiliser les éléments natifs : button, a, input apportent gratuitement le clavier, le focus et le rôle. Les recréer en div avec des attributs ARIA reproduit au mieux ce que le navigateur offre déjà.

> La première règle d'ARIA — Ne pas utiliser ARIA. Un role="button" sur un div exige d'implémenter à la main le focus, la touche Entrée, la barre d'espace et l'état désactivé. Un button fait tout cela sans une ligne de code.

Le rendu et l'audit

Une application rendue côté client n'expose son contenu qu'après exécution du JavaScript. Un audit crédible doit donc analyser le DOM final, après hydratation — ce qu'un outil qui se contente du HTML servi ne voit pas. C'est une contrainte technique de l'outillage, pas un détail méthodologique.

Tester en continu

Des vérifications automatisées dans les tests de composants attrapent les régressions les plus mécaniques. Elles ne remplacent pas l'audit, mais évitent de le repasser entièrement à chaque livraison.

---

À lire aussi

PartagerLinkedIn Email

← Toutes les ressources