From harness-claude
Guides inclusive UI text writing: gender-neutral pronouns (they/them), ability-neutral verbs (select vs click), culture-aware phrasing avoiding idioms. For diverse audiences, forms, errors, onboarding, accessibility labels.
npx claudepluginhub intense-visions/harness-engineering --plugin harness-claudeThis skill uses the workspace's default tool permissions.
> Inclusive language in UI — gender-neutral, ability-neutral, culture-aware writing, avoiding idioms that exclude
Guides UI text writing with active voice rules, verb-first buttons/links, actor-naming in errors, and passive voice exceptions. For labels, instructions, notifications, and reviews.
Improves unclear UX copy, error messages, microcopy, labels, and instructions for better interface clarity. Useful when refining confusing text or bad UX writing.
Designs UI copy including labels, instructions, errors, empty states, onboarding text, tooltips, CTAs, confirmation dialogs, voice/tone frameworks, and content models. For UX writing and content strategy.
Share bugs, ideas, or general feedback.
Inclusive language in UI — gender-neutral, ability-neutral, culture-aware writing, avoiding idioms that exclude
Use "they/them" as the default singular pronoun in UI text. When referring to a user whose gender is unknown or unspecified, use singular "they." "When a user logs in, they see their dashboard" -- not "he sees his dashboard" or "he or she sees his or her dashboard." GitHub, Slack, Stripe, and Google all adopted singular "they" in their style guides. The construction is grammatically established (used in English since the 14th century), shorter than "he or she," and inclusive of non-binary users. For direct address, prefer "you" -- "Your dashboard" is always better than "The user's dashboard."
Avoid ability-based metaphors in UI actions. Standard UI verbs assume visual and physical ability: "see," "look at," "click," "drag," "watch." Replace them with ability-neutral alternatives that describe the cognitive action, not the physical one. "Check your settings" not "See your settings." "Select an option" not "Click an option." "Review the document" not "Look at the document." "Move the item" not "Drag the item." These alternatives work for screen reader users, keyboard-only users, and users with motor disabilities. They also happen to be more precise -- "review" implies cognitive evaluation, while "look at" only implies visual contact.
| Ability-specific (avoid) | Ability-neutral (prefer) |
|---|---|
| See the results | View the results |
| Look at the preview | Review the preview |
| Click the button | Select the button |
| Watch the video | Play the video |
| Hear the alert | Receive the alert |
| Walk through the steps | Follow the steps |
| Hands-on tutorial | Interactive tutorial |
Replace gendered defaults with neutral alternatives. Language that assumes a default gender excludes people and reinforces stereotypes. Maintain a substitution list and apply it consistently:
| Gendered (avoid) | Neutral (prefer) |
|---|---|
| mankind | humanity, people |
| man-hours | person-hours, work hours |
| manpower | workforce, staffing |
| manned | staffed, operated |
| guys (as address) | everyone, team, folks |
| salesman | salesperson, sales rep |
| chairman | chairperson, chair |
| master/slave | primary/replica |
| blacklist/whitelist | blocklist/allowlist |
| grandfathered | legacy, exempt |
GitHub renamed its default branch from "master" to "main" in 2020. The change was technically trivial (a configuration default) but symbolically significant -- it demonstrated that inclusive language in technical systems is achievable without disruption.
Avoid idioms that assume cultural context. English-language idioms often assume familiarity with American culture, sports, or history. "Hit a home run" means nothing to a user in Germany. "Level the playing field" assumes knowledge of sports metaphors. "Grandfather clause" has roots in post-Civil War voter suppression. Replace idioms with direct language:
| Idiom (culturally bound) | Direct alternative |
|---|---|
| Hit a home run | Succeeded, achieved the goal |
| Move the needle | Made measurable progress |
| Low-hanging fruit | Easy wins, quick tasks |
| Drinking from a firehose | Overwhelming amount of info |
| Boil the ocean | Take on too much at once |
| Circle back | Return to this topic |
| Open the kimono | Share information |
| Sanity check | Quick review, confidence check |
Direct language is not only more inclusive -- it is more precise. "Quick review" is clearer than "sanity check" for any audience.
Use person-first or identity-first language based on community preference. Different disability communities have different preferences. The Deaf community generally prefers identity-first ("deaf person"), while many other disability communities prefer person-first ("person with a disability"). When in doubt, use person-first language. In UI text, the best approach is often to focus on the situation, not the person: "If you use a screen reader" rather than "If you are a visually impaired person." This focuses on the tool and the experience, not the medical condition.
Design inclusive forms. Forms are where inclusive language is most critical because they ask users to categorize themselves. Principles for inclusive forms:
Avoid violent metaphors in technical contexts. Technical jargon often borrows from violent language: "kill the process," "terminate the connection," "abort the operation," "nuke the cache." In user-facing text, replace these with neutral alternatives: "end" or "stop" for "kill," "close" for "terminate," "cancel" for "abort," "clear" for "nuke." The violent metaphors are unnecessary -- the neutral alternatives are equally clear and do not carry the aggressive connotation. Apple's Human Interface Guidelines explicitly prohibit violent language in user-facing text.
When reviewing existing UI text for inclusivity, check each item:
The hierarchy of pronoun preference for UI text:
When writing UI text related to accessibility features:
The principle: accessibility features should be labeled by what they do, not by who needs them. This is both more inclusive and more useful -- sighted users also use keyboard shortcuts, and users without vestibular disorders may prefer reduced motion.
The Gendered Default. Using "he" or "his" as the default pronoun for unknown users. "When the admin reviews the request, he can approve or deny it." This pattern was once standard in English but is now recognized as exclusionary. It signals to non-male users that they are not the expected audience. The fix is simple and mechanical: replace "he" with "they" or restructure to use "you." "When you review the request, you can approve or deny it."
The Ableist Metaphor. Using disability as a negative metaphor. "The interface is crippled without JavaScript." "That feature is lame." "Are you blind? The button is right there." These metaphors equate disability with failure, inadequacy, or incompetence. They are harmful to disabled users and imprecise for all users. The fix: describe the actual problem. "The interface has limited functionality without JavaScript." "That feature is ineffective." "The button is in the top-right corner."
The Cultural Assumption. UI text that assumes all users share the same cultural references, holidays, seasonal context, or social norms. A "Happy Thanksgiving!" banner shown to users in Japan. A "Summer sale!" notification sent to users in the Southern Hemisphere where it is winter. Instructions that say "Call us during business hours" without specifying the timezone. Date formats that use MM/DD/YYYY (American) without considering that most of the world uses DD/MM/YYYY. The fix: design for the global user. Use ISO date formats or let users set their locale. Reference holidays only when the product is locale-specific. Always specify timezones.
The Tokenistic Inclusion. Adding a single diverse emoji or stock photo to a product that otherwise uses exclusionary language throughout. Surface-level representation without substantive language changes is performative and can feel worse than no attempt at all -- it signals awareness without action. The fix: inclusive language is a systematic practice, not a decoration. Start with the language and terminology. Audit the entire product, not just the homepage.
Microsoft's Inclusive Writing Guide. Microsoft published a comprehensive bias-free writing guide that their content teams use across all products. Key decisions: "they" as default singular pronoun, "select" instead of "click" (because touch and voice users do not click), "allowlist/blocklist" instead of "whitelist/blacklist," and person-first language for disability references. The guide includes specific examples for over 50 common patterns and is publicly available for other teams to reference. Microsoft's approach treats inclusive language as a content standard, not a suggestion -- it is enforced in code review the same way coding standards are.
GitHub's "main" Branch Rename. In 2020, GitHub changed the default branch name from "master" to "main." The technical change was minimal -- one configuration default. The cultural impact was significant: it demonstrated that inclusive language changes in technical systems are feasible, low-cost, and symbolic of broader commitments. GitHub published a migration guide, provided tooling to update existing repositories, and set a timeline for the transition. The rename is now an industry-standard default adopted by GitLab, Bitbucket, and most open-source projects.
Slack's Inclusive Emoji and Language Patterns. Slack supports diverse skin tone emoji, pronoun display in profiles, and uses inclusive language throughout its UI. Notification settings say "when someone mentions you" (gender-neutral). The team directory shows pronouns when users choose to display them, without making pronouns mandatory. Empty states say "No messages from anyone yet" rather than assuming a gendered pronoun for the hypothetical message sender. Slack's approach demonstrates that inclusive language can be systematic without being intrusive -- the changes are subtle, consistent, and respect user choice.
Apple's Human Interface Guidelines on Inclusion. Apple's HIG dedicates a section to inclusive language with specific guidance: use "select" instead of "click" to accommodate touch, voice, and switch control users. Use "turn on" and "turn off" instead of "enable" and "disable" (which carry ability connotations). Refer to people, not users -- "people who use your app" rather than "your users." Apple's guidelines treat inclusive language as a design requirement, not optional polish, and enforce it across all first-party apps as part of their App Review process.