GitHub announced on November 5, 2026 that repository overview pages now recognize ACCESSIBILITY.md. Maintainers can place the file at the repository root, in .github or docs, or inherit it from an organization’s .github repository. Public repositories can add or propose a starter through Insights and Community Standards. New repositories also receive an accessibility issue label by default.
A predictable file makes practices and limitations discoverable
The statement can describe accessibility goals, contributor expectations, tested environments, known barriers, workarounds and the process for reporting problems. It sits beside contribution guidelines, codes of conduct and security policies rather than replacing technical documentation or issue tracking.
The useful outcome is a direct path for someone who cannot complete a task. Plain language, descriptive links and a response process matter more than legalistic claims. Maintainers should not require disability disclosure, screenshots or recordings to accept a report.
Related sources: GitHub: Accessibility statements now have a home ↗
A target standard is not verified conformance
GitHub notes that a project may name a WCAG version and level as a goal. Claiming conformance requires an evaluation with scope, date, method and evaluator. A statement should therefore separate tested facts, known gaps and aspirations.
List browsers, platforms, input methods and assistive technologies actually tested. If coverage is incomplete, say so and link to tracked work. An honest limitation with a workaround is more useful than a broad unsupported assurance.
Related sources: GitHub: Accessibility statements now have a home ↗
Ownership keeps the statement from becoming stale
Name the team or role responsible for updates and define how accessibility issues are acknowledged, triaged and communicated. Contributor instructions can ask for keyboard, zoom, contrast or screen-reader evidence appropriate to the change.
Coding agents can help draft tests or descriptions, but they cannot establish lived usability or conformance by themselves. Human testing with disabled users and specialists remains important for high-impact products.
Related sources: GitHub: Accessibility statements now have a home ↗
Canadian projects can connect the file to public-sector obligations without overstating compliance
Canadian organizations should align the statement with the standards and laws applicable to their sector and jurisdiction, using current legal advice where needed. The GitHub feature itself does not certify compliance with federal or provincial accessibility requirements.
Start with tasks users need to complete, known barriers, tested environments and an accessible contact path. Track response time and verified fixes, and invite reporters to confirm remediation without making them prove personal circumstances.
Sources and editorial method
We use the linked original statements and reports to distinguish documented facts from our analysis. Company announcements describe their authors’ plans and claims; they are not independent verification of future outcomes. This article is dated and will be revised if material evidence changes. Read our editorial standards and corrections process.
- GitHub: Accessibility statements now have a home ↗ — Official November 5 announcement and maintainer guidance for ACCESSIBILITY.md.