Un fichier nommé ACCESSIBILITY.md est désormais officiellement reconnu et affiché sur la page d’accueil des dépôts GitHub. Cette évolution vise à donner un emplacement stable et prévisible aux projets pour expliquer leurs objectifs d’accessibilité, les limites connues et les processus de signalement des barrières. Le travail sur l’accessibilité, souvent dispersé dans les feuilles de route ou les fils de discussion, trouve enfin une adresse unique.

GitHub permet désormais à un dépôt de reconnaître ce fichier s’il est placé à la racine, dans le dossier .github/ ou docs/. De plus, les projets peuvent hériter de cette déclaration si elle est définie au niveau de l’organisation. Pour les dépôts publics, les mainteneurs peuvent y ajouter une déclaration via les « Community Standards » en utilisant un modèle de démarrage.

Ce mécanisme s’inscrit dans un mouvement plus large de structuration de la santé communautaire des projets, au même titre que les directives de contribution ou les politiques de conduite. En dédiant un espace à l’accessibilité, GitHub rend les pratiques du projet transparentes. On le voit déjà avec le CLI de GitHub, dont la déclaration détaille des contournements spécifiques pour les lecteurs d’écran, offrant une solution concrète aux utilisateurs.

La clarté avant la conformité légale

L’efficacité de ces déclarations repose sur leur lisibilité. Les experts en accessibilité insistent sur le fait que le langage simple et les chemins de signalement clairs sont plus utiles que des formulations lourdes tirées des normes. Le fichier ne dicte pas un format unique, ce qui est logique, car une petite librairie et une grande application web ont des besoins différents. Cependant, certaines rubriques ressortent comme fondamentales.

Les projets devraient clairement indiquer ses priorités : pourquoi l’accessibilité est importante pour eux, et quelles expériences utilisateur sont visées. Il faut aussi décrire les attentes envers les contributeurs, qu’il s’agisse d’humains ou d’agents de codage. Crucialement, le processus de réponse doit être défini : comment les problèmes sont-ils accusés réception, triés et communiqués ?

Définir ce que le projet peut maintenir

On ne peut pas se contenter de dire que le projet « est accessible ». Les déclarations les plus pertinentes détaillent ce qui a été testé et ce qui ne l’est pas. Par exemple, le GitHub Annotation Toolkit mentionne explicitement que sa librairie n’a pas fait l’objet de tests avec un clavier seul ou un lecteur d’écran. En contrepartie, il fournit une alternative structurée : une description textuelle accompagnant les annotations visuelles.

Pour les utilisateurs, cela signifie qu’ils savent exactement à quoi s’attendre. Et pour les mainteneurs, cela signifie une feuille de route claire pour les améliorations. D’ailleurs, même dans l’écosystème de l’IA, l’effort reste manuel. Des analyses montrent que même si le développement assisté par l’IA a un fort potentiel pour les développeurs en situation de handicap, l’accessibilité n’arrive pas automatiquement, elle exige une démarche délibérée (iTWire).

Ce qui doit guider la rédaction, c’est l’honnêteté sur la capacité de maintien. S’engager à suivre les normes WCAG n’est pas une preuve de conformité ; cela nécessite une évaluation spécifique, datée, et documentée. Il faut surveiller comment les équipes de projets vont intégrer cette nouvelle structure sans tomber dans le piège de la déclaration vide.

Sources

• Accessibility statements now have a home on GitHub, GitHub, 5 novembre 2026
• AI coding has real potential to open doors for developers with disabilities – but accessibility isn’t automatic, iTWire, 29 octobre 2026