Accessibilité RGAA : ce qu’une PME doit vraiment livrer

Le RGAA est le référentiel français qui opérationnalise les exigences d’accessibilité numérique, en s’alignant sur les WCAG (Web Content Accessibility Guidelines). Il organise des critères et des tests pour vérifier si un service en ligne est utilisable par le plus grand nombre, y compris les personnes en situation de handicap.

Ce n’est pas une certification magique délivrée par un plugin. Ce n’est pas non plus une obligation identique pour toutes les PME du secteur privé. Le cadre légal français vise d’abord les acteurs publics et certains organismes ; le privé est concerné selon seuils, secteurs et évolutions européennes (dont l’European Accessibility Act pour certains services). Votre première tâche est donc de situer votre obligation réelle, pas de « cocher le RGAA » par panique.

Pour une PME hors obligation stricte, le RGAA reste néanmoins le meilleur guide pratique. Il évite de réinventer une norme maison. Travailler « dans l’esprit RGAA / WCAG AA » sur les parcours critiques améliore la qualité produit, réduit le risque juridique futur et prépare les réponses aux appels d’offres.

Enfin, accessibilité n’égale pas seulement handicap permanent. Elle couvre des situations temporaires (bras cassé, écran au soleil, environnement bruyant) et des contextes métiers (tablette atelier, clavier uniquement). Un site accessible est souvent simplement un site mieux conçu.

Dans la sphère publique (État, collectivités, organismes concernés), l’accessibilité numérique s’accompagne d’obligations de transparence : déclaration d’accessibilité, schéma pluriannuel, plan d’action, mention du statut de conformité. Le référentiel de contrôle est le RGAA. Un prestataire qui livre un site public doit anticiper audit, correctifs et documentation — pas seulement « un site joli ».

Dans le privé, la situation est plus nuancée. Certaines grandes entreprises et certains secteurs de services sont soumis à des obligations spécifiques. Beaucoup de TPE/PME hors ces cas ne sont pas tenues au même formalisme immédiat. Cela ne signifie pas « rien à faire » : un client, un assureur, un partenaire ou un acheteur public peut exiger un niveau d’accessibilité dans le contrat.

Pour une PME qui répond à un marché public en sous-traitance ou en lot web, alignez-vous sur le niveau exigé dès le cahier des charges. Demandez si un audit RGAA est livrable contractuel, qui le finance, et quel taux de conformité est attendu sur l’échantillon. Sans cela, vous livrez un site « à peu près » et l’acheteur refuse la réception.

Côté privé « volontaire », définissez un socle productif : parcours critiques utilisables au clavier, contrastes corrects, formulaires compréhensibles, médias avec alternatives. Documentez ce socle dans le devis. Vous évitez le piège du « conforme RGAA » promis sans budget d’audit, tout en livrant une valeur réelle.

Dans tous les cas, différenciez trois niveaux de discours : (1) bonnes pratiques intégrées au build, (2) audit RGAA sur échantillon avec rapport, (3) affichage d’une déclaration et suivi pluriannuel. Chaque niveau a un coût. Mélanger les trois dans une phrase commerciale crée des litiges.

Avant les contrastes et les ARIA exotiques, la structure compte. Un titre h1 unique par page, une hiérarchie de titres cohérente, des listes réelles, des boutons qui sont des boutons et des liens qui sont des liens : c’est le socle que les technologies d’assistance exploitent.

Sur un projet Next.js, la tentation du « tout div » est réelle. Résistez. Utilisez les landmarks (header, nav, main, footer), des libellés de navigation clairs, et des zones de contenu distinctes. Un skip link (« Aller au contenu ») en tête de page accélère la navigation clavier.

Les tableaux de données doivent avoir des en-têtes ; les tableaux de mise en page sont à éviter. Les iframes ont un title. Les langues de page et de passages sont déclarées. Ces détails paraissent mineurs jusqu’à la première recette lecteur d’écran.

Du côté Figma, anticipez la sémantique : nommez les styles de titre, distinguez bouton et lien dans les specs, documentez l’ordre de lecture prévu. Le handoff Dev Mode doit porter ces intentions, sinon le développeur reconstruit une interface visuelle sans structure.

Mesurez la structure tôt : inspection DOM, outline des titres, validation HTML. Corriger une arborescence de titres en fin de projet coûte plus cher que de la figer dans les templates de base.

Tout parcours critique doit être réalisable au clavier seul : Tab, Shift+Tab, Entrée, Espace, Échap pour les modales. Si un menu, un carrousel ou une lightbox piège le focus, le site est bloquant pour une partie des utilisateurs — et souvent non conforme aux critères d’interaction du RGAA / WCAG.

Le focus visible n’est pas optionnel. Supprimer outline sans alternative est une erreur classique de design « clean ». Définissez un état focus cohérent dans Figma et implémentez-le en CSS (:focus-visible). Testez sur fond clair et foncé.

Les composants riches (onglets, accordéons, menus) demandent un comportement clavier prévisible. S’appuyer sur des primitives accessibles (Radix, patterns WAI-ARIA) réduit le risque, mais ne dispense pas de tester. Un composant « accessible sur la doc » peut être cassé par un override de styles ou un portail mal géré.

Sur mobile, pensez zones de touche et gestes. L’accessibilité n’est pas que desktop. Vérifiez aussi prefers-reduced-motion : les animations GSAP ou CSS ne doivent pas empêcher la compréhension ni déclencher de malaise. Proposez une version réduite quand l’utilisateur le demande.

