Inclusive language is accurate language: it describes people and systems without importing bias, stereotypes, or charged metaphors. These rules cover terminology, pronouns, and the people and scenarios that appear in examples and imagery. Writing for assistive technology is covered in accessibility.
incl-001 should GuidesAPI docsMarketingBlog Use singular ‘they’ as the default gender-neutral pronoun when referring to a generic person whose gender is unknown or unspecified. Avoid ‘he or she’, ‘he/she’, or alternating gendered pronouns across examples.
Examples
Rationale
Singular “they” is the established gender-neutral pronoun for a generic person, and it avoids both gender assumptions and clumsy alternatives like “he or she”.
incl-002 should GuidesAPI docsMarketingBlog When writing about a real, specific person, use the pronouns that person uses; do not assume pronouns from name or appearance.
Rationale
Using the pronouns a real person uses is a basic matter of respect and accuracy.
incl-003 should GuidesAPI docsMarketingBlog Replace gendered job titles and general terms with gender-neutral equivalents (‘chair’ for ‘chairman,’ ‘person-hours’ for ‘man-hours’).
Examples
Rationale
Gendered titles imply a role belongs to one gender; neutral equivalents include everyone who holds it.
incl-004 should GuidesAPI docsMarketingBlog Avoid ableist language including ‘crazy,’ ‘insane,’ ‘sanity check,’ ‘blind to,’ ‘cripple,’ and ‘dumb’; replace with context-appropriate neutral alternatives.
Examples
Rationale
Words that use disability as an insult demean disabled readers and are usually less precise than a plain description.
incl-011 should GuidesAPI docsMarketingBlog When writing about disability, focus on the person; avoid terms that imply pity such as ‘suffering from,’ ‘victim of,’ ‘stricken with,’ or ‘wheelchair-bound.’
Examples
Rationale
Framing disability as suffering casts the person as a victim; neutral phrasing keeps them the subject.
incl-012 should GuidesAPI docsMarketingBlog Do not describe people without disabilities as ‘normal’ or ‘healthy’; use ‘nondisabled person,’ ‘person without a disability,’ ‘neurotypical person,’ or similar.
Examples
Rationale
Calling nondisabled people “normal” implies disabled people are abnormal.
incl-013 should GuidesAPI docsMarketingBlog Acknowledge that some communities (autistic, Deaf, blind) prefer identity-first language; research and respect community preferences rather than applying a single rule universally.
Examples
Rationale
Some communities prefer identity-first language, so respecting a stated preference matters more than a blanket rule.
incl-016 should GuidesAPI docsMarketingBlog Don’t call a person ‘inspiring,’ ‘brave,’ or ‘courageous’ just for having a disability, and don’t frame disability as something to overcome; both are condescending.
Examples
Rationale
Praising someone as inspiring simply for having a disability, or framing disability as an obstacle to conquer, centers the observer’s feelings over the person and reads as condescending.
incl-022 should GuidesAPI docsMarketingBlog Avoid euphemistic or patronizing disability terms such as ‘physically challenged,’ ‘special,’ ‘differently abled,’ or ‘handi-capable.’
Examples
Rationale
Euphemisms like “differently abled” are widely seen as patronizing; plain terms are preferred by most disabled people.
incl-005 should GuidesAPI docsMarketingBlog Avoid violent figurative language in technical contexts, including ‘hang,’ ‘kill,’ and ‘STONITH’; use specific, descriptive alternatives.
Examples
Rationale
Violent metaphors read as harsh and often have exact technical terms that are clearer.
incl-006 should GuidesAPI docsMarketingBlog Replace ‘master/slave’ terminology with alternatives such as ‘primary/replica,’ ‘controller/agent,’ or ‘parent/subordinate.’
Examples
Rationale
The terms carry the weight of slavery; neutral pairs like primary and replica describe the relationship without it.
incl-007 should GuidesAPI docsMarketingBlog Replace ‘blacklist/whitelist’ with ‘blocklist/allowlist’ or rewrite the sentence to avoid the terms entirely.
Examples
Rationale
Tying good and bad to white and black reinforces racial associations, while blocklist and allowlist say the same thing plainly.
incl-014 should GuidesAPI docsMarketingBlog When an established non-inclusive term must be introduced (in code or as an industry term), introduce it once, in parentheses and in code font if applicable, then use the preferred term throughout the rest of the document.
Examples
master in older repositories). The primary branch then requires review before merges.master branch. The master branch then requires review before merges.Rationale
When an industry or code term is unavoidable, introducing it once and then using the preferred term keeps the content searchable without repeating the harmful term.
incl-015 should GuidesAPI docsMarketingBlog Do not use color as a metaphor for positive or negative qualities (‘black hat,’ ‘white hat,’ ‘red team’); use colors only to describe actual colors.
Examples
Rationale
Good-and-bad color metaphors carry the same associations as blacklist and whitelist.
incl-019 should GuidesAPI docsMarketingBlog Do not use slang that could be considered cultural appropriation, such as ‘spirit animal’; do not use profane or derogatory terms.
Examples
Rationale
Terms lifted from a culture as slang trivialize it.
incl-020 should GuidesAPI docsMarketingBlog Avoid the ‘pets vs. cattle’ metaphor for comparing on-premises/stateful systems with stateless cloud systems.
Examples
Rationale
The metaphor is jarring and unclear, so describing the systems directly is plainer.
incl-023 should GuidesAPI docsMarketingBlog Avoid socially charged technical terms such as ‘native feature’ and ‘first-class citizen’ where possible.
Examples
Rationale
Terms like “first-class citizen” carry social baggage that a neutral description avoids.
incl-008 should GuidesAPI docsMarketingBlog Use diverse names reflecting a variety of ethnicities and genders in examples; avoid names that skew toward a single cultural background.
Examples
Rationale
Names drawn from one background signal a narrow imagined audience; varied names reflect the real readership.
incl-009 should GuidesAPI docsMarketingBlog Avoid stereotypes in examples, images, and job-role depictions; represent a variety of genders, ethnicities, ages, abilities, and socioeconomic backgrounds.
Examples
Rationale
Stereotyped roles in examples and images alienate readers who do not fit them and misrepresent the audience.
incl-010 should GuidesAPI docsMarketingBlog Avoid examples that are overly US-centric or reflect primarily a Western or affluent lifestyle; be mindful of holidays, sports, foods, and cultural practices.
Examples
Rationale
Examples built on one region’s defaults exclude the rest of a global audience.
incl-017 should GuidesAPI docsMarketingBlog Be inclusive of diverse family structures in examples and imagery; do not default to a nuclear family of two parents and biological children.
Examples
Rationale
Defaulting to one family shape excludes the many readers whose families differ.
incl-018 should GuidesAPI docsMarketingBlog Do not make generalizations about people, countries, regions, or cultures, including positive or neutral generalizations.
Examples
Rationale
Even a positive generalization about a group flattens real variation and can offend.
incl-021 should GuidesAPI docsMarketingBlog Avoid framing content around ‘native speakers’ vs. ‘non-native speakers’ of English; revise to discuss features in terms relevant to anyone regardless of language background.
Examples
Rationale
Framing readers as native or non-native speakers is exclusionary and usually irrelevant to the feature being described.