Design accessible : UI kit, composants et règles RGAA

Résumer le contenu avec l’IA :

Concevoir l’accessibilité avant de corriger les erreurs

Dans un projet web, l’accessibilité numérique est encore trop souvent traitée en fin de parcours. Une maquette est validée, les développements avancent, les contenus sont intégrés, puis l’audit RGAA révèle une série de non-conformités : contrastes insuffisants, focus invisible, formulaires difficiles à comprendre, composants interactifs inutilisables au clavier, liens peu explicites ou messages d’erreur incomplets.

Ce scénario est fréquent dans les collectivités et les destinations touristiques. Il ne vient pas toujours d’un manque de bonne volonté. Il vient surtout d’un problème de méthode. L’accessibilité n’a pas été traduite en livrables concrets dès la conception.

Un design accessible ne se limite pas à des couleurs bien contrastées ou à une interface sobre. Il repose sur un ensemble de livrables vérifiables : un UI kit documenté, des composants accessibles, des règles d’usage, des états d’interaction, des annotations pour l’intégration et une checklist de recette.

Pour une mairie, une intercommunalité, un office de tourisme ou une agence d’attractivité, ces livrables ont un intérêt très opérationnel. Ils permettent de mieux cadrer les prestataires, de réduire les corrections tardives, de sécuriser les parcours essentiels et de maintenir la qualité dans le temps. Autrement dit, ils transforment l’accessibilité en méthode de pilotage.

Pourquoi le design accessible doit être cadré dès les livrables ?

Le design influence directement la capacité d’un utilisateur à comprendre et utiliser un service numérique. Il détermine la hiérarchie visuelle, les contrastes, la taille des textes, les espacements, l’apparence des boutons, les états d’erreur, la visibilité du focus, la compréhension des formulaires et la lisibilité globale d’une page.

Sur un site de collectivité, ces choix conditionnent l’accès aux démarches en ligne, aux horaires d’ouverture, aux actualités, aux formulaires de contact ou aux informations pratiques. Sur un site touristique, ils conditionnent l’accès aux hébergements, aux activités, aux événements, aux itinéraires, aux informations d’accessibilité physique ou aux outils de réservation.

Lorsqu’un design n’est pas suffisamment documenté, chaque métier interprète les règles à sa manière. Le designer livre une intention visuelle. L’intégrateur prend des décisions techniques. Le développeur adapte les composants. Le contributeur ajoute des contenus sans toujours connaître les règles de lisibilité. Résultat : la cohérence initiale se dégrade progressivement.

C’est précisément pour éviter cette perte en ligne que les livrables sont essentiels. Ils ne servent pas seulement à « faire joli » ou à harmoniser l’interface. Ils permettent de rendre explicites les règles que chacun devra respecter pendant la conception, l’intégration, la contribution et la maintenance.

Un audit d’accessibilité en fin de projet reste utile, mais il intervient trop tard pour corriger facilement certains choix structurants. À l’inverse, une revue des livrables de design permet de détecter les problèmes avant qu’ils ne soient intégrés dans le code ou reproduits sur des dizaines de pages.

Ce qu’un livrable de design accessible doit permettre de vérifier

Un livrable de design accessible doit permettre de vérifier trois dimensions : la lisibilité de l’interface, l’utilisabilité des composants et la cohérence des règles dans le temps.

La lisibilité concerne tout ce qui aide l’utilisateur à comprendre rapidement ce qu’il voit. Les textes doivent être suffisamment contrastés, les titres clairement hiérarchisés, les contenus bien espacés et les blocs visuels faciles à distinguer. Cette lisibilité bénéficie à tous les publics : personnes malvoyantes, seniors, utilisateurs en mobilité, agents consultant le site sur un écran ancien ou touristes cherchant une information rapidement depuis un smartphone.

L’utilisabilité concerne la capacité à interagir avec l’interface. Un bouton doit être identifiable comme un bouton. Un champ de formulaire doit avoir un libellé compréhensible. Une erreur doit expliquer ce qui ne va pas et comment corriger. Une modale ne doit pas piéger l’utilisateur. Un menu doit pouvoir être parcouru sans souris. Une carte touristique doit proposer une alternative si l’information visuelle n’est pas accessible.

La cohérence, enfin, concerne la capacité à maintenir ces règles dans le temps. Un site accessible le jour de sa mise en ligne peut rapidement perdre en qualité si les composants ne sont pas documentés, si les contributeurs n’ont pas de règles éditoriales ou si chaque nouvelle page est conçue comme un cas particulier.

Le bon livrable n’est donc pas seulement une maquette validée. C’est une documentation de conception. Elle doit permettre de répondre à une question simple : « Est-ce que les choix graphiques et fonctionnels peuvent être compris, développés, testés et maintenus correctement ? ».

Livrable n°1 : un UI kit accessible, pas seulement esthétique

Le UI kit est souvent perçu comme une bibliothèque graphique. Il rassemble les couleurs, les typographies, les boutons, les champs, les pictogrammes et les éléments récurrents de l’interface. Dans une logique d’accessibilité, il doit aller plus loin. Il doit documenter les conditions d’usage de chaque élément.

Un UI kit accessible commence par une palette de couleurs vérifiée. Il ne suffit pas de choisir des couleurs « institutionnelles » ou « territoriales ». Il faut tester leurs combinaisons réelles : texte sur fond clair, texte sur fond coloré, boutons primaires, boutons secondaires, alertes, liens, étiquettes, badges, messages d’erreur, pictogrammes et bordures de champs.

La difficulté vient rarement de la couleur principale en elle-même. Elle vient plutôt des variantes : gris clair utilisé pour un texte secondaire, bleu trop pâle pour un lien, rouge d’erreur insuffisamment lisible, état désactivé presque invisible, pictogramme fonctionnel trop discret. Le UI kit doit donc préciser quelles associations sont autorisées et lesquelles sont interdites.

La typographie doit également être cadrée. Le livrable doit définir les tailles de texte, les interlignages, les graisses, les styles de titres et les espacements. Un site peut être visuellement élégant mais difficile à lire si les textes sont trop petits, si les lignes sont trop longues ou si les niveaux de titres ne sont pas suffisamment différenciés.

Pour une destination touristique, cette question est importante. Les pages sont souvent riches en visuels, en blocs éditoriaux, en offres, en cartes et en informations pratiques. Sans règles strictes de hiérarchie et de respiration, l’interface devient vite dense. Pour une collectivité, le risque est différent : l’accumulation d’informations administratives peut rendre les pages difficiles à parcourir si les niveaux de lecture ne sont pas bien organisés.

Le UI kit doit aussi préciser les règles applicables aux pictogrammes et illustrations. Une icône décorative n’a pas le même rôle qu’une icône fonctionnelle. Une illustration d’ambiance n’a pas le même besoin d’alternative qu’un schéma explicatif. Un pictogramme indiquant un service accessible, un parking, une gare ou un équipement ne doit pas être le seul moyen de comprendre l’information.

Un UI kit accessible n’impose pas un design pauvre ou uniforme. Il permet au contraire de concevoir plus vite, avec plus de cohérence et moins d’arbitrages implicites.

Livrable n°2 : des composants accessibles documentés

Les composants sont le cœur du design accessible. Un composant est un élément réutilisable de l’interface : bouton, champ de formulaire, menu, accordéon, onglet, alerte, modale, carte, pagination, moteur de recherche, filtre ou bloc de résultat.

Dans un projet web, les non-conformités les plus pénalisantes viennent souvent de composants mal conçus. Un formulaire de contact mal documenté peut bloquer une demande citoyenne. Un filtre inaccessible peut empêcher un visiteur de trouver un hébergement. Une carte interactive sans alternative peut rendre invisible une partie de l’offre touristique. Une modale mal gérée peut piéger la navigation clavier.

Chaque composant devrait être documenté selon plusieurs dimensions. Il faut préciser son usage, ses variantes, ses états, son comportement responsive, ses règles de contenu et les points d’attention pour l’intégration.

Les états sont particulièrement importants. Un bouton ne se limite pas à son apparence « normale ». Il doit aussi être prévu au survol, au focus, à l’activation, au chargement et dans un état désactivé. Un champ de formulaire doit prévoir l’état par défaut, l’état rempli, l’état en erreur, l’état validé, l’aide à la saisie et le message d’erreur. Un accordéon doit préciser son état ouvert, fermé, le comportement de son titre et la façon dont il est annoncé aux technologies d’assistance.

Le focus visible mérite une attention spécifique. Pour les personnes qui naviguent au clavier, il indique l’endroit où elles se trouvent dans la page. S’il est absent, trop discret ou masqué, la navigation devient confuse. Ce point ne doit pas être laissé à l’appréciation de l’intégrateur. Il doit être prévu dans les maquettes et documenté dans la bibliothèque de composants.

Pour les collectivités, les composants prioritaires sont généralement les formulaires, les menus, les moteurs de recherche, les démarches en ligne, les alertes, les tableaux, les annuaires et les blocs de contact. Pour les destinations touristiques, il faut ajouter les fiches d’offres, les cartes, les filtres, les calendriers, les modules de réservation, les galeries médias et les listes de résultats.

Les composants tiers doivent faire l’objet d’une vigilance particulière. Un moteur de réservation, une carte interactive, un module de billetterie ou un chatbot peut introduire des obstacles importants. Le fait qu’un outil soit commercial, répandu ou « clé en main » ne garantit pas son accessibilité. Il faut donc prévoir son évaluation dès la conception et non après son intégration.

Livrable n°3 : des maquettes annotées pour faciliter l’intégration

Une maquette visuelle montre l’apparence attendue d’une page. Une maquette annotée explique comment cette page doit fonctionner et comment elle doit être comprise.

Dans une démarche d’accessibilité, les annotations sont essentielles. Elles permettent de transmettre des informations qui ne sont pas visibles dans une image statique. Elles peuvent préciser l’ordre de lecture, les niveaux de titres, les libellés de champs, les messages d’erreur, les textes alternatifs attendus, les comportements au clavier, les éléments dynamiques ou les zones qui doivent être annoncées aux technologies d’assistance.

Prenons l’exemple d’une page d’événement touristique. La maquette peut présenter une photo, un titre, une date, un lieu, une carte, un bouton de réservation et des informations pratiques. Mais elle ne dit pas nécessairement comment l’image doit être décrite, si la date doit être structurée, comment la carte est remplacée par une alternative textuelle, quel est l’intitulé exact du bouton ou comment les informations d’accessibilité du lieu sont présentées.

Même logique pour une page de démarche municipale. Une maquette peut afficher un formulaire clair visuellement, mais ne pas indiquer comment les champs sont libellés, comment les erreurs sont associées aux champs, comment les étapes sont annoncées ou comment l’utilisateur revient à une erreur après validation.

L’annotation évite ces ambiguïtés. Elle crée un langage commun entre le designer, l’intégrateur, le développeur, le chef de projet, le contributeur et l’éventuel auditeur. Elle permet aussi au commanditaire de mieux contrôler la qualité des livrables avant de valider une phase de conception.

Dans un projet contraint, l’annotation ne doit pas nécessairement être excessive. Il n’est pas utile de transformer chaque maquette en document juridique. En revanche, les parcours clés doivent être documentés avec précision : page d’accueil, navigation, recherche, formulaire, fiche détaillée, carte, réservation, démarche en ligne et page de contenu éditorial.

Livrable n°4 : des règles éditoriales accessibles

Le design accessible ne dépend pas uniquement des designers. Les contenus jouent un rôle déterminant. Un bouton mal libellé, un lien vague, un titre peu descriptif ou un message d’erreur incomplet peut dégrader fortement l’expérience utilisateur, même si le composant est techniquement correct.

Les règles éditoriales doivent donc faire partie des livrables. Elles expliquent comment rédiger les titres, les liens, les boutons, les alternatives d’images, les messages d’erreur, les aides à la saisie et les contenus téléchargeables.

Sur un site institutionnel, un lien intitulé « Cliquez ici » ou « En savoir plus » n’est pas assez explicite lorsqu’il est sorti de son contexte. Il vaut mieux écrire « Consulter les horaires de la mairie », « Télécharger le formulaire de demande de subvention » ou « Voir les démarches liées au stationnement ». Ces libellés améliorent l’accessibilité, mais aussi le référencement naturel et la compréhension globale de la page.

