Accessible writing

Curb cuts - the little ramps where a sidewalk meets the street - were fought for by wheelchair users. Then everyone else started using them: parents with strollers, travelers with suitcases, delivery workers with carts. Accessibility features consistently follow this pattern: built for a specific need, useful to everyone.

• High-contrast text serves low-vision readers, and everyone reading a laptop in sunlight.
• Text-to-speech and captions serve blind and Deaf users, and everyone listening to a doc on a commute or watching a video in a quiet office.
• Keyboard access serves people who cannot use a mouse, and every power user who never wanted to.
• Plain language serves readers with cognitive disabilities, and every exhausted engineer skimming at 2am - Session 1's audience made universal.

Google's accessibility course teaches disability as a mismatch between a person and a design, not a fixed attribute of a person. The same barrier hits three kinds of readers:

Design for the permanent case and the temporary and situational cases come along for free. That multiplies your audience: the number of people who will ever experience your doc through a screen reader, a zoomed screen, or a monochrome e-reader is far larger than any disability statistic suggests.

Honesty note: unlike most sessions, this page is not a walkthrough of one source. It consolidates FOUR - Google's Tech Writing for Accessibility course (8 units), the accessibility sections of both the Google developer documentation style guide and the Microsoft Writing Style Guide, and Write the Docs' accessibility guidance. They agree on almost everything, which is exactly why the material is teachable as five rule groups rather than four bibliographies.

• Google's course supplies the inclusive-design framing and the editing checklist.
• The two style guides supply the mechanical rules: alt text, contrast, link text, color.
• Microsoft goes furthest on inclusive language, with a full bias-free communication section.
• Write the Docs supplies the community practice: test with real assistive tech, not just checkers.

Alt text is what a screen reader speaks in place of an image. The rules, agreed by every source:

• Describe the image in context. The same pipeline diagram gets different alt text in a quickstart ("the three Pulse scripts run in order") than in an architecture doc ("ingest writes raw CSVs that clean filters before metrics aggregates").
• Keep it short: a phrase or one to two sentences. Alt text is spoken linearly; a paragraph traps the listener.
• Decorative images get alt="" - empty, not missing. Empty tells the screen reader to skip; missing makes it read the filename aloud.
• Complex images split: a short alt ("daily event counts for July, described below") plus a full explanation in body text, where every reader benefits from it.
• Never start with "Image of..." - the screen reader already announced it is an image. And no all-caps: some screen readers spell capitalized words letter by letter.

Contrast is the one rule group with hard numbers, so use them:

• 4.5:1 minimum contrast ratio for small text against its background.
• 3:1 minimum for large text (roughly 18pt and up, or 14pt bold).
• Verify with a tool - the WebAIM Contrast Checker takes two hex codes and gives a pass or fail. Never eyeball it: your calibrated monitor in a dim office is the best-case scenario, not the median reader's.

Language about people carries assumptions, and docs travel further than you plan. The consolidated guidance:

• Center the person, not the condition: "a person who is blind", "people with limited mobility". Avoid framing disability as deficiency: no "normal users" versus everyone else, no "healthy" as the contrast to disabled.
• Drop the pity verbs: not "victim of", "suffers from", or "wheelchair-bound" - a wheelchair is mobility, not confinement. "Uses a wheelchair" states the fact.
• Respect identity-first preferences. Many Deaf and neurodivergent people prefer identity-first language ("Deaf person", "autistic person"). When you write for or about a specific community, their preference wins over the general rule.
• Microsoft's bias-free additions: gender-neutral language ("they", "chairperson", example names drawn from many cultures), no militaristic metaphors ("kill the process" becomes "stop the process" where it is not a literal command name), and diverse example names instead of ten Johns.

The visual rule that catches the most data-team artifacts: never rely on color, pattern, or position ALONE to carry meaning. Red-means-bad fails for colorblind readers, printed pages, and screen readers all at once.

• Pair every color with a text label. A red cell that also says FAIL survives every rendering; a red cell alone survives none of them.
• Every visual gets alt text - charts, screenshots, diagrams, the lot. Rule group 1 applies to all of them.

The last group is how the doc is built, not what it says:

• Real heading elements, no skipped levels. Screen-reader users navigate by heading; a bolded line styled to look like a heading is invisible to them, and jumping from H1 to H4 scrambles the outline.
• Descriptive link text. Screen readers can list every link on a page out of context - a list of nine "click here"s is useless. "See the config reference" works everywhere.
• Plain language, active voice, short sentences. Session 2's rules are also accessibility rules - cognitive load is an access barrier.
• Convert dense paragraphs to lists when they carry parallel items - exactly Session 2's paragraphs-to-lists move.
• Test it for real: zoom to 200%, navigate with keyboard only, then listen to the page with the screen reader already on your machine (VoiceOver on a Mac, Narrator on Windows). Ten minutes of listening teaches more than an hour of guidelines.