Writing bias-free content

Bias-free writing ensures that your documentation does not exclude, stereotype, or make assumptions about your readers based on characteristics like gender, age, disability, race, or cultural background. This is not about political correctness — it is about accuracy and professionalism. Documentation that makes assumptions about its readers is documentation that alienates some of them.

This guidance applies most strictly to public-facing documentation, read by a genuinely unknown, global audience. Internal documentation for a known team may reasonably use more context-specific references — but the core principle (don't make a reader feel like an afterthought) still applies everywhere; see the Public vs. Private Knowledge Base Structure section of the Knowing Your Audience guide for how visibility tier shapes other writing decisions the same way.

Gender-Neutral Language

Do not assume the gender of your reader or any user you are describing. The singular "they" — now widely accepted in formal writing — is the cleanest solution for referring to a person whose gender is unknown or unspecified.

Where possible, restructure the sentence to use the second person ("you") or a plural subject, which avoids the pronoun issue entirely:

• "Administrators can access..." rather than "An administrator can access... They can..."
• "Users should update their passwords" rather than "Each user should update their password"

This same guidance is referenced, in brief, in the Words to Avoid quick reference — this article is the fuller treatment it points to.

Gender-neutral job titles and role terms

Beyond pronouns, some role names default to a gendered form out of habit. Use the neutral alternative in documentation regardless of which gender the specific person you're describing happens to be, since documentation is usually describing a role generically:

• chairperson, not chairman
• server, not waiter/waitress
• businessperson, not businessman

Age-Neutral Language

Avoid assumptions about the age of your reader. Do not write documentation that assumes familiarity with specific technologies that only younger readers would know ("swipe to navigate") or that assumes limited familiarity with technology that implies older readers ("even if you are not tech-savvy").

Write for the actual knowledge level of your audience, not for assumed generational characteristics.

Disability-Inclusive Language

Use person-first language when referring to people with disabilities, unless your audience or style specifically calls for identity-first language. Person-first language puts the person before the condition.

Avoid using disability as a metaphor: "blind spot," "falls on deaf ears," "lame excuse." These uses are generally harmless in casual conversation but are worth avoiding in documentation as a professional standard.

Note on identity-first vs. person-first language: person-first phrasing ("a person with autism") is the safer general default, but it is not universal — many autistic self-advocates and other communities explicitly prefer identity-first language ("an autistic person"). Where you know your audience's preference, follow it. Where you don't, person-first is the reasonable default, but don't treat either form as an absolute rule that overrides a community's stated preference.

Substance use and mental health terminology

Avoid language that stigmatizes a health condition, even when used casually or as a comparison. "Addict" reduces a person to a condition; prefer "person with a substance use disorder" when the context genuinely calls for describing this. Similarly, avoid using mental health terms as casual hyperbole in documentation — "crazy," "insane," or "unstable" used to mean "surprising," "extreme," or "unreliable" borrows the weight of real conditions for an unrelated meaning. Replace with the word you actually mean: "unpredictable," "resource-intensive," "produces inconsistent results" — whatever the specific, factual claim is, rather than a reflexive substitution for the flagged word. The fix depends on what you're actually trying to say, not a fixed word swap.

Terms with outdated or ableist origins

A few common words have a specific, often-overlooked history worth being aware of: "dumb," as a historical term for a person unable to speak, is now more commonly used to mean "unintelligent" — avoid both uses in documentation; for the literal meaning, use "non-verbal" or "unable to speak," and for the colloquial meaning, use a precise word for what you actually mean ("unhelpful," "unclear," "not effective") rather than either sense of "dumb."

Culturally Neutral Language

Avoid idioms, colloquialisms, and culturally specific references that will not translate well for a global readership. What is immediately clear to readers from one culture may be opaque or confusing to readers from another. See the Idioms and Culture-Bound Language section of the Voice and Tone guide for the base rule and additional examples; the entries below are specific to language that carries cultural or exclusionary weight beyond simple translation difficulty.

Sports metaphors, cooking metaphors, and political references all carry cultural baggage. Where possible, use direct, literal language that requires no cultural context to understand.

Calendars, holidays, and "business days"

Be cautious with date examples and scheduling language that assume a specific national or religious calendar. "Business days" assumes a Monday–Friday work week that doesn't hold everywhere; a holiday reference ("just before the holidays") assumes a specific holiday and calendar that not every reader shares. Where a concrete example date is needed, prefer the neutral formats described in the Numbers, Dates, and Time guide, and describe scheduling constraints explicitly ("weekdays, excluding public holidays in your region") rather than assuming a shared calendar.

Bias in Example Content

Bias shows up not just in grammar and word choice, but in the illustrative content writers create to demonstrate a feature — sample names, scenarios, and imagery.

• Names in sample data: Avoid defaulting to the same name or a narrow set of names (for example, always "John Smith") in every example. Rotate a genuinely diverse set of names across your knowledge base so no single demographic is implicitly treated as the default user.
• Assumed family or relationship structures: A scenario that casually assumes "his wife" or "her husband" bakes in an assumption that isn't relevant to the feature being documented. Use neutral framing ("their partner," "a family member," or simply omitting the detail) unless the relationship structure is actually relevant to the content.
• Imagery and avatars: If your documentation includes illustrative photos, icons, or avatars, avoid defaulting to a single demographic across every example. This is a design system concern as much as a writing one, but writers choosing or requesting imagery should apply the same standard.

Avoid Assumptions About Reader Ability or Experience

Do not assume readers are using the same hardware, operating system, or browser as you. Do not assume they have the same level of technical literacy as you. Provide cross-platform instructions when relevant and write steps that describe what to look for, not just where to click, so that readers with different setups can orient themselves.

Similarly, avoid language that presupposes a baseline level of familiarity: "as you know," "naturally," "as you might expect." These phrases exclude readers who do not already know the thing being referenced, and are a close relative of the condescension problem covered in the Voice and Tone guide (simply, just, easily, obviously) — both signal that the writer expects more from the reader than the reader may actually have.

Reviewing Your Writing for Bias

Bias is often invisible to the writer. A practical review technique: read your draft and ask, for each sentence, whether it would mean the same thing to a reader of any gender, any age, any cultural background, and any physical ability. If any of those readers would be confused, excluded, or feel spoken down to, the sentence needs revision.

Self-Audit Checklist

Before publishing, check the article against these questions:

• Are all pronouns gender-neutral, using "they," second person, or a restructured plural subject?
• Is the content free of assumptions about the reader's age or generation-specific technology familiarity?
• Does disability-related language use person-first phrasing, and is it free of disability used as a metaphor?
• Have culture-specific idioms and metaphors been replaced with direct, literal language?
• Do date, holiday, and "business day" references avoid assuming a specific national or religious calendar?
• Do sample names, scenarios, and any imagery reflect a genuinely diverse range of people, rather than a single default demographic?
• Is the content free of assumptions about the reader's hardware, OS, browser, or baseline technical familiarity?
• Would this content read the same way to a reader of any gender, age, cultural background, and physical ability?