Sur un site touristique, les images ont souvent une forte valeur éditoriale. Une photo d’ambiance peut être décorative, mais une image montrant l’accès à un site, le plan d’un parcours, une chambre adaptée ou un équipement spécifique porte une information utile. Les règles doivent aider les contributeurs à distinguer ces cas.

Les messages d’erreur méritent aussi une règle claire. Un message comme « Erreur » ne suffit pas. L’utilisateur doit comprendre quel champ pose problème, pourquoi la saisie est refusée et comment corriger. Par exemple : « Le champ téléphone doit contenir 10 chiffres » est plus utile que « Format invalide ».

Ces règles éditoriales ont une autre vertu : elles maintiennent l’accessibilité après la mise en ligne. Beaucoup de sites sont correctement conçus au départ, puis se dégradent lorsque de nouveaux contenus sont ajoutés sans cadre. Une documentation simple, intégrée aux pratiques de contribution, limite ce risque.

Livrable n°5 : une checklist de recette design accessible

Avant de passer de la maquette au développement, il est utile de réaliser une recette design. Cette étape consiste à vérifier que les principaux choix de conception respectent les exigences attendues.

La checklist ne remplace pas un audit RGAA, mais elle permet de détecter tôt les problèmes les plus fréquents. Elle doit être simple, utilisable par un chef de projet et suffisamment précise pour objectiver la validation.

Voici les points prioritaires à intégrer :

Les contrastes sont vérifiés pour les textes, liens, boutons, pictogrammes fonctionnels et bordures utiles.
Les états de focus sont visibles et prévus pour tous les éléments interactifs.
Les formulaires disposent de libellés, aides, erreurs et validations compréhensibles.
Les composants principaux sont documentés avec leurs variantes et comportements.
Les titres, liens et boutons utilisent des intitulés explicites.
Les maquettes mobile sont fournies pour les parcours clés.
Les cartes, médias et composants visuels disposent d’alternatives adaptées.
Les composants tiers sont identifiés et soumis à vérification.
Les règles éditoriales sont disponibles pour les contributeurs.
Les critères de recette sont intégrés au planning projet.

Cette checklist a un rôle de garde-fou. Elle évite de valider une direction artistique sans avoir vérifié ses conséquences concrètes sur l’usage. Elle aide aussi à dialoguer avec une agence ou un prestataire sans se limiter à une appréciation subjective du design.

Comment intégrer ces livrables dans un cahier des charges ?

Dans un cahier des charges, la mention “le site devra être accessible” est insuffisante. Elle exprime une intention, mais elle ne donne pas de livrables vérifiables. Pour être utile, l’exigence doit être traduite en attendus précis.

Il est préférable de demander explicitement un UI kit accessible, une bibliothèque de composants documentés, des maquettes annotées, des règles éditoriales, une checklist de recette et une phase de revue accessibilité en conception.

Le cahier des charges peut aussi préciser que les composants doivent couvrir les états interactifs, les erreurs, les comportements responsives et les usages clavier. Il peut demander que les composants tiers soient identifiés et évalués avant validation. Il peut enfin prévoir une passation aux contributeurs, afin que les règles de contenu soient comprises après la mise en ligne.

Cette précision protège le commanditaire. Elle permet de comparer les offres, de questionner les méthodes des prestataires et d’éviter une accessibilité “déclarative”. Une agence qui affirme produire des interfaces accessibles doit pouvoir expliquer comment elle documente ses composants, comment elle vérifie les contrastes, comment elle traite les formulaires et comment elle transmet les règles aux équipes techniques.

Pour une collectivité ou une destination touristique, cette exigence est aussi un levier budgétaire. Plus les attentes sont claires au départ, moins les corrections tardives sont nombreuses. L’accessibilité devient alors une condition de qualité intégrée au projet, et non une ligne de reprise ajoutée en urgence.

Les erreurs fréquentes à éviter

La première erreur consiste à confondre accessibilité et sobriété visuelle. Une interface épurée n’est pas automatiquement accessible. Un design minimaliste peut produire des contrastes trop faibles, des boutons peu identifiables ou des états d’interaction invisibles.

La deuxième erreur consiste à limiter l’accessibilité aux contrastes. Les contrastes sont essentiels, mais ils ne suffisent pas. Un site peut avoir des couleurs conformes et rester difficile à utiliser si ses formulaires sont mal conçus, si ses liens sont vagues ou si ses composants ne fonctionnent pas au clavier.

La troisième erreur consiste à oublier les états. Beaucoup de maquettes montrent uniquement l’apparence par défaut des composants. Or, les états d’erreur, de focus, de chargement ou de désactivation sont souvent ceux qui posent le plus de problèmes.

La quatrième erreur consiste à reporter la responsabilité sur le développement. Les développeurs ont un rôle majeur, mais ils ne peuvent pas corriger seuls des choix de conception mal cadrés. Si la hiérarchie, les contenus, les variantes et les comportements ne sont pas définis, l’intégration devient une succession d’arbitrages implicites.

La cinquième erreur consiste à négliger la contribution. Un design accessible qui n’est pas accompagné de règles éditoriales risque de se dégrader rapidement. Les contributeurs doivent savoir rédiger un lien, choisir une image, structurer une page et signaler une information importante sans s’appuyer uniquement sur la couleur.

Cas d’usage : collectivité et destination touristique

Pour une collectivité, les livrables de design accessible doivent sécuriser les services essentiels. Le site municipal ou intercommunal n’est pas seulement une vitrine. Il donne accès à des démarches, des formulaires, des alertes, des informations pratiques et des documents. Une personne doit pouvoir comprendre comment contacter un service, demander une aide, consulter un arrêté, trouver un équipement ou connaître les horaires d’accueil.

Dans ce contexte, les composants prioritaires sont les formulaires, les menus, les moteurs de recherche, les pages de démarches, les alertes, les tableaux et les blocs de contact. Le UI kit doit garantir une lisibilité forte, y compris pour des contenus administratifs parfois complexes. Les règles éditoriales doivent aider à simplifier les intitulés et à éviter le jargon interne.

Pour une destination touristique, l’enjeu est différent mais tout aussi sensible. Le site doit inspirer, informer et convertir, sans exclure les personnes qui ont besoin d’une interface claire, compatible avec les technologies d’assistance ou utilisable dans des conditions dégradées. Un visiteur peut consulter le site depuis un mobile, en extérieur, avec une connexion instable, une fatigue visuelle ou un handicap temporaire ou permanent.

Les composants prioritaires sont alors les fiches d’offres, les filtres, les cartes, les calendriers, les médias, les formulaires de réservation et les informations pratiques. Les photos doivent être utilisées avec soin, les informations d’accessibilité physique doivent être lisibles, les cartes doivent être accompagnées d’alternatives et les boutons d’action doivent être explicites.

Dans les deux cas, l’accessibilité ne nuit pas à l’attractivité. Elle renforce la clarté, la confiance et l’efficacité du parcours.

Synthèse : les livrables à demander avant de valider une maquette

Avant de valider une phase de design, une collectivité ou une destination touristique devrait disposer d’un socle documentaire clair.

Le UI kit accessible fixe les règles visuelles : couleurs, contrastes, typographies, espacements, pictogrammes et usages autorisés. La bibliothèque de composants documente les éléments interactifs, leurs variantes, leurs états et leurs comportements. Les maquettes annotées facilitent le passage de relais vers l’intégration et le développement. Les règles éditoriales aident les contributeurs à maintenir la qualité après la mise en ligne. La checklist de recette permet d’objectiver la validation avant d’engager les développements. Enfin, la documentation de gouvernance précise qui met à jour les règles et comment les évolutions seront contrôlées.

Ces livrables ne doivent pas être vus comme une surcharge documentaire. Ils sont une assurance qualité. Ils permettent de réduire les malentendus, d’éviter les corrections tardives et de rendre l’accessibilité plus concrète pour tous les acteurs du projet.

Conclusion : un design accessible se pilote par ses livrables

Un design accessible n’est pas une promesse esthétique. C’est une méthode de conception documentée, vérifiable et maintenable. Sans UI kit accessible, sans composants documentés, sans maquettes annotées et sans règles éditoriales, l’accessibilité repose trop souvent sur des interprétations individuelles.

