Accessibilité MVP

Déclaration d’accessibilité MVP : quoi écrire sans mentir

Publié le 6 novembre 2026

Ton application fonctionne peut-être pour toi, mais certains utilisateurs restent bloqués. Voici comment documenter les contrôles réellement faits, les limites connues et une prochaine action utile.

Guide pratique · Lecture : environ 12 minutes

Pourquoi une déclaration d’accessibilité devient utile dès le MVP

Tu viens de lancer une petite application. Le formulaire fonctionne, le paiement est prêt, et tu as demandé à quelques proches de tester. Pourtant, une personne ne parvient pas à utiliser le menu au clavier. Une autre ne comprend pas le message affiché après une erreur. Le problème n'est pas seulement technique : personne ne sait où signaler ce blocage, ni quelle solution provisoire proposer.

Le 5 novembre 2026, GitHub a expliqué qu'il rend désormais les fichiers ACCESSIBILITY.md plus visibles dans les dépôts. Ces documents peuvent décrire les objectifs, les limites connues, les environnements testés et la façon de signaler un obstacle. La date correspond à la publication de l'annonce ; l'heure de mise en ligne et le début exact du déploiement ne sont pas précisés. Annonce officielle GitHub.

Pour un créateur de micro-SaaS, la leçon dépasse GitHub. Une déclaration d'accessibilité honnête n'est pas un badge de qualité. C'est une façon de dire ce que tu as réellement vérifié, ce qui reste difficile et comment contacter quelqu'un quand une tâche devient impossible.

Tu n'as pas besoin d'attendre une grosse équipe. Tu as besoin d'une méthode modeste, traçable et compréhensible. Le plus important : ne jamais écrire que ton produit est conforme simplement parce qu'un outil automatique n'a trouvé aucune erreur.

Ce qu'une déclaration peut dire, et ce qu'elle ne prouve pas

Une déclaration d'accessibilité est un document destiné aux personnes qui utilisent ton service. Elle peut présenter tes efforts, les technologies testées, les obstacles connus et un moyen de demander de l'aide. Le W3C propose un guide de rédaction et un générateur de déclaration qui permettent de structurer ces informations.

Ce document n'est pas un audit. Il ne remplace ni les tests manuels ni une évaluation menée par une personne compétente. Il ne prouve pas non plus qu'une application satisfait automatiquement toutes les obligations légales applicables.

Trois formulations à ne pas confondre

« Nous visons les WCAG 2.2 niveau AA » exprime un objectif. « Nous avons testé le parcours d'inscription au clavier sur telle version de navigateur » décrit une vérification délimitée. « Notre application est entièrement conforme » constitue une affirmation beaucoup plus forte qui exige des preuves adaptées à son périmètre.

Si tu n'as pas réalisé d'évaluation globale, indique-le clairement. Tu peux écrire : « Le service n'a pas encore fait l'objet d'une évaluation complète. Certains parcours ont été vérifiés ; d'autres restent à examiner. » Cette formulation ne te dispense pas de tes responsabilités éventuelles. Elle évite simplement de transformer une intention en résultat.

La conformité légale dépend notamment du pays, de la nature du service et de l'organisation. Pour une activité commerciale en France, vérifie les règles applicables à ton cas avec une source juridique compétente. Ne copie pas une déclaration institutionnelle en pensant qu'elle couvrira automatiquement ton produit.

La méthode ACCÈS : cinq décisions concrètes

La méthode ACCÈS est un cadre de travail éditorial proposé ici, pas un standard officiel. Elle sert à passer d'une intention vague à des actions que tu peux réellement vérifier.

A : choisis une activité plutôt qu'un écran

Une application contient souvent des dizaines de composants. Commence par une tâche complète : créer un compte, envoyer une demande, retrouver un document ou payer une facture. Le test doit aller du premier écran au résultat attendu.

Pour un service de devis, « le bouton est visible » ne suffit pas. Il faut pouvoir atteindre le formulaire, comprendre les champs, corriger une erreur et confirmer l'envoi. Si une seule étape bloque, l'ensemble du parcours peut devenir inutilisable.

Décris le scénario avec un verbe et un résultat : « Une personne peut envoyer une demande de devis sans utiliser la souris. » Cette phrase devient ton critère de test, pas une promesse générale.

C : conserve les preuves de tes contrôles

Note la date, le navigateur, l'appareil, la méthode de navigation et le résultat. Un test au clavier sur ordinateur ne démontre pas que VoiceOver fonctionne sur iPhone. Un test automatique ne démontre pas qu'un message d'erreur est compréhensible.

Un tableau suffit : scénario, environnement, résultat observé, défaut et prochaine action. Tu peux conserver des captures, mais évite d'y inclure des données personnelles. Les captures ne remplacent pas une description textuelle du problème.

Le W3C distingue dans son générateur le statut de conformité, les environnements compatibles, les limites et l'approche d'évaluation. Cette séparation t'aide à éviter une phrase trop large fondée sur quelques essais.

C : nomme les contraintes sans les maquiller

Une limite utile décrit l'effet sur une tâche. « Le menu déroulant ne peut pas être ouvert au clavier sur la page de paiement » aide davantage qu'un vague « quelques problèmes d'accessibilité subsistent ».

Ajoute une solution temporaire seulement si elle existe et fonctionne. Ne renvoie pas vers un numéro de téléphone qui n'est jamais répondu, ni vers une adresse inventée. Si aucune alternative n'est disponible, indique-le et donne une manière réelle de signaler le problème.

Classe les défauts selon leur impact : tâche impossible, tâche très difficile, gêne récurrente, amélioration secondaire. Ce classement est un outil de priorisation, pas une qualification officielle de gravité.

È : prévois un échange accessible

Une déclaration sans canal de contact est une porte avec une poignée dessinée. Prévois une adresse ou un formulaire que tu contrôles effectivement. La personne doit pouvoir décrire le problème sans fournir de diagnostic médical ni prouver un handicap.

Demande seulement les informations utiles : page ou étape, comportement observé, résultat attendu, appareil et navigateur si la personne les connaît. Les captures et enregistrements doivent rester facultatifs.

N'annonce pas « réponse sous 24 heures » si tu ne peux pas tenir cet engagement. Tu peux expliquer que les signalements seront examinés, puis fixer un délai réaliste après avoir vérifié ta capacité de traitement.

S : transforme les signalements en décisions

Attribue chaque obstacle à une personne responsable, même si cette personne est toi. Note son état : reçu, à reproduire, correction prévue, corrigé, à vérifier. Une correction n'est pas terminée quand le code est écrit, mais quand le parcours concerné a été retesté.

Conserve également les limites non résolues. Elles sont utiles aux personnes qui rencontrent le problème et aux futurs contributeurs. Supprimer une limite de la déclaration sans test de confirmation reviendrait à effacer une alarme plutôt qu'à réparer le défaut.

Cas pratique fictif : un micro-SaaS de rendez-vous

Imaginons Inès, qui prépare un petit service de prise de rendez-vous pour des réparateurs de vélos. Son MVP permet de choisir une prestation, une date et un créneau. Les données et les personnes de cet exemple sont entièrement fictives.

Inès pense avoir terminé : les boutons fonctionnent à la souris, les créneaux s'affichent et l'e-mail de confirmation part correctement. Elle demande ensuite à une personne de réaliser la même tâche sans toucher la souris.

Le calendrier s'ouvre, mais le focus clavier disparaît après le choix du mois. La personne ne peut plus atteindre les créneaux. Un deuxième essai révèle qu'un message « erreur 422 » apparaît lorsque le téléphone est laissé vide, sans expliquer ce qu'il faut faire.

Inès ne conclut pas que « l'application est inaccessible » dans son ensemble, car elle n'a pas tout testé. Elle documente deux obstacles précis et bloque la publication du parcours concerné tant que la réservation ne peut pas être effectuée correctement.

Elle corrige d'abord la navigation au clavier, puis remplace le message technique par une indication compréhensible. Elle teste à nouveau le parcours sur les environnements réellement disponibles. Elle note les résultats, y compris les essais qui restent à faire sur lecteur d'écran.

Sa déclaration provisoire explique que la réservation au clavier a été testée dans un navigateur identifié, que l'application n'a pas fait l'objet d'un audit complet et qu'un canal de signalement existe. Elle ne revendique aucun niveau de conformité non évalué.

Pourquoi ce cas change la priorité

Sans cette méthode, Inès aurait peut-être consacré son après-midi à ajouter une animation de calendrier. Le test révèle au contraire une difficulté qui empêche d'atteindre le résultat principal du produit.

Elle peut maintenant choisir sa prochaine mission : corriger un blocage, vérifier le parcours, puis seulement reprendre les fonctionnalités secondaires. C'est aussi une façon de valider une idée de business sur son usage réel, au-delà de la simple attractivité d'une maquette.

Pourquoi ça marche pour une petite équipe

Le premier bénéfice est la réduction de l'ambiguïté. « Améliorer l'accessibilité » est un chantier sans fin clairement visible. « Permettre la réservation au clavier sur mobile et ordinateur » est une tâche dont tu peux observer le résultat.

Le deuxième bénéfice est la continuité. Quand tu changes de prestataire ou reprends le projet après plusieurs semaines, tu retrouves les environnements testés, les limites et les décisions. GitHub met précisément en avant cette utilité de la documentation accessible aux contributeurs.

Le troisième bénéfice est la relation avec les utilisateurs. Une personne bloquée n'a pas besoin de connaître les critères techniques pour signaler qu'elle ne peut pas terminer un paiement. Une déclaration lisible lui indique comment transmettre l'information et ce que l'équipe sait déjà.

Enfin, la méthode protège ton temps. Tu ne traites pas chaque détail comme une urgence identique. Tu privilégies les tâches impossibles, puis les erreurs qui compliquent fortement les parcours essentiels. Cela ne dispense pas d'une évaluation complète lorsqu'elle est nécessaire.

Ce qu'un fichier ACCESSIBILITY.md apporte réellement

Dans un dépôt GitHub, le fichier peut être placé à la racine, dans .github/ ou dans docs/. GitHub explique qu'il est désormais mis en évidence dans les informations du dépôt. Il peut servir de référence aux développeurs et contributeurs.

Ce fichier n'est pas automatiquement la déclaration publique de ton application. Un utilisateur final ne consulte pas forcément le dépôt. Pour lui, prévois un accès simple depuis l'interface ou une page d'information appropriée, après validation de son contenu.

Ne confonds pas non plus documentation et fonctionnalité : créer un fichier ne corrige aucun bouton, aucun contraste et aucun formulaire. Le document doit refléter les tests et les corrections, pas les remplacer.

Comment l'appliquer dès aujourd'hui en 90 minutes

Le temps indiqué ici est une proposition d'organisation, pas une durée moyenne mesurée. Si ton application est complexe, certains tests demanderont davantage de travail.

Pendant les quinze premières minutes, choisis un seul parcours essentiel. Écris son point de départ, son résultat attendu et les étapes intermédiaires. Par exemple : « Ouvrir une fiche produit, remplir le formulaire et recevoir une confirmation. »

Consacre ensuite vingt minutes à une navigation sans souris. Utilise Tabulation, Maj + Tabulation, Entrée et Échap lorsque c'est pertinent. Observe la position du focus et vérifie que chaque action importante reste atteignable.

Pendant vingt minutes supplémentaires, examine les erreurs. Laisse un champ obligatoire vide, utilise une valeur invalide et vérifie que le message explique comment corriger la situation. Ne te contente pas d'un encadré coloré sans texte explicite.

Prends quinze minutes pour noter tes observations. Sépare ce que tu as testé de ce que tu n'as pas testé. Une case « lecteur d'écran : non vérifié » vaut mieux qu'un résultat inventé.

Utilise les vingt dernières minutes pour écrire une première déclaration de travail : périmètre, objectif, contrôles réalisés, limites connues et canal de signalement. Ne publie pas d'adresse fictive. Si le canal n'est pas prêt, crée d'abord ce moyen de contact avant de rendre la déclaration publique.

Tu peux t'appuyer sur le générateur du W3C pour ne pas oublier de rubrique. Son existence ne certifie pas le texte que tu produis. Relis chaque phrase comme une affirmation qui doit pouvoir être démontrée.

Erreurs courantes à éviter

Affirmer une conformité sur la base d'un score automatique

Un scanner peut signaler certains problèmes techniques. Il ne sait pas toujours si une tâche est compréhensible ou si l'ordre des actions a du sens. Complète ses résultats par des essais manuels et, lorsque possible, par des retours de personnes concernées.

Copier la déclaration d'un autre produit

Tu risques de citer des navigateurs jamais testés, des délais de réponse irréalistes ou des obligations qui ne correspondent pas à ton activité. Une déclaration courte mais exacte est plus utile qu'un texte juridique spectaculaire et faux.

Confondre absence de plainte et absence de problème

