Content section

packages/website/docs/content/accessibility.mdx

@@ -0,0 +1,84 @@
+---
+id: content_accessibility
+slug: content-accessibility
+---
+
+# Accessibility 
+
+This page shares common tips and tricks for writing accessible UI copy. It is not exhaustive and does not replace the official
+[WCAG 2.0 guidelines](https://www.w3.org/TR/2008/REC-WCAG20-20081211/#guidelines). 
+
+
+Writing accessible UI copy is only one part of improving web accessibility. Check the [EUI documentation](https://eui.elastic.co/#/guidelines/accessibility) for more accessibility guidelines.
+
+
+## What is accessible content and why does it matter
+
+**Accessibility** for content means making sure that the content can be consumed properly, independently of how users choose or have to interact with it.
+
+Our users and readers are diverse, with different abilities, and disabilities. 
+They also interact with our content in different ways: screen readers, mobile devices, Braille, and so on. The list is long, and always evolving. 
+
+As content authors, it is our responsibility to provide them with [perceivable, operable, understandable, and robust content](https://www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head).
+
+## Guidelines
+
+✔️ **Make your content scannable.** A clear structure and meaningful words tell users if the feature or flow is relevant to them within seconds. 
+
+✔️ **Add alt text for all images, icons and media files.** Screen readers, Braille output devices, and search engines love concise, accurate alt text that describe what cannot always be displayed, viewed or heard on screen. 
+
+
+| Inaccessible                 |  | Accessible               |
+| --------------------- | --- | ------------------------- |
+| Image of in progress rule creation form. | → | User is setting up a new threshold rule. |
+| Logs integrations | → | Integrations that let you to ingest logs. |
+
+
+✔️ **Use plain language.** Clear, concise UI copy helps users perform tasks. Jargon and complex sentences can confuse or slow them down. Helpful and detailed plain language guidance can be found on the [plainlanguage.gov](https://www.plainlanguage.gov/guidelines/) website.
+
+
+| Inaccessible                 |  | Accessible               |
+| --------------------- | --- | ------------------------- |
+| Update the sourcerer selection to be the default detections data view. | → | Choose the default Security data view. |
+| **Cancel update rule?** You will lose changes to the rule. | → | **Discard rule changes?** Select **Discard** to reject these changes. |
+
+
+✔️ **Use meaningful link text.** Descriptive text instead of "click here" or "read more" helps users understand what to expect when they open the link. Screen readers jump between links by generating a list of them, and spell out URLs.
+
+
+| Inaccessible                 |  | Accessible               |
+| --------------------- | --- | ------------------------- |
+| Click here for more information. | → | Learn more about indices. |
+| Create a query. Learn more. | → | Learn how to create an ES\|QL query. |
+
+
+✔️ **Use device agnostic language.** Users can access content and products in many ways. We do not know if they use a mouse, a keyboard, a tablet, and so on. 
+
+
+| Inaccessible                 |  | Accessible               |
+| --------------------- | --- | ------------------------- |
+| Type in your username and password. | → | Enter your username and password. |
+| Select a time range for the Alerts table. | → | Choose a time range for the Alerts table. |
+
+
+✔️ **Avoid directional language.** Do not use above, below, left, right, and so on. All these terms assume that UI layouts never vary, that users can actually see the UI, and that they see it the way you think they do. Users might have disabilities or impairments that affect how they understand the UI.
+
+
+| Inaccessible                 |  | Accessible               |
+| --------------------- | --- | ------------------------- |
+| Complete the form below. | → | Complete the following form. |
+| Import values from a file by clicking the **Import values** button under the table. | → | Select **Import file** to import values from supported file types. |
+
+
+## Words to avoid
+
+Avoid the following words. Use the suggestions instead.
+
+| Avoid                 |  | Use instead               |
+| --------------------- | --- | ------------------------- |
+| Click, tap            | → | Select, choose            |
+| Above, over           | → | Preceding, previous       |
+| Below, under          | → | Following, further, later |
+| See                   | → | Check, refer to           |
+| Hear (hear about...)  | → | Learn                     |
+| Type                  | → | Enter                     |

packages/website/docs/content/adapt-tone.mdx

@@ -0,0 +1,183 @@
+---
+id: content_tone
+slug: content-tone
+sidebar_position: 20
+---
+
+# Tones
+
+Adapt the way you write to each situation users can face. 
+
+ Our products and solutions are very technical, data-oriented, and they're used globally by people from different cultures, abilities, and personalities. 
+ These considerations, amongst others, limit the spectrum of tones we use to some extent, but not entirely. 
+
+ During the users' journey with Elastic, there are times for excitement and discovery, but also times for help, support, and empathy.
+
+
+ ## Stimulating
+
+**Attributes**
+
+    We're proud to show new and cool stuff. Be:
+
+    - Motivational
+    - Excited
+    - Enthusiastic
+
+    When using this tone, you may:
+    - Use exclamation marks, but sparingly.
+    - Take time to help the user understand how this feature benefits them.
+    - Use visuals to support your text.
+
+**Cases**
+
+    Although it can be very visible because of the way it's written and the UI elements it shows in, the **stimulating** tone is used **quite rarely** overall. 
+
+    We use it when we want to show new things to users, especially in:
+
+    - Product tours
+    - New feature announcements
+
+## Friendly
+
+**Attributes**
+
+    All's fine, we'll help you find your way. Be:
+
+    - Calm
+    - Positive
+    - Confident
+
+    When using this tone, you may:
+    - Use more casual terminology.
+    - Explain what's missing or what's happening.
+    - Provide actions or clearly state when there's no action needed.
+
+
+**Cases**
+
+    The **friendly** tone is used **sparingly** overall and usually blends in the UI at different moments of the users' journey. 
+
+    We use it when orienting users in doing their next action or learning different things they could do, especially in:
+
+    **UI**
+    - Empty states (no item created or no matching results)
+    - Loading and waiting states
+    - Tips
+    - Success messages
+    - Welcome emails (signup & trial)
+
+    **Documentation**
+    - Quick starts
+    - Tutorials
+
+## Informational
+
+**Attributes**
+
+    E=MC². Be:
+
+    - Direct
+    - Straight to the point
+    - Neutral
+
+    When using this tone:
+    - Use a minimum of words.
+    - Write for scanning and help users quickly locate what matters to them.
+    - Use action verbs to: 
+        - Label selection controls.
+        - Describe what settings do or what to do with a setting.
+    - Use clear nouns for
+        - menus, form field names 
+
+
+**Cases**
+
+    The **informational** tone is the **most used** one. It is everywhere in the UI, and sometimes seems so normal that we forget about it. Yet, it is very important! 
+
+    We use it for naming and describing things:
+
+    - Menus, titles, setting names, hint text, placeholders, introductions, and descriptions
+    - In-product assistance (tooltips, help popovers, guided setups)
+    - Information callouts
+    - Confirmation modals
+    - Calls to action (buttons and links)
+    - Event logs
+
+    **Documentation**
+    - Reference content
+    - Concepts
+    - How-tos
+    - Troubleshooting
+
+## Empathetic
+
+**Attributes**
+
+    Something might be wrong and requires attention. Let us help you. Be:
+
+    - Reassuring
+    - Professional
+    - Precise
+
+    When using this tone, you may:
+    - Be more action-oriented than usual to offer direct paths to users.
+
+
+**Cases**
+
+    The **empathetic** tone is used **sparingly** overall and is usually shown in places that draw the user's attention. 
+
+    We use it when notifying users of things that are not immediately critical but still require attention, especially in:
+
+    - Warnings and cautions
+    - Upgrade and deprecation notices
+
+## Supportive
+
+**Attributes**
+
+    Something is definitely wrong. Here's why, and how to fix it. Be:
+
+    - Serious
+    - Concerned
+    - Urgent
+
+    When using this tone, you may:
+    - Focus on what went wrong. Don't be apologetic.
+    - Help users learn how something happened, how to prevent it, how to fix it.
+    - Provide clear actions, or clearly state it if there's no action needed.
+
+
+
+**Cases**
+
+    The **supportive** tone is used **sparingly**. It usually becomes visible in forms that draw the user's attention, for example, through callouts or notifications. 
+
+    We use it when the immediate attention of the user is required, especially in:
+
+    - Errors
+    - Licensing or billing-related content
+    - Vulnerability and remediation content
+
+## Stern
+
+**Attributes**
+
+    We don't advise this action, but you're the master of your destiny. Be:
+
+    - Deterring
+    - Heavy with caution
+    - Advisory
+
+    When using this tone, you may:
+    - Use stronger words that highlight possible negative effects.
+    - Format the content in a way that make the risks stand out.
+
+**Cases**
+
+    The **stern** tone is **rarely** used. Reserve it for very specific cases, and for advanced or administrative features.
+
+    We use it when insisting on the high risks an action could pose, especially in:
+
+    - Danger type of warnings

packages/website/docs/content/inclusivity.mdx

@@ -0,0 +1,106 @@
+---
+id: content_inclusivity
+slug: content-inclusivity
+---
+
+# Inclusivity
+
+This page provides guidelines for writing inclusive UI copy for product content but it's not exhaustive.
+
+## What is inclusive content and why does it matter
+
+**Inclusivity** for content means making sure that the content we serve reflects the diversity of our community, respects it, and promotes positive change. 
+
+
+## Guidelines
+
+### Write for an international audience
+
+Our products use American English (en_US) as a standard for written content. 
+Yet they are used, read by persons all around the globe, for whom English is not always their primary language.
+Our content must take that into account.
+
+✔️ **Aim for simplicity.** Indeed, we are a technical company, writing for 
+  technically-savvy users. However, it benefits everyone if we try to keep our writing as simple as possible.
+
+  * **Short sentences** - They leave less space for interpretation. They are easier to scan, read, and translate.
+
+  * **Plain language** -  Use active voice, present tense, using examples, and so on. 
+  Some of these guidelines might already look familiar. Several countries have 
+  [plain language initiatives](https://www.plainlanguage.gov/guidelines/) to 
+  promote clearer communication. Do your 
+  best to embrace these guidelines and focus on the message.
+
+  * **Negation** - It is easier to say what something IS 
+  versus what it is NOT. When you add a negative construction, it takes the 
+  reader longer to parse the meaning of the phrase. For example, instead of saying "You cannot access the content without signing up", say "Sign up to access the content." 
+
+  * **Words with multiple meanings** - 
+  Don't skip helper words if they make the sentence clearer and easier to read. In UI copy, we try to be as literal and unambiguous as possible to ensure that it can be easily consumed by our users from around the globe. One way to achieve that is to choose words that have fewer meanings, especially when a word's intended meaning is not its primary meaning.
+
+✔️ **Be aware of differences and diversity in content and examples.** 
+Different people are used to different names, currencies, date and time formats, different units of measurement (like for temperature, distance, speed), and so much more. 
+* Avoid ambiguous values, like `04/05/06` for a date. Is it May 4 or April 5, and which year? `11/17/1987` leaves less room for interpretation if the exact format is not specified nearby. 
+* If there is no obvious example standard (RFC) to follow, try to be diverse to represent our audience.
+
+✔️ **Avoid idioms or expressions that are not commonly known, a.k.a regionalisms.** 
+
+In our Elastic documentation we aim for a fun, friendly, and sometimes quirky 
+tone. To achieve that, it can help to use informal, playful language. However, we also have to be careful that our text is as inclusive as possible, so we try to avoid expressions that might be unknown or opaque for some users. Here are a few examples of what to avoid:
+
+* Idioms (for example, _It's a piece of cake_ or _So far so good_)
+* Regional expressions (for example, _G'day!_, _Y'all_, or _eh_)
+* Sports expressions (for example, _touched base_ or _threw a curve ball_)
+* Pop culture references (for example, _Elvis has left the building_ or _Same bat-time, same bat-channel_)
+
+We're all pretty good at avoiding these, but there's one problematic type of 
+expression that sometimes shows up in UI copy. Latin terms and 
+abbreviations are a common source of confusion, particularly for people whose 
+first language does not have Latin roots.
+
+Here are some terms to avoid and suggested alternatives:
+
+| Avoid      |  | Use instead     |
+--- | --- | ---
+| _e.g._ (exempli gratia) | → | _for example_ | 
+| _etc._ (et cetera) | → | _and more_ or _and so on_ |
+| _i.e._ (id est) | → | _that is_ |
+| _via_ | → | _by way of_, _by means of_, or _through_ |
+
+✔️ **Aim for readability.** Tools like the [Hemingway App](https://hemingwayapp.com/) can help you make content simpler. Be conversational, but prioritize clarity.
+
+### Use gender-neutral language
+
+Writing gender-neutral mainly consists in avoiding gender bias and word choices implying that one gender is the norm.
+
+✔️ **Pronouns.** In the UI, this can be avoided by addressing users directly.
+When it's not possible, use *they*/*their*, even for singular. There's more than one gender, and it's not binary either.
+
+✔️ **Biased words and expressions.** Guys, mankind, policeman... Words that we're all used to hear and use. But the default is not male. 
+Most expressions and words that perpetuate this bias (that exists in many cultures and languages!) can be replaced with neutral alternatives or synonyms: Folks, humanity, police officer...
+
+### Avoid violent, offensive, ableist terminology
+
+Earlier in this page, we discussed avoiding ambiguous terms, especially when a word's intended meaning is 
+not its primary meaning. Other types of words and phrases best avoided are:
+
+* buzzwords (_incentivize_, _synergies_)
+* superhero terms (_rockstar_, _wizard_, _ninja_)
+* violent imagery (_crush the competition_)
+* non-specific superlatives (_unrivaled_, _unparalleled_, _world class_)
+
+Some words have nuances that fall into the above categories, which may cause 
+them to be misinterpreted. Here are some alternatives:
+
+| Avoid      |      | Use instead   |
+--- | --- | ---
+| Abort	     | → | _stop_, _cancel_, or _end_ |
+| Boot 	     | → | _start_ or _run_ |
+| Execute     | → | _run_ or _complete_ |
+| Hack (noun) | → | _tip_ or _workaround_ |
+| Hack (verb) | → | _configure_ or _modify_ |
+| Hit (verb)  | → | _click_ or _press_ |
+| Hit (noun)  | → | _visits_ (as in _website visits_) |
+| Invalid     | → | _not valid_ or _incorrect_ |
+| Kill		  | → | _cancel_ or _stop_ |
+| Terminate	  | → | _stop_ or _exit_ |