Pour les collectivités et les destinations touristiques, l’enjeu est clair : proposer des services numériques utilisables par tous, tout en maîtrisant les coûts et les délais. Les livrables de design accessible permettent précisément d’agir plus tôt, avec plus de méthode et moins de reprises.

Ils donnent aussi au commanditaire un rôle plus actif. Plutôt que d’attendre un audit final pour découvrir les non-conformités, il devient possible de questionner les choix, de vérifier les composants, de cadrer les règles et de sécuriser les parcours importants dès la conception.

L’accessibilité numérique devient alors moins abstraite. Elle se voit dans les maquettes, se lit dans les règles, se teste dans les composants et se maintient dans la durée.

FAQ

Qu’est-ce qu’un design accessible ?

Un design accessible est une conception d’interface qui permet à tous les utilisateurs, y compris les personnes en situation de handicap, de comprendre, parcourir et utiliser un service numérique. Il repose sur des choix vérifiables : contrastes suffisants, textes lisibles, composants compréhensibles, focus visible, navigation clavier, formulaires clairs et contenus bien structurés.

Quels livrables demander pour garantir un design accessible ?

Les livrables prioritaires sont un UI kit accessible, une bibliothèque de composants documentés, des maquettes annotées, des règles éditoriales, une checklist de recette et une documentation de gouvernance. Ces éléments permettent de vérifier l’accessibilité avant l’intégration technique et de maintenir la qualité après la mise en ligne.

Un UI kit suffit-il pour rendre un site accessible ?

Non. Un UI kit est utile, mais il ne suffit pas. Il doit être complété par des composants documentés, des règles d’usage, des comportements interactifs, des annotations fonctionnelles et des consignes éditoriales. L’accessibilité dépend aussi du développement, de la contribution, des contenus et des composants tiers.

Pourquoi faut-il documenter les composants ?

Les composants sont réutilisés sur de nombreuses pages. S’ils sont mal conçus, la même erreur se répète partout. Les documenter permet de préciser leurs états, leurs variantes, leur comportement au clavier, leurs messages d’erreur et leurs règles de contenu. C’est un levier direct de qualité et de conformité.

Quels composants sont prioritaires pour une collectivité ?

Les composants prioritaires sont les menus, formulaires, moteurs de recherche, démarches en ligne, alertes, tableaux, annuaires, accordéons et blocs de contact. Ce sont eux qui conditionnent l’accès aux services publics numériques et aux informations essentielles pour les citoyens.

Quels composants sont prioritaires pour une destination touristique ?

Les composants prioritaires sont les fiches d’offres, cartes interactives, filtres, calendriers, galeries médias, formulaires de réservation, moteurs de recherche et modules de billetterie. Ils doivent rester utilisables sans souris, compréhensibles par tous et accompagnés d’alternatives lorsque l’information est visuelle.

Pourquoi le focus visible est-il important ?

Le focus visible indique la position de l’utilisateur lorsqu’il navigue au clavier. Sans indicateur clair, il devient difficile de savoir quel lien, bouton ou champ est actif. Le focus doit donc être prévu dès la conception graphique, documenté dans les composants et vérifié pendant la recette.

Les contrastes suffisent-ils à garantir l’accessibilité ?

Non. Les contrastes sont indispensables, mais ils ne couvrent qu’une partie du sujet. Il faut aussi traiter la structure des contenus, les formulaires, les messages d’erreur, la navigation clavier, les intitulés de liens, les alternatives aux images et le comportement des composants interactifs.

Comment intégrer le design accessible dans un cahier des charges ?

Il faut demander des livrables vérifiables plutôt qu’une simple intention générale. Le cahier des charges doit mentionner le UI kit accessible, les composants documentés, les maquettes annotées, la recette design, les règles éditoriales et l’évaluation des composants tiers. Ces éléments facilitent le contrôle de la qualité.

Un design accessible peut-il rester attractif ?

Oui. L’accessibilité ne s’oppose pas à l’attractivité. Elle impose surtout de concevoir des interfaces plus lisibles, cohérentes et robustes. Pour une collectivité ou une destination touristique, elle améliore la qualité de service, renforce la confiance et facilite l’accès aux informations importantes.

Design accessible : livrables attendus UI kit, composants, règles