Skip to main content
Beta: Front-End Checklist is currently in beta. Some issues are still being fixed. Thanks for your patience.

Use inclusive language

Content uses inclusive, non-discriminatory language that welcomes all users regardless of ability, gender, race, or background.

Utilities
Quick take
Typical fix time 20 min
  • Replace ableist terms (crazy, lame, blind to) with neutral alternatives
  • Use gender-neutral language (they, users, people) by default
  • Write error messages that guide rather than blame users
  • Avoid idioms and cultural references that don't translate globally
Why it matters: Language shapes experience—ableist, gendered, or exclusionary terminology creates unwelcoming experiences and reinforces harmful stereotypes, even unintentionally.

Rule Details

Inclusive language makes all users feel welcome and avoids reinforcing harmful stereotypes.

Code Example

// ❌ Ableist language in code
function sanityCheck(data: unknown): boolean { ... }
const dummyUser = { name: 'Test' }
// This is a crazy edge case
 
// ✅ Inclusive alternatives
function validateInput(data: unknown): boolean { ... }
const sampleUser = { name: 'Test' }
// This is an unusual edge case

Why It Matters

Language shapes experience—ableist, gendered, or exclusionary terminology creates unwelcoming experiences and reinforces harmful stereotypes, even unintentionally.

Ableist Language Alternatives

AvoidUse Instead
crazy, insaneunexpected, surprising, intense
lameuninteresting, ineffective
blind to, turn a blind eyeunaware of, ignore
deaf tounresponsive to, ignore
dumbsilent, unable to speak
cripple, crippleddisable, impair, damage
sanity checkconfidence check, validation
dummy (variable, data)placeholder, sample, test

Gender-Neutral Language

<!-- ❌ Gendered assumptions -->
<p>When a user logs in, he can access his dashboard.</p>
<label>Salutation: Mr. / Mrs. / Ms.</label>
 
<!-- ✅ Gender-neutral -->
<p>When users log in, they can access their dashboard.</p>
<label>Name (optional title)</label>
<!-- Or offer inclusive options: Mx., prefer not to say, custom -->

Error Messages

// ❌ Blaming, unhelpful error messages
const errors = {
  invalidEmail: "You entered an invalid email",
  wrongPassword: "Wrong password. Try again.",
  formFailed: "You made errors in the form"
}
 
// ✅ Helpful, non-blaming messages
const errors = {
  invalidEmail: "Please enter a valid email address (example: name@domain.com)",
  wrongPassword: "The password doesn't match our records. Need to reset it?",
  formFailed: "Some fields need attention. See highlighted areas below."
}

Avoiding Cultural Bias

// ❌ Culture-specific idioms
const messages = {
  success: "Home run! You did it!",
  error: "Back to square one",
  loading: "Keep your fingers crossed"
}
 
// ✅ Universal language
const messages = {
  success: "Complete! Your changes are saved.",
  error: "Let's try a different approach",
  loading: "Processing your request"
}

Form Design

// ❌ Binary gender, required field
<select name="gender" required>
  <option value="male">Male</option>
  <option value="female">Female</option>
</select>
 
// ✅ Inclusive options, optional field
<select name="gender" aria-describedby="gender-note">
  <option value="">Prefer not to say</option>
  <option value="female">Female</option>
  <option value="male">Male</option>
  <option value="non-binary">Non-binary</option>
  <option value="other">Other</option>
</select>
<p id="gender-note" className="helper-text">
  Optional. Used for personalization only.
</p>

Name Fields

// ❌ Assumes Western naming conventions
<input name="firstName" required />
<input name="lastName" required />
 
// ✅ Flexible name handling
<input
  name="fullName"
  required
  aria-describedby="name-help"
/>
<p id="name-help">Enter your name as you'd like to be addressed</p>
 
// Or if separate fields needed:
<input name="givenName" placeholder="Given name(s)" />
<input name="familyName" placeholder="Family name" />

Placeholder Text and Examples

<!-- ❌ Culturally specific examples -->
<input placeholder="John Smith">
<input type="tel" placeholder="(555) 123-4567">
 
<!-- ✅ Generic or varied examples -->
<input placeholder="Your name">
<input type="tel" placeholder="+1 555 123 4567" aria-describedby="phone-format">
<p id="phone-format">Include country code for international numbers</p>

Content Review Checklist

## Language Review Checklist
 
### Ableist Language
- [ ] No "crazy," "insane," "lame," "dumb"
- [ ] No "blind to," "deaf to," "turn a blind eye"
- [ ] No "sanity check," "dummy data"
 
### Gender
- [ ] Uses "they/them" for unknown individuals
- [ ] Avoids "he/she" constructions
- [ ] Gender fields are optional or inclusive
 
### Tone
- [ ] Error messages guide, don't blame
- [ ] Instructions are encouraging, not condescending
- [ ] Avoids idioms that don't translate
 
### Names & Identity
- [ ] Name fields accommodate global naming conventions
- [ ] Titles/salutations are optional
- [ ] Examples use diverse names

Exceptions

  • Some exact legal, product, or brand wording cannot be simplified freely, but the surrounding content should still reduce ambiguity and cognitive load where possible.
  • A content rule should be judged on the final user-facing wording, not just on individual banned phrases taken out of context.
  • If a page has both structural accessibility failures and content clarity issues, fix the failure that prevents users from reaching or perceiving the content first.

Standards

  • Align the implementation with W3C WAI: WCAG Overview and verify the rendered experience, not only the source code.
  • Align the implementation with MDN: Accessibility and verify the rendered experience, not only the source code.

Verification

Automated Checks

  • Use automated tools to flag common issues

Manual Checks

  • Read all user-facing text with fresh eyes
  • Check error messages for blame language
  • Review form fields for assumptions about identity
  • Test with users from diverse backgrounds

Use with AI

Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.

Check

Verify implementation

Review content for ableist language (crazy, lame, blind to), gendered assumptions (he/she defaults), cultural bias, and exclusionary terminology. Verify error messages and instructions are respectful and constructive.

Fix

Auto-fix issues

Replace ableist terms with neutral alternatives. Use gender-neutral language (they, users, people). Avoid idioms that may not translate across cultures. Write error messages that guide rather than blame.

Explain

Learn more

Explain how language shapes experience and can unintentionally exclude or harm users, and why inclusive language creates welcoming digital spaces for everyone.

Review

Code review

Review the rendered markup and interactive states that affect Use inclusive language. Flag exact elements, roles, labels, focus behavior, or keyboard interactions that violate the rule, and note how to verify the fix with browser accessibility tooling or assistive tech.

Sources

References used to support the guidance in this rule.

Further Reading

Tools and supplementary material for exploring the topic in more depth.

axe DevTools
deque.comTool

Rules that often go hand-in-hand with this one.

Write in plain language

Content uses clear, simple language that is easy to understand for users with cognitive disabilities and non-native speakers.

Accessibility
Avoid sensory-only instructions

Instructions do not rely solely on sensory characteristics like color, shape, size, location, or sound.

Accessibility
Fix empty and broken links

All links contain accessible text content and do not lead to broken destinations.

Accessibility
Use descriptive link text

Link text clearly describes the destination or purpose without relying on surrounding context.

Accessibility

Was this rule helpful?

Your feedback helps improve rule quality. This stays internal for now.

Loading feedback...
0 / 385