Contexte et objectifs
GitHub a constaté que les informations d’accessibilité étaient dispersées entre tickets, guides de contribution, rapports d’audit et conversations informelles. Cette fragmentation oblige les utilisateurs à chercher longtemps la procédure de signalement d’un obstacle et empêche les mainteneurs de conserver le contexte lorsque les équipes changent. Pour remédier à ce problème, la plateforme a créé un emplacement unique – le fichier ACCESSIBILITY.md – afin de rendre les objectifs d’accessibilité, les attentes des contributeurs, les environnements supportés et les limites connues immédiatement visibles depuis la page d’accueil du dépôt.
Fonctionnement du fichier ACCESSIBILITY.md
Le fichier est reconnu lorsqu’il se trouve à la racine du dépôt, dans le répertoire .github/ ou docs/. Un projet peut également hériter d’une déclaration stockée dans le dépôt .github/ de son organisation, ce qui évite la duplication de texte. Pour les dépôts publics, GitHub propose d’ajouter ou de proposer une déclaration via le menu Insights > Community Standards, où un modèle concis pré‑rempli guide les mainteneurs. En plus du fichier, chaque nouveau dépôt reçoit automatiquement un label d’incident accessibility, facilitant le suivi et la catégorisation des tickets liés aux barrières d’accès.
Le contenu du fichier n’est pas figé ; il doit refléter la capacité réelle du projet à maintenir les informations à jour. Les sections recommandées incluent : priorités et objectifs, attentes des contributeurs (vérifications, preuves, agents automatisés), procédure de signalement (sans exigence de divulgation de handicap), processus de réponse, environnements supportés, limitations connues, responsabilité de mise à jour et voies de feedback. Le texte précise que la mention d’une version WCAG (par exemple WCAG 2.1 AA) ne constitue pas une certification ; une telle affirmation nécessite une évaluation formelle avec date, méthode et évaluateur clairement indiqués.
Exemples d’application et bonnes pratiques
Le CLI de GitHub illustre l’usage concret du fichier : la déclaration décrit un problème de lecture d’un tableau avec un lecteur d’écran et fournit une commande qui affiche les numéros et titres des pull‑requests ligne par ligne, contournant ainsi la difficulté. De même, le GitHub Annotation Toolkit signale que ses annotations Figma reposent sur la position du canvas et les lignes de connexion, ce qui n’est pas exploitable par les technologies d’assistance. La solution proposée consiste à ajouter une description textuelle structurée identifiant chaque élément annoté, son sémantique et son ordre.
Ces exemples montrent que le ACCESSIBILITY.md ne se limite pas à un texte juridique ; il offre des instructions opérationnelles (ex. : commande de contournement) et expose clairement les zones non testées, comme l’absence de validation clavier‑seul ou lecteur d’écran pour le toolkit. En affichant la déclaration sur la page d’accueil du dépôt, GitHub rend ces informations aussi accessibles que les guides de contribution, les codes de conduite et les politiques de sécurité, renforçant ainsi la visibilité et la traçabilité des pratiques d’accessibilité au sein de la communauté open source.
