When we talk about accessibility in documentation, we usually mean screen reader compatibility, alt text for images, and colour contrast ratios. These things matter. But this talk argues that we have been drawing the accessibility circle too small — and that in doing so, we have been leaving out the majority of the people who need accessible documentation the most.
Good documentation is an accessibility feature for the developer in Pune who learned programming in Telugu and reads English as a second language. It is an accessibility feature for the neurodivergent contributor who cannot parse a wall of jargon-dense prose but can follow a clear, logically structured procedure. It is an accessibility feature for the first-generation college student who has never worked with a Linux terminal and has no senior engineer to ask. It is an accessibility feature for the maintainer in a low-bandwidth region who cannot load a documentation site bloated with JavaScript and embedded videos.
None of these users show up in a WCAG audit. All of them are being failed by documentation that was written for someone else.
As a technical writer at Red Hat, an open source contributor, and someone who has given talks on documentation accessibility, I have seen this pattern play out repeatedly: projects invest in accessibility tooling for their software interface while their documentation implicitly assumes a reader who is already halfway to knowing the answer. The result is documentation that is technically accessible and practically exclusionary at the same time.
This talk reframes documentation accessibility as a spectrum — from the technical baseline of WCAG compliance all the way to the deeper question of who your writing assumes the reader to be. We will look at real examples of documentation that passes every automated accessibility check and still fails large categories of real users. We will examine the assumptions baked into common documentation patterns — the "simple", the "just", the "obviously" — and what they signal to readers who do not share the writer's context. And we will look at what genuinely inclusive documentation practice looks like, drawing on real examples from FOSS projects that have got this right.
The argument this talk makes is simple but uncomfortable: if your documentation is only readable by someone who already mostly knows the answer, it is not accessible — regardless of your contrast ratios.