Une personne bloquée peut simplement quitter ton service. Si ton formulaire de signalement est lui-même inaccessible, tu ne recevras peut-être jamais son retour. Teste également le moyen de contact.

Promettre une correction immédiate

Certaines difficultés demandent une refonte. Explique ce qui est prévu sans inventer de date. Si une solution de remplacement existe, décris-la clairement et vérifie qu'elle fonctionne.

Tout remettre à plus tard

Un MVP n'a pas besoin de dix pages de politique pour commencer à tester son parcours principal. Mais attendre la première grosse vente pour regarder si le formulaire est utilisable revient à ignorer une partie de tes utilisateurs potentiels.

Transformer cette compétence en mission de service limitée

Tu peux appliquer ACCÈS à ton propre produit, ou en faire une prestation de diagnostic préliminaire pour une petite structure. Attention au vocabulaire : si tu ne disposes pas de la qualification et de la méthode nécessaires, ne vends pas une certification de conformité.

Une offre limitée peut consister à examiner un parcours, décrire les obstacles reproductibles, proposer des priorités et préparer un brouillon de déclaration à valider par le client. Le livrable doit distinguer les tests réalisés, les limites de la mission et les recommandations.

Pour fixer un tarif, calcule le temps de préparation, d'exécution, de restitution et de reprise. Le guide sur le prix d'une prestation peut t'aider à structurer ce calcul sans supposer un tarif de marché.

Avant de prospecter, montre un exemple de grille anonymisée ou fictive. Explique que tu identifies des problèmes observables, sans garantir une conformité globale. Puis demande à un professionnel du secteur si ce livrable répond à un besoin réel. Tu peux aussi choisir une idée de business adaptée avant de t'engager sur une offre.

Si tu crées une activité de service, prévois le temps nécessaire pour suivre les corrections. Un rapport qui s'accumule dans une boîte mail sans responsable n'apporte pas la même valeur qu'un diagnostic accompagné d'une prochaine action clairement attribuée.

FAQ : déclaration d'accessibilité et MVP

Faut-il une déclaration dès le premier prototype ?

Elle peut être utile très tôt pour documenter les limites et le contact. L'obligation légale éventuelle dépend du contexte. Une déclaration ne remplace pas les tests.

ACCESSIBILITY.md rend-il mon application accessible ?

Non. C'est un document de transparence. Il ne modifie pas le comportement de l'interface et ne démontre aucune conformité à lui seul.

Puis-je écrire « conforme WCAG 2.2 AA » ?

Seulement si tu disposes d'une évaluation suffisante pour soutenir cette affirmation sur un périmètre défini. Un objectif de conformité n'est pas une conformité vérifiée.

Quel test réaliser en premier ?

Choisis le parcours principal et essaie de le terminer au clavier, puis examine les messages d'erreur. Note précisément l'environnement et les limites de ton essai.

Une déclaration peut-elle évoluer ?

Oui. Mets-la à jour quand les parcours, les résultats des tests, les obstacles ou les moyens de contact changent. Conserve des dates et des preuves.

Ressources complémentaires et prochaine étape

L'annonce de GitHub explique l'emplacement et l'usage du fichier ACCESSIBILITY.md. Le guide du W3C détaille les informations utiles aux utilisateurs, tandis que son générateur fournit une structure à personnaliser.

Pour préparer ton projet, tu peux également consulter le guide DOTO sur les premiers clients sans publicité et celui sur le business plan sans chiffres inventés. Ces ressources aident à relier le travail technique à une offre et à une validation commerciale, sans promettre de revenus.

Aujourd'hui, choisis une seule tâche que ton utilisateur doit pouvoir accomplir. Teste-la, écris ce que tu as observé et décide de la correction prioritaire. Tu peux ensuite explorer les missions guidées de DO TO DAY pour avancer étape par étape, sans ajouter de fonctionnalités simplement parce qu'elles semblent intéressantes.

Une déclaration utile ne dit pas « tout est parfait ». Elle dit où tu en es, ce que tu sais et ce que tu vas vérifier ensuite.

Sources et limites

Exemple fictif, pas d'audit ni d'avis juridique ; les obligations dépendent de la situation et les tests ne prouvent pas une conformité globale.

• GitHub — Accessibility statements now have a home on GitHub, 5 novembre 2026
• W3C WAI — Developing an Accessibility Statement
• W3C WAI — Generate an Accessibility Statement