Intégrez la navigation clavier dans la recette métier, pas seulement dans un audit expert. Un PO qui parcourt le tunnel « Tab jusqu’au paiement » détecte vite les pièges que l’équipe visuelle ne voit pas.

Les contrastes insuffisants restent l’un des défauts les plus fréquents en livraison. Visez au minimum les seuils WCAG AA pour le texte et les composants d’interface critiques. Vérifiez aussi les états : placeholder, disabled, erreur, lien sur image.

Dans Figma, auditez les paires de couleurs avant handoff. Corrigez le design system, pas page par page. Un token « texte secondaire » trop clair se répète partout en production. Les plugins de contraste aident ; la validation humaine reste nécessaire sur les cas limites (texte sur photo, dégradés).

La typographie joue : taille minimale confortable, interlignage, largeur de ligne. L’accessibilité cognitive et visuelle se joue aussi dans la lisibilité éditoriale. Évitez les blocs de texte justifiés trop denses et les contrastes décoratifs sur contenus informatifs.

Ne vous reposez pas sur la couleur seule pour transmettre une information (erreur formulaire, statut, graphique). Ajoutez texte, icône ou motif. C’est un critère WCAG classique et un gain UX pour tout le monde.

Documentez les exceptions (logo marque, média artistique) plutôt que de les ignorer. Une exception assumée dans la déclaration ou le rapport d’audit vaut mieux qu’un silence gênant en recette.

L’accessibilité n’est pas qu’un sujet développeur. Une image informative sans alternative textuelle, une vidéo sans sous-titres, un PDF scanné illisible : ce sont des non-conformités de contenu. Prévoir un workflow éditorial (qui écrit l’alt, qui valide) fait partie du livrable PME.

Les formulaires concentrent les échecs : labels absents, erreurs non reliées aux champs, Captcha hostiles, messages uniquement en couleur. Exigez des labels visibles, des instructions claires, des erreurs textuelles et une validation compréhensible au clavier comme à la souris.

Pour les documents téléchargeables, préférez des formats accessibles ou des pages HTML équivalentes. Un catalogue PDF image unique est un mur pour beaucoup d’usagers — et un mauvais signal en marché public.

Les contenus dynamiques (toasts, live regions) doivent être annoncés sans agressivité. Évitez les carrousels autoplay non contrôlables. Si vous animez, donnez le contrôle : pause, arrêt, équivalent statique.

Formez brièvement les éditeurs. Une heure de règles (alt, titres, liens explicites « en savoir plus » contextualisés) évite de dégrader un socle technique correct en trois mois de publication.

Construisez une recette en trois couches. Couche 1 : automatismes (axe-core, Lighthouse accessibility, contrast checkers) pour attraper le bruit de fond. Couche 2 : parcours clavier manuels sur l’échantillon critique. Couche 3 : smoke test lecteur d’écran (NVDA ou VoiceOver) sur accueil, navigation et formulaire.

Choisissez un échantillon représentatif : accueil, une page modèle, contact, une page contenu riche, une page légale, le tunnel clé. C’est l’esprit de la méthode RGAA : on n’audite pas « tout Internet », on audite un périmètre défini.

Tracez les anomalies avec criticité (bloquant, majeur, mineur) et responsable (design, front, contenu). Sans responsable, le backlog d’accessibilité devient un tiroir. Planifiez des correctifs dans le sprint, pas « un jour ».

Si vous visez une déclaration publique, budgétez un audit selon la méthode RGAA par un profil compétent. L’équipe projet peut préparer le terrain ; l’audit formel a une valeur de preuve et de priorisation. Ne promettez pas « conforme » dans un devis sans cette ligne.

Après mise en production, prévoyez une maintenance : nouvelles pages, nouveaux composants, campagnes marketing qui cassent les contrastes. L’accessibilité est un continuum, pas un tampon de recette unique.

Promettre « site 100 % RGAA » sans audit ni budget correctifs. Reformulez en « socle AA sur parcours critiques + audit optionnel ».

Corriger uniquement ce que l’outil automatique signale. Les pièges clavier et les libellés ambigus passent sous le radar.

Traiter l’accessibilité en fin de projet. Les tokens couleur et les composants de base doivent être justes dès le design system.

Oublier les contenus et les PDF. Le front peut être propre et le site rester inutilisable.

Copier une déclaration d’accessibilité d’un autre site. C’est trompeur et risqué. Une déclaration décrit votre échantillon, votre date d’audit et vos écarts réels.

Négliger le consentement et les cookies overlies qui piègent le clavier à l’arrivée. Le premier écran compte autant que le footer.

Le RGAA est un référentiel de méthode, pas un badge automatique. Situez d’abord votre obligation (public, secteur réglementé, exigence contractuelle) avant de promettre une conformité.

Pour une PME, un socle réaliste porte sur structure, clavier, contraste, formulaires et contenus — priorisé sur les parcours critiques.

Figma et Next.js sont des leviers : tokens et composants justes en amont, sémantique et focus en intégration.

La recette combine automatismes, clavier et smoke test lecteur d’écran. L’audit RGAA formel est un livrable distinct.

Marché public et déclaration publique exigent documentation et plan de progrès, pas seulement de bonnes intentions.

L’accessibilité se maintient après la mise en production : éditorial, campagnes et nouveaux composants inclus.