The Open Source Docs Accessibility Checklist I Wish Every Project Had

Most open source projects do not have an accessibility problem. They have an awareness problem.

The fixes are rarely complicated. A heading hierarchy that screen readers can navigate. Alt text on architecture diagrams that actually describes the diagram. Link text that says something more useful than "click here." Contrast ratios that work for users in bright sunlight or with low vision. Plain language that does not assume the reader has a computer science degree. These are not expensive interventions. They are habits — and most FOSS documentation toolchains make them easy to get wrong and surprisingly easy to get right, once you know what to look for.

The problem is that most documentation contributors have never been handed a checklist. Accessibility in FOSS docs is treated as a specialist concern — something for dedicated accessibility teams, if the project is large enough to have one. For everyone else, it is a gap that persists not out of indifference but out of not knowing where to start.

This talk is that starting point.

As a technical writer at Red Hat and a speaker on documentation accessibility, I have audited documentation across FOSS projects of every size. This talk distils those audits into a practical, immediately usable checklist — not a compliance framework, not a legal requirement, but a set of concrete checks any contributor can run on any documentation page today. We will walk through each item live, with real FOSS documentation examples showing the failure, the fix, and the difference it makes to a real user.

The checklist covers headings and document structure, image alt text for technical diagrams, table markup, link text, colour contrast, keyboard navigation considerations, and plain language. Every item is actionable without specialist tooling. All of it is open, shareable, and yours to take back to your project.