GitHub reconoce desde el 5 de noviembre de 2026 un nuevo fichero estándar en los repositorios, ACCESSIBILITY.md, y lo muestra en la portada del proyecto con una pestaña Accessibility y un enlace en la barra lateral, igual que ya hacía con el README, la licencia o la política de seguridad. La idea es que cada proyecto tenga un lugar fijo donde explicar su estado de accesibilidad, qué entornos soporta y cómo comunicar barreras.
Las claves de ACCESSIBILITY.md en GitHub en 30 segundos
- GitHub muestra el fichero ACCESSIBILITY.md en una pestaña propia de la portada del repositorio.
- Se detecta en la raíz, en
.github/o endocs/, y se puede heredar del repositorio.githubde la organización. - Los repositorios públicos pueden crearlo con una plantilla desde Insights, en Community Standards.
- Los repositorios nuevos incluyen una etiqueta
accessibilitypara issues.
El anuncio, firmado por Jan Maarten, diseñador y especialista en accesibilidad de GitHub, funciona como los otros ficheros de salud de la comunidad. GitHub busca ACCESSIBILITY.md en la raíz del repositorio, en el directorio .github/ o en docs/. Si el repositorio no tiene uno, puede heredar el de la organización desde su repositorio especial .github, lo que permite a una empresa con decenas de proyectos publicar una declaración común y personalizarla solo donde haga falta.
Cómo crearlo y qué poner dentro
En los repositorios públicos, la vía más rápida es Insights > Community Standards, donde aparece una tarjeta de accesibilidad con un botón para añadir o proponer la declaración a partir de una plantilla breve. La plantilla trae indicaciones que el proyecto sustituye por su propia información, y GitHub la documenta en su guía para añadir una declaración de accesibilidad.
GitHub sugiere que el fichero recoja las prioridades y objetivos del proyecto; qué se espera de quien contribuye, con indicaciones tanto para personas como para agentes de programación; cómo informar de una barrera de accesibilidad; cómo se tramitan esos avisos, con niveles de gravedad opcionales; los entornos soportados, incluidos plataformas, navegadores, métodos de entrada y tecnologías de apoyo; las limitaciones conocidas con sus alternativas y enlaces a las correcciones pendientes; quién mantiene la declaración, y cómo dar opinión. Hay una recomendación explícita: no exigir a quien informa que revele una discapacidad ni que aporte capturas o grabaciones.
Como ejemplos, GitHub cita su propia CLI, que documenta ajustes, barreras conocidas y una forma de listar pull requests más cómoda con lector de pantalla; el GitHub Annotation Toolkit, que reconoce una limitación de su biblioteca de Figma y admite que no se ha probado solo con teclado ni con lector de pantalla, y el Open Source Accessibility Toolkit.
Un objetivo WCAG no es una certificación
El punto más útil del anuncio es una advertencia. Un proyecto puede indicar como objetivo una versión y un nivel de las pautas WCAG (Web Content Accessibility Guidelines), pero GitHub recalca que «un objetivo no establece una conformidad verificada». Para afirmar conformidad hace falta una evaluación que precise alcance, fecha, método y quién la hizo. Es una distinción importante para equipos que trabajan con administraciones o clientes sujetos a normativa, como la Ley Europea de Accesibilidad, aplicable desde junio de 2025, aunque el anuncio de GitHub no menciona ninguna regulación concreta.
Para un equipo de sistemas o de plataforma, el fichero tiene una utilidad práctica: centraliza qué se ha probado y qué no, y evita que esa información quede repartida entre issues, wikis y conversaciones. También es un buen sitio para dar instrucciones a los asistentes de IA que generan código de interfaz. GitHub no explica si los repositorios privados tienen la misma plantilla en Community Standards, ya que el anuncio solo menciona los públicos.
Preguntas frecuentes
¿Dónde se coloca el fichero ACCESSIBILITY.md?
En la raíz del repositorio, en .github/ o en docs/. También se puede heredar del repositorio .github de la organización.
¿Cómo se crea desde GitHub?
En repositorios públicos, desde Insights > Community Standards, que ofrece una plantilla para añadir o proponer la declaración.
¿Indicar WCAG en el fichero certifica la accesibilidad?
No. GitHub aclara que un objetivo WCAG no es conformidad verificada; para eso hace falta una evaluación con alcance, fecha, método y evaluador.
Fuentes:
