Inclusive language
Learn how to create inclusive content and app experiences using inclusive design principles and techniques.Design principles for inclusive language
Inclusive language isn’t about following a list of good and bad words. It’s about taking an approach that avoids assumptions and stereotypes, and treats people with respect.
Make content easy to understand
Use plain language. Simple wording is more inclusive and helps people complete their tasks faster and with higher success rates.
Don’t use metaphors, idioms, or jargon.
Use person-first language when you can’t ask
When you can’t ask someone their preference, use person-first language. It centers around the person, rather than their difference. For example: ‘people with disabilities’ rather than ‘disabled people’.
However, some people prefer to use identity-first language to represent themselves, such as many people in the Deaf community, so it’s best to ask whenever possible.
Don’t make assumptions about abilities
Don’t use phrasing that makes assumptions about how people experience your app.
For example, by making claims about how easy an experience is, it’s less precise and can exclude people based on their abilities.
Do
Set up your new project in a few steps.
Don’t
It’s easy to set up a new project.
Avoid metaphors and idioms
Metaphors and idioms are non-literal phrases used in regular speech.
- Metaphors are when people compare something to something else (such as ‘they were like a fish out of water’)
- Idioms are phrases where the meaning isn’t conveyed by any of the words (such as ‘between a rock and a hard place’).
They can be confusing for our global audience, hard to accurately translate, and create an unnecessary barrier to comprehension. All this can be avoided by being accurate and literal.
Do
Automation helps teams create work items faster.
Don’t
Automation makes creating work items a piece of cake.
Do
Confluence has many useful features.
Don’t
Confluence has more features than you can poke a stick at.
How to describe people
Be clear
When you need to describe a group of people, use clear language that aligns with how people describe themselves, such as whether they use person-first or identity-first language.
You can also reduce inaccurate assumptions or stereotypes by improving the way you describe people’s differences. For example:
| Good | Better | Reason |
|---|---|---|
| Alternative text helps people with visual disabilities interact with images. | Alternative text helps people who use assistive technology interact with images. | Not all people who use assistive technologies like screen readers have visual disabilities. Using the ‘better’ definition is more inclusive and more accurate. |
| This project was done in consultation with people of Indigenous backgrounds. | This project was done in consultation with First Nations Australians. | Use specific terms when referring to racial and ethnic groups. Vague terms don't acknowledge the different experiences of racial and ethnic communities. |
Don’t change words used to describe people
Avoiding describing people’s differences can reinforce the prejudices of society.
Describing race, ethnicity, disability, age, class, gender, and sexuality isn’t a negative thing, unless these descriptions are being used in discriminatory ways. For example, it can be ok to use the phrase ‘people of color’ if you don’t have enough information to be more specific.
Don’t modify phrases to make differences sound positive. Words like ‘differently abled’ or ‘handi-capable’ are patronizing and don’t fit with the diversity of human experiences.
Designers avoid some words related to disabilities because they’re trying to be inclusive. Some words like ‘watch’ and ‘see’ aren't microaggressions because words that relate to disabilities aren’t negative words.
You should avoid using them in a negative context, but you can use them if they help make things clear.
| Words | Reason |
|---|---|
| View, watch, see | People who are blind or have low vision aren’t excluded by these words. They still ‘view’ a list of items, only in a different way. Where it makes sense, avoid these words. But you don’t need to remove them if they’re accurate. |
| Enabled, disabled | ‘Disabled’ isn't an offensive word. It reflects when people are limited by their environment and society. Avoid associating the word disabled with negative states. Wherever you can, alternatives to ‘disabled’ like ‘turned off’ or ‘unavailable’ are better. |
Techniques for inclusive experiences
Use they/them pronouns and gender-neutral language
- When referring to a person, use the pronouns they tell you to use.
- If you don’t know the person or group of people, use they/them pronouns. This makes our apps more gender inclusive and easier to read.
Do
Ask your project admin to enable editing permissions on their account.
Don’t
Ask your project admin to enable editing permissions on his or her account.
Make alt text concise and consistent
- If images provide information, always include alternative text (‘alt text’) so people using assistive technologies can access it.
- When you’re writing alternative text, consider how it will change the experience for a person using a screen reader. Is it accurate? Is it too wordy? Is it informative enough?
- If you’re using the same visuals in multiple places, use the same alt text every time it appears. And if elements are repetitive, like iconography, be concise so the experience isn’t annoying for people using assistive technology.
Write accurate content, links, and labels
Use accurate, descriptive language for content and links, as it reduces cognitive load and improves the experience for people who don’t use assistive technology.
Don’t deliberately keep visual labels short and hide the descriptive information behind an aria-label.
| Example | Alternative | Reason |
|---|---|---|
| Ask Rovo about a topic within your company’s knowledge base. Learn more. | Ask Rovo about a topic within your company’s knowledge base. About Rovo. | Accurate, descriptive links reduce people’s cognitive load. |
| Atlassian Intelligence is great for speeding up your work and improving productivity. | Use Atlassian Intelligence to find answers, get summaries, and generate content. | Don’t use vague promotional language. Describing new features with accuracy builds trust and helps people make informed decisions. |
| Step 1 | Create project (step 1 of 3) | Describe tasks accurately so people know where they are in their workflow. |
Gather form information thoughtfully
- When gathering data about people, avoid pre-defined categories. They often don’t reflect the diversity of our world and can prevent people from using software if there isn’t an option for them.
- Don’t ask for more information than necessary. Detailed personal information often isn’t relevant to our apps, so ask how or if you really need people to identify or group themselves before building this into a form.
- If you need to collect information about people’s identities, give them the option to not answer or to give a self-defined answer.
- Avoid setting any particular group of people as the default option. This implies that other groups are not the norm or not common, or forces some people to navigate and configure fields more than others.
- When gathering information about names, use a ‘Full name’ field instead of separating names by first name, last name, and salutation.
Additional resources
Language is changing all the time, so we don’t maintain a list of terms to use or avoid. Instead, use resources like: