Write in plain and inclusive language

Complex sentences and long paragraphs can be daunting for some users, such as those with reading disabilities or low vision, or for those who use translation tools. In addition, biased language can deter users from reading the documentation and using Splunk products. Plain language ensures that all users can process text more quickly. Inclusive language ensures your documentation is fair, neutral in tone, and welcoming to all communities.

Follow these guidelines to write approachable and accessible documentation:

• Write in plain language, using simple sentence construction and short paragraphs.
• Write using inclusive language by choosing alternatives for biased terminology and by aligning with disability communities on language preferences. See Write unbiased documentation.
• Avoid using complex words, such as jargon or complicated terminology. When you need to use terminology, use it consistently. See Use plain language.
• Avoid writing tasks in paragraph form. Instead, use lists to organize tasks. See Using lists with accessibility.

Create descriptive headings

Descriptive titles and headings are crucial to helping users find the information they need. For example, many screen reader users tab through headings first to figure out where they need to go. Users with reading disabilities find sections organized by headings easier to parse than long sections with fewer headings. With descriptive and organized headings, all users can orient themselves and navigate through your documentation.

Follow these guidelines when using headings in your documentation:

• Use headings to break up long paragraphs and help screen reader users navigate through the topic.
• Organize your content by dividing topics into clear, logically ordered sections and subsections. If your topic requires more than 2 levels of sectioning, consider splitting it into multiple topics to keep information focused and easy to navigate.
• Always maintain a logical structure when nesting sections. Avoid skipping section levels to ensure consistent navigation and accessibility for all users.

For more guidance on headings, see Naming conventions for topics and sections.

Avoid directional language

Language that relies only on direction doesn't help users with visual disabilities or those who use screen readers. Aim to remove this language from your documentation, and add language that isn't dependent on spatial cues to help the user figure out where to go.

When directing users to a location in your topic, avoid using directional language like "above", "below", "left", or "right". Instead, describe the page element based on temporal relationships, such as whether it comes before or after the current sentence.

If you can't provide the information the user needs in the current paragraph, include a descriptive link to the location. If you are referring to the next paragraph or section or to the preceding paragraph or section, it's okay to use "following", "next", or "previous" without a link.

Review the following table for examples of how to reference different locations within a topic:

Temporal relationship	Word options	Do this	Don't do this
Before the current sentence	Earlier, previous	For more information, see the Write in plain and inclusive langauge section earlier in this topic.	For more information, see the Write in plain and inclusive language section above.
Following directly after the sentence	Following, next	The following table shows examples of inputs.	The table below shows examples of inputs.
Further in the topic	Later	For more information, see the Combine color with other elements section later in this topic.	See below for information on color.

If you must guide users through the UI, refer to UI elements using their labels whenever possible. Avoid relying on directional language as the only means to guide users to a location. Typically, directional language isn't needed to guide users through a task, but it's okay to include directional language in your instructions if the user might have trouble finding a location in the UI solely by the label.

Review the following table for examples of guiding users through the UI:

Do this	Don't do this
Select a value from the Zone drop-down list in the top-right corner.	Select a value from the drop-down list in the top-right corner.
Select an asset you want to configure from the Actions panel on the left.	Select an asset you want to configure from the upper-left panel.

Combine color with other elements

Color can often be a helpful indicator for sighted readers. However, users who are color blind or use screen readers might not be able to recognize color when it's used as the only identifying element. When referring to color, include other identifiers to help all readers find what you're describing.

Review the following table for examples of ways you can combine color with other identifying elements:

Do this	Don't do this
Select the red alert with high severity.	Select the red alert.
The tallest points on the time-series chart, indicated by yellow circles, are the outliers.	Outliers on the time-series chart are yellow.

When creating diagrams or images that have color, use a combination of colors, shapes, patterns, explanatory text, and labels instead of color alone. See Using images with accessibility.

Lead into new page elements

Page elements include tables, lists, images, videos, searches, commands, and code blocks. Always introduce a new page element using a complete lead-in sentence that explains what information the element contains or what the user needs to do. A lead-in sentence prepares users with what to expect from the upcoming page element.

Spell out words and symbols

Screen readers don't always refer to symbols using terms that fit the context of the sentence, so it's important to define symbols carefully in writing. Avoid unnecessary abbreviations or acronyms, especially those that don't closely match the words they refer to.

For clarity, use words instead of substituting them with symbols. If you must use a symbol as a noun in your sentence, spell it out first and then include it in parentheses with nonbreaking spaces. See Show symbols in text for more information guidance, examples, and what to call symbols.

Rather than using the right-pointing angle bracket to describe menu paths, use an appropriate semantic tag like menucascade or an equivalent word like "then". See Brackets.

Review the following table for examples of writing out text equivalents instead of relying on symbols:

Do this	Don't do this
Apps and add-ons	Apps & add-ons
Begin your time offset with a plus ( + ) or minus ( - ) to indicate the offset from the current time.	Begin your time offset with +/- to indicate the offset from the current time.
It can take about 5 minutes for your host to display in the user interface.	It can take ~5 minutes for your host to display in the user interface.
In Splunk Web, select Settings, then Advanced Search. In Splunk Web, select Settings > Advanced Search.	In Splunk Web, select Settings > Advanced Search.

If you're writing UI text and you don't have space to write out the name of the symbol, use hidden text such as the aria-label attribute to define the symbol. For more guidance, see Abbreviations.

Be precise

When using pronouns that point back to or substitute for a noun, consider whether it's clear what the noun is that the pronoun refers to. If the referent is unclear, too broad, or located far from the pronoun, the sentence can be vague or difficult to parse for users with reading disabilities.

Follow these guidelines when writing for precision:

• Avoid capturing vague or broad ideas using pronouns like "this" or "these" without additional clarification.
• Make sure that relative pronouns, like "who", "which", and "that", modify the nearest noun.
• If a pronoun can have multiple possible referents in a sentence, always specify that referent in your writing. See Pronouns for more information.

Review the following table for examples of precise and vague sentences:

Do this	Don't do this
The job eventually expires after the search object is removed from the queue.	This eventually leads to the job expiring.
This algorithm functions like an online shopping algorithm, which suggests related items based on what items other customers viewed or purchased.	This is similar to the algorithms used for online shopping websites, which suggest related items based on what items other customers viewed or purchased.