Le vrai chantier derrière l’accessibilité Web

Le mot « accessibilité » revient sur la table dans de plus en plus de projets. Pas forcément en premier, mais il est là ! Glissé dans une to-do, brandi par un·e PO qui revient d’une conférence, ou ajouté comme critère dans un appel d’offres. Ce n’est pas (encore) le sujet prioritaire. Mais ce n’est plus un sujet qu’on peut enterrer sous le tapis.

Et c’est une bonne nouvelle 👌

Mais c’est aussi un sujet qu’on va devoir mieux manier. Pas juste cocher une case RGAA. Pas juste ajouter un role="button" au mauvais endroit. Et sûrement pas faire semblant que la performance suffit à couvrir le besoin !

Section intitulée performance-une-base-necessaire-pas-une-fin-en-soiPerformance : une base nécessaire, pas une fin en soi

Chez JoliCode, la performance frontend est une discipline que nous essayons de bâtir avec rigueur. Nos audits s’appuient systématiquement sur les Core Web Vitals (LCP : Largest Contentful Paint, INP : Interaction to Next Paint, CLS : Cumulative Layout Shift) pour mesurer la performance perçue, mais aussi pour détecter des blocages réels dans le parcours utilisateur. Nous traquons par exemple les décalages de mise en page, les scripts trop lourds, les images mal optimisées, qui nuisent autant à l’expérience qu’au référencement naturel ou à l’accessibilité.

La performance perçue est souvent la première porte d’entrée vers l’accessibilité. Un site rapide, stable et fluide, c’est un site plus accessible pour tous, notamment pour ceux qui naviguent sur des appareils modestes ou en environnement contraint. Cela dit, il est impératif de ne pas confondre vitesse et accessibilité : un site performant n’est pas nécessairement accessible 👀

Section intitulée notre-stack-nos-conventionsNotre stack, nos conventions

Utiliser des outils modernes ne suffit pas à garantir une bonne accessibilité. Nous avons fait le choix de stack et de conventions qui rendent plus simples, plus robustes et plus naturelles les bonnes pratiques d’accessibilité, dès la conception. Ce n’est pas magique. Ce sont des choix d’équipe, documentés, confrontés à la réalité des projets.

Nous aimons utiliser :

• Symfony UX, avec ses composants Twig réutilisables, pour structurer nos interfaces avec une sémantique claire, factorisée et testable.
• Stimulus, framework JavaScript minimaliste, pour créer des interactions accessibles et lisibles sans trop de surcouche ni de complexité inutile.
• Live Components, pour injecter de l’interactivité AJAX tout en gardant le contrôle sur le rendu HTML et les états.
• Une approche hybride CSS, mêlant classes utilitaires Tailwind et classes sémantiques, pour trouver un équilibre entre lisibilité et maintenabilité.
• Des outils de cohérence (pnpm, eslint, stylelint, Prettier) configurés dès notre starter front-end (une base de code minimaliste qui embarque déjà les outils, configurations et conventions que nous avons choisis) pour diffuser les bonnes pratiques sur chaque projet.
• Storybook, qui nous permet de documenter nos composants, de tester leur accessibilité de manière isolée, et de partager un design system lisible et surtout évolutif sur le long terme.

Cette architecture technique nous permet d’intégrer les bonnes pratiques d’accessibilité dès le début, et de maintenir un socle propre et durable.

Notre approche repose aussi sur un référentiel qualité interne, que nous faisons évoluer projet après projet. Ce référentiel n’est pas figé : il grandit à mesure que l’on affine nos pratiques d’intégration, que l’on croise les retours des équipes, les erreurs récurrentes, et les cas limites qu’on rencontre sur le terrain.

Sur l’accessibilité en particulier, cette « base » s’étoffe : navigation clavier, composants JavaScript accessibles, attributs alt bien gérés côté back-office, etc. À chaque projet, ces critères sont systématiquement vérifiés. C’est notre manière de transformer l’expérience acquise en exigence partagée. On s’appuie aussi sur des standards qualité comme Opquast et on les confronte à la réalité de nos projets grâce à cet outil qualité.

Section intitulée l-accessibilite-ce-n-est-pas-un-fix-en-fin-de-projetL’accessibilité, ce n’est pas un « fix » en fin de projet

L’accessibilité est un choix de conception qui doit irriguer chaque étape, du design à la production. Cela impose de repenser la manière d’écrire du HTML, de designer les interactions, de construire les parcours utilisateur. Ce sont des habitudes qu’on n’acquiert pas sans effort.

Nous intégrons ces réflexions dans notre quotidien, en gardant en tête que 80 % des handicaps sont invisibles : fatigue, troubles cognitifs, douleur, surcharge mentale, ou simple contexte d’usage dégradé. Une vision large, pragmatique, et non limitée à l’évidence visuelle ou motrice.

Section intitulée on-aime-etre-secoue-dans-le-bon-sensOn aime être secoué ! (dans le bon sens)

On se souvient, même si cela commence à dater, de la conférence marquante de Delphine Malassingne qui nous a rappelé que « c’est nous, les développeurs, qui créons l’inaccessibilité », souvent sans le vouloir, simplement parce que nous ne la vivons pas au quotidien.

Autre conférence : celle de la MAIF sur le meilleur composant pour saisir une date. Spoiler : le datepicker n’est pas toujours la meilleure idée en 2025. Et l’accessibilité, ce n’est pas trouver LA solution parfaite, mais la moins pire pour le plus de monde possible.

Section intitulée on-ne-fait-pas-toutOn ne fait pas tout !

Nous ne sommes pas une structure spécialisée 100% accessibilité mais une équipe d’ingénieurs qui construisent des socles solides, professionnels et durables, qui intègrent performance et accessibilité dans la stack. Nous ne faisons pas de remédiation par exemple, ce n’est simplement pas notre métier.

Par contre, notre équipe est capable :

• De poser un socle solide, joli, documenté,
• De construire des interfaces qui respectent les usages réels,
• De vous dire quand un composant est une impasse, et de le remplacer par quelque chose de mieux.

Et si vous nous laissez faire un audit frontend, vous verrez que la perf et l’accessibilité sont souvent deux manières de parler de la même chose : l’attention portée aux détails, aux vrais usages, et à ce qu’on laisse derrière nous.

Section intitulée l-accessibilite-numerique-c-est-la-loi-maintenantL’accessibilité numérique : c’est la loi, maintenant

En bonus, la loi s’en est mêlée. Depuis le 28 juin 2025, la directive européenne sur l’accessibilité numérique entre vraiment en vigueur. Pour plein de secteurs (coucou le e‑commerce), ce n’est plus une option. Et pas juste sur les contrastes. Sur les usages réels.

Qui est concerné ?

• Entreprises privées, dès 10 salarié·e·s et/ou plus de 2 M€ de CA (hors micro‑entreprises) .
• Secteurs concernés : sites vitrine ou e‑commerce, applis, services de téléphonie, médias, transports, services bancaires en ligne, bornes (gares, distributeurs…), liseuses, TV, smartphone, box…

Ces acteurs « entrent dans le champ » : Il faudra prouver la conformité avec les WCAG 2.1 AA (Web Content Accessibility Guidelines, niveau AA), la norme EN 301 549 (European standard for accessibility requirements for ICT products and services) et le RGAA (Référentiel Général d’Amélioration de l’Accessibilité).

• Réaliser un audit
• Publier une déclaration d’accessibilité
• Mettre en ligne un schéma pluriannuel (et un canal pour recueillir les retours)

Section intitulée avec-nousAvec nous ?

Pas de miracle. Pas de poudre magique. Juste :

• Une équipe qui s’est déjà posé les bonnes questions,
• Des outils de dev bien câblés (starter front, linters, composants accessibles, CI/CD qui surveille la dette),
• Une vraie envie de faire mieux, sans bullshit ni checklist déconnectée du réel.

Section intitulée on-peut-intervenirOn peut intervenir

En phase de cadrage / sprint 0

• On vous accompagne dès le début pour construire une architecture front solide et accessible : sémantique claire, composants orientés usage, structure pensée pour la navigation clavier et l’injection des bonnes pratiques (WCAG, RGAA…).

En milieu de projet

• Si vous sentez que les bonnes pratiques d’accessibilité peinent à s’intégrer, on intervient pour analyser la stack frontend : performance, sémantique, fallback, qualité des composants, respect de l’accessibilité technique. Ce n’est pas un audit RGAA exhaustif, mais un focus technique précis, intégrable dans votre stack, orienté usage et faisabilité.

Avant mise en production / CI­/CD, on vérifie que :

• La CI/CD surveille les régressions
• Les composants livrés tiennent leurs promesses
• Les parcours clés sont utilisables en conditions réelles.

L’accessibilité, ce n’est pas un sujet à la mode. C’est juste ce qui aurait dû être fait depuis le début 🤷

On y va ?