@atlaskit/ads-mcp 0.17.0 → 0.17.2

package/dist/cjs/tools/get-guidelines/guidelines-structured-content.codegen.js

@@ -9,12 +9,33 @@ exports.guidelinesStructuredContent = void 0;
  *
  * Structured content for content guidelines from design-system-docs foundations content.
  *
- * @codegen <<SignedSource::4f7efe5f3afd0bc4b8832adf32e729d9>>
+ * @codegen <<SignedSource::50b9bf501530f3bf94e6e4dece48d956>>
  * @codegenCommand yarn build structured-docs
  */
 
 var guidelinesStructuredContent = exports.guidelinesStructuredContent = [{
-  content: '## A note for Content Designers\n\nWhen you’re working with engineers, all they need is the time and date format length, and the i18n\nlibrary API will format the date accordingly based on the locale signals Atlassian provides.\n\nEach programming language has an i18n library that automatically localizes time and date strings\nbased on a user’s locale settings/preferences. Date and time formatters are used to convert dates\nand times from their internal representations to textual form and back again in a\nlanguage-independent manner.\n\nTime and date strings should never be localized manually by a translator as time and date strings\nshould be tied to a user’s locale (country and language) not their language. Hardcoding time and\ndate content is bad practice and creates a bad international customer experience.\n\n## Abbreviating days and months\n\nUse abbreviations when space is limited. Be clear about which months or days you are referring to.\n\nUse these abbreviations for the days of the week:\n\n- Monday – Mon\n- Tuesday – Tue\n- Wednesday – Wed\n- Thursday – Thu\n- Friday – Fri\n- Saturday – Sat\n- Sunday – Sun\n\nUse these abbreviations for the months:\n\n- January – Jan\n- February – Feb\n- March – Mar\n- April – Apr\n- May – leave it as May\n- June – Jun\n- July – Jul\n- August – Aug\n- September – Sep\n- October – Oct\n- November – Nov\n- December – Dec\n\n<DoDont type="do">Be consistent when using abbreviations</DoDont>\n<DoDont type="dont">\n\tDon’t use the shortest form of days and months – F, M, N, etc. If there isn’t room to designate\n\tthe month, work on redesigning.\n</DoDont>\n\n## The date format in American English\n\nUsually, the month comes before the day, then followed by the year. On the 8th day of the month of\nJanuary, in the year 2020, then the date in American English can be written as:\n\n- Jan 8\n- January 8\n- January 8, 2020\n- Monday, January 8, 2020\n\nAtlassian uses American English when writing in English. The formats above are broken down below to\nhelp when writing absolute values are required. Choose patterns that are appropriate for your\ncontext.\n\n### Long date\n\nUse full date in cards, bylines, and anywhere else space or your design allows for it:\n\n- Use numerals for the day\n- Spell out the month and day of the week in words\n- Give the full four-digit year, not a two-digit abbreviation\n\nDon’t use ordinal numbers, for example, 1st, 2nd, 3rd, etc.\n\n<DoDont type="do">Tuesday, April 12, 1952</DoDont>\n<DoDont type="dont">Tuesday 12th April 1952</DoDont>\n\n### Medium date\n\nYou can also use a shorter format. Here spell out the month and use numerals for the day and year:\n\n<DoDont type="do">April 12, 1952</DoDont>\n\n### Short date\n\nWhen space is limited shorten dates further, for example in lists, tables, charts, and comments.\n\n- Spell out the month using abbreviations\n- Use numerals for the day and the year\n\nWe recommend using the following pattern in shorter spaces:\n\n<DoDont type="do">Sep 14, 2006</DoDont>\n\nWhen you need to leave out either the day or year, where possible, spell out the month in full.\n\n- October 22 or July 2019\n\n## Numerical dates\n\nWriting dates entirely in numbers has disadvantages when it comes to readability and usability. This\nis because parts of the world use the date in a different order for numeric dates. Avoid doing this\nif it\'s possible because it often also has large UX implications. Instead, we recommend using any of\nthe other date formats above.\n\nIf it’s absolutely necessary to express a date in numerical date format, use the format YYYY-MM-DD,\nand separate the elements by using hyphens. This conforms to\n[ISO 8601 international standards](https://wikipedia.org/wiki/ISO_8601) for numerical date format.\n\n- 2021-05-23\n\nIn a content draft or design spec if you’re adding a fictional date, choose a day greater than 12.\nThis will help to clearly differentiate the day from the month.\n\n## Grammar and punctuation\n\nPunctuation is a localization issue and should be localized wherever possible. Avoid if possible,\ndefaulting to no punctuation.\n\n### Hyphens\n\nWhen writing as numerals separate the numbers with an unspaced hyphen, using the format above.\n\n### Apostrophes\n\nAvoid using apostrophes. In more casual writing, you can use expressions such as ‘the seventies’ or\n\'the \'70s\' - using contractions for the missing numerals in the year.\n\n### Capital and lower case\n\nMonths and days are proper nouns and start with a capital letter. Specific days, times of the year\nor periods in history are all proper nouns. Use capitals for all proper nouns.\n\nUse initial capitals for all institutional holidays, religious days, and public events:\n\n- New Year’s Day\n- Good Friday\n- Ramadan\n- Yom Kippur\n\n## Using ‘to’ and ‘from’\n\nUse ‘to’ if a number range is preceded by ‘from’ in a phrase. Use ‘and’ if a range is preceded by\n‘between’. Avoid using hyphens and en dashes in spans of dates.\n\n<DoDont type="do">From 2015 to 2019</DoDont>\n<DoDont type="dont">2014 - 2015</DoDont>\n\nWhen this isn\'t possible, for example:\n\n- financial years\n- or when information is in parentheses, such as terms of office and years of birth and death.\n\nFor these, use a hyphen without any spaces on either side:\n\n- FY2008-09\n- John Smith (1917–1992) had 3 younger siblings.\n\n## Divisions of the year\n\nSpring in the northern hemisphere is autumn (fall) in the southern hemisphere. Avoid talking about\nseasons. Instead, use months or quarters.\n\n## Time\n\nIn most cases, especially when you need to be precise, use numbers to give a clearer expression of\ntime. Use a colon between the hours and minutes with no spaces on either side.\n\n<DoDont type="do">3:30:42 p.m. PST</DoDont>\n\nIf it’s an exact hour, no “:00″ is required. For timestamps, labels on graphs, durations, and more\navoid using zeros. Only show minutes if it’s not on the hour.\n\n<DoDont type="do">8 a.m.</DoDont>\n<DoDont type="dont">8:00am</DoDont>\n\n### Using ‘a.m.’ and ‘p.m.’\n\n<SectionMessage title="a.m/p.m clarification">\n<Stack space="space.100">\nUse the following date/time formatting guidelines when creating static content, like a blog, manuals, instructions, etc.\n\nKeep in mind that, for dynamic content, the design system components expect a locale value\nrepresenting the end users preferred date/time format from their profile or their system (e.g.\nbrowser), which could be different from the guidelines on this page.\n\n</Stack>\n</SectionMessage>\n\nAs with American English in most cases, we use rules set by the AP style guide.\n\n- Lowercase a.m. and p.m., with periods.\n- Use numerals, with a space between the time and the a.m. or p.m., for example, 6:30 a.m.\n- If a time range is entirely in the morning or evening, use a.m. or p.m. only once: “6:30-10 p.m.”\n  If it goes from the morning into the evening (or vice versa), you need both: “10 a.m.-2 p.m.”\n\n### Noon, midday, and midnight\n\nWhere possible use ‘noon’, ‘midday’ or ‘midnight’ instead of ‘12 a.m.’ or ‘12 p.m.’ to make it\neasier for people.\n\n### The 24-hour system\n\nUse the 24-hour system if it helps people understand your content. But it’s important to understand\nthat many times this is system-driven. This is important if you’re referring to time in the context\nof more serious communications, for example, in case of outages and in security comms.\n\nThe 24-hour system numbers hours from 00:00 hours (midnight) to 23:59 and always uses at least 4\ndigits. If seconds are included use 6 digits.\n\n- The first 2 digits are the hours\n- The next 2 digits are the minutes\n- The last 2 digits are the seconds\n\nUse a colon to separate the hours, minutes, and seconds.\n\n### Talking about time\n\nAvoid using the prefix ‘bi’ to mean either 2 or twice. It can be confusing.\n\n- ‘Bimonthly’ can mean either every 2 months or twice a month.\n- ‘Biannual’ means twice a year.\n\nInstead, use fortnightly or the phrase ‘every 2’.\n\n<DoDont type="do">Your x will repeat every 2 weeks</DoDont>\n<DoDont type="dont">Your x will repeat bi-monthly</DoDont>\n\n### Using date and time together\n\nThis is used when displaying both the date and the time of day. For example, in historical versions\nof pages. To do this use the following formats\n\n- MMM dd, yyyy HH:mm\n- dd, HH:mm\n\n### Relative date and time\n\nIt’s important that you express date and time information as you would speak in conversation when\nthe situation allows for it.\n\nIn some cases, the easiest way to describe something that happened very recently is using the ‘ago’\nformat. Use this when the exact date is less important. For future and past events, use approximate\ntime by rounding down to the largest or most recent date or time.\n\nYou should always provide a way for people to see the actual timestamp, usually via a tooltip.\n\n#### Past\n\n| Description                 | Display                      | Display when limited space     |\n| --------------------------- | ---------------------------- | ------------------------------ |\n| Within the last few seconds | just now                     | now                            |\n| Within the last minute      | a minute ago                 | 1 m                            |\n| Within 59 minutes           | x minutes ago                | X m                            |\n| 60 minutes ago              | 1 hour ago                   | 1 h                            |\n| x hours ago                 | x hours ago                  | X h                            |\n| 1 day ago                   | yesterday                    | 1 d                            |\n| 1 day ago (with time)       | yesterday at 5:05 pm         | n/a                            |\n| 2 days ago < 7 days         | x days ago                   | Use the truncated date (Aug 8) |\n| 7 days ago                  | 1 week ago                   | Use the truncated date (Aug 8) |\n| > 7 days ago                | Date stamp: "August 8, 2018" | Use the truncated date (Aug 8) |\n\n#### Future\n\n| Description                   | Display                      | Display when limited space     |\n| ----------------------------- | ---------------------------- | ------------------------------ |\n| Within the next few seconds   | shortly                      | now                            |\n| In the next minute            | In 1 minute                  | in 1 m                         |\n| In the next 60 minutes        | In x minutes                 | in X m                         |\n| In 60 minutes                 | In 1 hour                    | in 1 hr                        |\n| In x hours                    | In x hours                   | in X hr                        |\n| In 1 day (by date, not hours) | tomorrow                     | Use the truncated date (Aug 8) |\n| In 2 to 7 days                | In x days                    |                                |\n| In 7 days                     | In 1 week                    |                                |\n| In > 7 days                   | Date stamp: "August 8, 2018" |                                |\n| > 7 days ago                  | Date stamp: "August 8, 2018" |                                |\n\n## Writing for languages other than English and internationalization\n\nDate and time formatting differs greatly from country to country, and even within regions of a\ncountry, such as Canada and Switzerland.\n\nThe Product Internationalization team is responsible for creating app UI content in non-English\nlanguages by localizing externalized code strings provided by our Product Engineers.\n\nIn order to accurately localize date and time formatting for different locales (country and\nlanguage), we require Engineers to ensure that all content containing the date and time references\nare not hardcoded and reference built-in i18n libraries/APIs for automatic format\n\n### Best practice for Engineers\n\nThe best practice for Internationalization is for Engineers not to hardcode time and date strings\nand to reference the programming i18n library API which will automatically format time and date\nstrings as per the detected or selected locale.',
+  content: "## Building accessible apps\n\nAn accessible app means people of all abilities can interact with, understand, and navigate it.\n\nADS components ship with built-in accessibility features, such as keyboard support and sensible ARIA\nusage. However, you still need to review your patterns, content, and interactions so your app is\naccessible end-to-end.\n\n### Follow our accessibility principles\n\nOur principles cover the main requirements to design and build accessible experiences, helping you\nto put accessibility into action.\n\n#### Build consistent experiences\n\nThe user experience should be familiar, identifiable, and work as expected regardless of device,\nscreen size, platform, or assistive technology.\n\n- Use design system components as the basis of every experience. They have inbuilt accessibility\n  features and create consistency across apps.\n- Ensure the same components, patterns, and interactions are used for the same experiences across\n  pages and apps to lessen cognitive load.\n\n#### Keep experiences and language simple\n\nRespect people’s time by making apps that are uncomplicated and easy to use.\n\n- Avoid complex process and experiences.\n- Use similar patterns across apps and experiences.\n- Use concise and plain language.\n- Aim for content to be written at a reading level of ages 12 to 14.\n\n#### Be inclusive\n\nAccessible design is inclusive of people of all races, ethnicities, genders, sexual orientations,\nand backgrounds.\n\n- Use [inclusive language](https://atlassian.design/foundations/content/inclusive-writing).\n- Don’t make assumptions about people’s abilities.\n- Avoid jargon,\n  [metaphors, and non-literal phrases](https://atlassian.design/foundations/content/inclusive-writing#avoid-metaphors-and-idioms).\n\n#### Give people control\n\nPeople should be able to adapt our apps to suit their needs.\n\n- Enable [reflow](https://www.w3.org/WAI/WCAG21/Understanding/reflow.html) across all screen sizes.\n- Allow people to adjust scale, contrast, and colors.\n- Make sure personal reduced motion settings are respected by our apps.\n- Inform people about high-impact changes before you make them.\n\n#### Provide text alternatives\n\nText is powerful for assistive technologies, as it can be seen on a screen, heard using\ntext-to-speech, and touched with a braille screen reader.\n\n- Use visible and accessible labels.\n- Write clear and concise labels and\n  [alternative (alt) text](https://accessibility.huit.harvard.edu/describe-content-images).\n- Include a transcript for videos on the page or link to it.\n\n#### Ensure color is accessible\n\nSome people can’t perceive color, while others perceive limited color.\n\n- Never rely on color alone to convey meaning.\n- Use a color contrast ratio of 4.5:1 for regular text and 3:1 for large text and graphics.\n\n#### Use semantic HTML\n\n[Semantic HTML](https://www.w3schools.com/html/html5_semantic_elements.asp) describes the exact\nmeaning of an element to a web browser. It helps people using assistive technology navigate and\ninterpret page elements.\n\n- Use `header` , `nav`, `footer` (for example).\n- Don't use `div` or `span` (for example) as they don't convey meaning.\n\n#### Test apps broadly\n\nTest with different tools and a diverse array of people.\n\n- Test apps with people with disabilities and across different levels of technical experience.\n- Use different types of technology and accessibility tools, such as\n  [Accessibility Insights](https://accessibilityinsights.io), to test your app.\n\n## What to consider when building accessible apps\n\nEveryone will experience a disability at some point in their lives, whether it's a situational\nimpairment or a permanent or temporary disability. At these times, assistive technology can help\npeople use our apps — but only if they’re built to be accessible.\n\nConsider the following when designing and building your app. And remember: people are multi-faceted,\nso it's important not to solve for one disability in isolation.\n\n### Visual disabilities\n\n- Provide clear and informative alternative (alt) text and semantic HTML.\n- Don’t rely on color alone to convey meaning, and make sure color contrast is accessible.\n- Examples of visual disabilities include:\n  - Blind (permanent)\n  - Migraine (temporary)\n  - Lost glasses (situational)\n\n### Auditory disabilities\n\n- Include closed captions and transcripts for videos.\n- Make sure transcripts for audio are available.\n- Examples of auditory disabilities include:\n  - Deaf (permanent)\n  - Ear infection (temporary)\n  - On public transport (situational)\n\n### Limited mobility\n\n- Support keyboard navigation, large selectable targets, and correct semantic HTML.\n- Examples of limited mobility include:\n  - Cerebral palsy (permanent)\n  - Broken wrist (temporary)\n  - Crying baby (situational)\n\n### Cognitive disabilities\n\n- Use wording that’s clear and in plain language.\n- Break up big chunks of text using headings and subheadings, bullet points, and small paragraphs.\n- Design experiences that are easy to navigate.\n- Examples of cognitive disabilities include:\n  - Dyslexia (permanent)\n  - Anxiety (temporary)\n  - Busy office (situational)\n\n<SectionMessage title=\"Benefits of accessible apps\">\n\tWhen we consider accessibility and inclusion throughout every part of the design and development\n\tprocess, we create apps that benefit everyone on a team, reach more people, comply with\n\tlegislation, and keep us innovative.\n</SectionMessage>\n\n## Helpful tools (Atlassians only)\n\n<IconCardGroup data={contactUsCards} />",
+  keywords: ['accessibility', 'wcag', 'keyboard', 'aria', 'assistive technology', 'inclusive design', 'usability']
+}, {
+  content: '## About border tokens\n\nBorders define boundaries and add emphasis using a combination of width and color tokens. Width\ntokens control a border\'s prominence, while color tokens provide its meaning. Pair these tokens to\ncommunicate an element’s purpose, such as a simple divider, or a visible interactive state.\n\n## Border width tokens and usage guidelines\n\nUse border width tokens to provide a clear and intentional way to apply width across different\nstates and use cases.\n\n<Stack space="space.200">\n\t<BorderTable />\n\t<Text>* Token values are subject to change and should be used as an indication only.</Text>\n</Stack>\n\n### Default border width\n\nThe `border.width` token is the default value for all standard borders and dividers. It establishes\nthe baseline thickness for components that require a subtle, defining outline, ensuring they are\nvisually distinct.\n\n![](./_assets/border-width.png)\n\n### Selected states\n\nUse the `border.width.selected` token to show users which option they’ve selected from a group.\nApply this token to highlight a user\'s choice, such as an active tab or a chosen item in a list.\n\n![](./_assets/border-width-selected.png)\n\n### Focus ring\n\nUse the `border.width.focused` token to define the thickness of the focus ring. Apply this token to\nshow keyboard users where they are on the page. When users press Tab to move through an interface,\nthe token highlights the active element they can interact with. This helps make your interface\naccessible to everyone.\n\n![](./_assets/border-width-focused.png)\n\n## Border color and width pairing\n\nCreate borders by pairing width and color tokens. Choose:\n\n- width tokens to control how thick and visible your border appears\n- color tokens to show what the border means, like its state or importance\n\nAlways pair the right width token with the right color token to keep your interface consistent and\nclear for users.\n\n![](./_assets/border-width-color.png)\n\n### Visual indicator for selected state\n\nAlways pair the `border.width.selected` token with the `color.border.selected` token, to show users\nwhich items they’ve selected. Use this combination to consistently highlight selected elements, like\nan active tab or a chosen list item, throughout the interface.\n\n![](./_assets/border-width-selected-color.png)\n\n### Required pairing for focus state\n\nAlways pair the `border.width.focused` token with the `color.border.focused` token to define the\nthickness of the focus ring.\n\nUse this combination to consistently highlight elements that receive keyboard focus, so users always\nknow which element is active and ready for interaction.\n\nTo ensure consistency and accessibility when adding a focused state to your components, follow these\nstandards:\n\n- **Code:** Use the\n  [Focusable component](https://atlassian.design/components/primitives/focusable/examples) to wrap\n  all interactive elements requiring focus.\n- **Design:** Use the\n  [Focus Ring component (Atlassians only)](https://go.atlassian.com/focus-ring-component) from the\n  Atlassian Design System Figma library.\n\n![](./_assets/border-width-focused-color.png)\n\nIt’s important to consider contrast when using different accent colors in your UI. For subtle\nbackgrounds, pair them with an accent border to meet the 3:1 contrast requirement for accessibility.\n\n[More about accent colors](https://atlassian.design/foundations/color/accents#use-borders-for-more-contrast-around-subtle-backgrounds)\n\n![](./_assets/border-width-accent-color.png)',
+  keywords: ['border', 'stroke', 'outline', 'design tokens', 'visual hierarchy']
+}, {
+  content: '## Color anatomy\n\n### Saturated colors\n\nSaturated colors can infuse meaning to an experience, highlight UI, or create associations with\nsimilar colored UI.\n\n<img\n\tsrc={colorSaturatedPaletteLight}\n\talt="Color ramps for all saturated colors, which are blue, teal, green, lime, yellow, orange, red, magenta, and purple."\n/>\n\n### Neutral colors\n\nNeutral colors apply to most backgrounds, text, and shapes in our experiences. They don’t typically\nhave a meaning associated with them, though they can imply things like disabled states.\n\n<img\n\tsrc={colorNeutralPaletteLight}\n\talt="There are dedicated neutrals for both light and dark mode."\n/>\n\nColor ramp for light neutrals, and a separate color ramp for dark neutrals.\n\n### Alpha colors\n\nAlpha colors have varying levels of transparency or opacity. Transparency helps UI adapt to\ndifferent background colors and elevations.\n\n<img\n\tsrc={colorAlphaPaletteLight}\n\talt="Light and dark alpha neutral ramps with a circle appearing behind part of the ramps, which demonstrate the transparent quality of the colors."\n/>\n\nIf you aren\'t using design tokens, see our\n[color palette page](https://atlassian.design/foundations/color/color-palette) for hex codes and\nRGBa values.\n\n## Applying color with design tokens\n\nFor most Atlassian app experiences, colors are applied using\n[design tokens](https://atlassian.design/tokens/design-tokens). This means rather than choosing a\ncertain shade or value, you’ll choose a design token to apply colors.\n\nFor the full list of color design tokens and their values, see our\n[design token reference list](https://atlassian.design/components/tokens/all-tokens). Every token\ncomes with a description to help you ensure you’re using the correct one.\n\n<img\n\tsrc={colorTokensInScreenLight}\n\talt="Screenshot of a Jira board mapped to different token examples. The board title uses “color.text”, task icon uses “color.icon.accent.green”, and the button background uses “color.background.brand.bold."\n/>\n\nAll color design tokens start with the word “color”, followed by the property that it\'s applied to,\nsuch as a background, border, or icon.\n\n<img\n\tsrc={colorApplyingColor2Light}\n\talt="The design token name, “color.background.danger.bold.hovered”, broken down into parts. The property is “background”, and the modifier is “danger.bold.hovered."\n/>\n\nAfter the property name, the token may have one or more modifiers that represent the different parts\nof our color system: color role, emphasis level, and interaction state.\n\n## Color roles\n\nColor roles describe the intention behind the color. For example, color roles are applied to buttons\nto differentiate between primary, secondary, warning, or dangerous actions.\n\n<img\n\tsrc={colorRolesLight}\n\talt="Examples of color roles applied to button backgrounds. Primary button uses the brand color role, default button uses the neutral color role, warning button uses the warning color role, and danger uses the danger color role."\n/>\n\n<ColorRolesTable />\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: colorRoleDoLight, alt: \'\' }}>\n\t\tUse the right color role for your situation.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: colorRoleDontLight, alt: \'\' }}>\n\t\tDon’t use an accent when the color has semantic meaning.\n\t</DoDont>\n</DoDontGrid>\n\n## Emphasis levels\n\nEmphasis determines the amount of contrast a color has against the default surface. Emphasis can\nrange from subtlest to boldest. Bolder colors have more contrast against the default surface, which\nadds more attention than subtle colors.\n\n<img\n\tsrc={colorEmphasisLevelStatusLight}\n\talt="Comparing differences between bold and default lozenges. Bold lozenges have much more contrast than the default lozenges.Comparing differences between default, subtle, and subtlest text. Default text has the highest contrast, subtlest has the least."\n/>\n<img\n\tsrc={colorEmphasisLevelsTextLight}\n\talt="Comparing differences between default, subtle, and subtlest text. Default text has the highest contrast, subtlest has the least."\n/>\n\n### Use inverse tokens on bold backgrounds\n\nInverse tokens are designed to show on bold backgrounds. There are inverse tokens for text, borders,\nand icons on bold backgrounds.\n\nFor bold warning backgrounds, which are yellow, there are special `warning.inverse` tokens designed\nto pass WCAG AA contrast requirements.\n\n<img\n\tsrc={colorEmphasisLevelInverseLight}\n\talt="A danger banner and warning banner with text. The danger banner text is using “color.text.inverse”, and the warning banner text is using “color.text.warning.inverse."\n/>\n\n## Interaction states\n\nStates communicate the status of an interactive element.\n\n<img\n\tsrc={colorInteractionStatesLight}\n\talt="Button interaction states, which include default, hovered, and pressed states."\n/>\nUse hovered, pressed, selected, focused, or disabled tokens to create visual changes related to\ninteraction states.\n\n### Hovered and pressed for icons\n\nThere are no dedicated hovered and pressed tokens for icons. Instead, we recommend using a subtle\nneutral background to indicate state changes.\n\n<img\n\tsrc={colorInteractionStatesIconsLight}\n\talt="Icon interaction states. The default icon background uses “color.background.neutral.subtle”, the hovered icon background uses “color.background.neutral.subtle.hovered”, and the pressed icon background uses “color.background.neutral.subtle.pressed."\n/>\n\n## Accessibility in color\n\nWe comply with WCAG AA standard contrast ratios:\n\n- **Must pass 3:1 contrast:** Any UI essential to understanding the experience and text 24px or\n  larger ([WCAG 1.4.11](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html))\n- **Must pass 4.5:1:** Text smaller than 24px\n  ([WCAG 1.4.3](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html))\n\nSee our [color accessibility](https://atlassian.design/foundations/accessibility#colors) guidance\nfor more information.\n\n## Designing in dark mode\n\nDesign tokens currently support two color themes: light and dark. Each color design token maps to a\ndifferent value for each theme so their appearance differs depending on which theme is being used.\n\n- To learn the basics of tokens and themes, go to\n  [design tokens](https://atlassian.design/tokens/design-tokens).\n- For detailed mappings from light to dark colors, see\n  [picking colors for dark mode](https://atlassian.design/foundations/color/color-palette#picking-colors-for-dark-mode).\n  Note that if you are using design tokens, you shouldn’t have to map your own values.\n\n## Related\n\n- Learn about the basics of [design tokens](https://atlassian.design/tokens/design-tokens).\n- If you need hex codes, RGBA values, or dark mode mappings, see our\n  [color palettes](https://atlassian.design/foundations/color/color-palette).\n- For guidance on color usage in charts, read our\n  [data visualization color guideline](https://atlassian.design/foundations/color/data-visualization-color).\n- See the list of [all design tokens](https://atlassian.design/components/tokens/all-tokens) for\n  full descriptions and values for all tokens.',
+  keywords: ['color', 'palette', 'contrast', 'brand', 'design tokens', 'themes']
+}, {
+  content: 'Accents don\'t communicate any specific meaning to users, unlike success, warning, or other\n[color roles](https://atlassian.design/foundations/color#color-roles).\n\nUse accent colors where users choose a color for their content (in\n[color pickers](https://atlassian.design/foundations/color/color-picker-swatches)), or in\nexperiences where color helps categorize content.\n\n<img\n\tsrc={accentsWhiteboardLight}\n\talt="Color ramps for all saturated colors, which are blue, teal, green, lime, yellow, orange, red, magenta, and purple."\n/>\n\n## Color options\n\nThere are 10 accent colors available: blue, teal, green, lime, yellow, purple, magenta, red, orange,\nand gray.\n\n<img src={accentsColorsLight} alt="Tags shown in the 10 accent colors." />\n\n## Applying accent colors\n\nEach accent color has dedicated [design tokens](https://atlassian.design/tokens/design-tokens) that\ncan be applied to backgrounds, text, borders and icons. The full list of tokens is available in\n[design token reference list](https://atlassian.design/components/tokens/all-tokens).\n\nIf you aren\'t sure whether to use an accent token, consider whether the color could be swapped for\nanother without changing the experience or meaning behind it.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: accentsRoleDo, alt: \'\' }}>\n\t\tUse accent tokens for any experience where the color is just one of many colors, and changing it\n\t\twould have no impact on the experience.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: accentsRoleDont, alt: \'\' }}>\n\t\tDon\'t use accent tokens when the color has a specific meaning in our system, such as\n\t\tinformation, warning, or success.\n\t</DoDont>\n</DoDontGrid>\n\n## Emphasis levels\n\nAccent tokens come in multiple shades, which can either provide different emphasis levels for visual\nhierarchy or be used to provide more color options for user-generated content.\n\n### Background accent tokens\n\nBackground accent tokens have four emphasis levels ranging from subtlest to bolder.\n\n<img\n\tsrc={accentsBackgroundAccentTokensLight}\n\talt="A color picker with four shades per color. There is a label pointing to each shade of purple. From most subtle to boldest, the labels say color.background.accent.purple.subtlest, color.background.accent.purple.subtler, color.background.accent.purple.subtle, and color.background.accent.purple.bold."\n/>\n\n### Text accent tokens\n\nText accent tokens have two emphasis levels – default and bolder.\n\n<img\n\tsrc={accentsTextAccentTokensLight}\n\talt="Examples of text in different colors. A label points to text in a lighter magenta that says color.text.accent.magenta.default. Another label points to text with a darker shade that says color.text.accent.magenta.bolder."\n/>\n\n### Icon accent tokens\n\nIcon accent tokens have two emphasis levels – default and bolder.\n\n<img\n\tsrc={accentsIconsLight}\n\talt="Examples of icons in different colors. A label points to an icon in a lighter magenta that says color.icon.accent.magenta.default. Another label points to an icon with a darker shade that says color.icon.accent.magenta.bolder."\n/>\n\n## Accent color accessibility\n\nWhen pairing accent text or icon colors against backgrounds, make sure they meet\n[minimum contrast requirements](https://atlassian.design/foundations/color#accessibility-in-color).\n\n- Pair default or bolder accent text or icons with subtlest and subtler accent backgrounds\n- Pair bolder accent text or icons with subtle accent backgrounds\n- Pair inverse text or icons with bolder accent backgrounds\n\nIf you\'re pairing text or icon tokens outside of these recommendations, ensure they meet the minimum\ncontrast requirements against the background.\n\n<img\n\tsrc={accentsColorAccessibility2Light}\n\talt="Visualization of how various teal text and background pairings can look. Default and bolder text appears on a subtlest background, default and bolder text appears on a subtler background, bolder text appears on a subtle background, and inverse text appears on a bolder background.Visualization of how various teal icon and background pairings can look. Default accent icons or icons using accent text appear on a subtlest background, an icon using accent text appears on a subtler or subtle background, and an inverse icon appears on a bolder background.\n"\n/>\n<img\n\tsrc={accentsColorAccessibilityLight}\n\talt="Visualization of how various teal text and background pairings can look. Default and bolder text appears on a subtlest background, default and bolder text appears on a subtler background, bolder text appears on a subtle background, and inverse text appears on a bolder background.Visualization of how various teal icon and background pairings can look. Default accent icons or icons using accent text appear on a subtlest background, an icon using accent text appears on a subtler or subtle background, and an inverse icon appears on a bolder background.\n"\n/>\n\n## Best practices\n\n### Avoid yellow\n\nYellow presents a unique challenge for accessibility and can appear more like brown. Consider using\na different accent color in its place, such as orange.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: accentsAvoidYellowDoLight, alt: \'\' }}>\n\t\tConsider using accent tokens other than yellow, such as orange.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: accentsAvoidYellowDontLight, alt: \'\' }}>\n\t\tAvoid using yellow accent tokens, as these become brown to meet contrast requirements.\n\t</DoDont>\n</DoDontGrid>\n\n### Use borders for more contrast around subtle backgrounds\n\nPair subtler accent backgrounds with accent borders if your\n[experience needs to pass 3:1 contrast](https://atlassian.design/foundations/color#accessibility-in-color).\n\nBolder accent backgrounds meet these requirements on their own. For data visualization, use our\n[chart tokens](https://atlassian.design/foundations/color/data-visualization-color#custom-charts)\ninstead.\n\n<img\n\tsrc={accentsBorderTokenLight}\n\talt="View of a calendar event with a label pointing to the border color that says color.border.accent.magenta. Another label points to the background color that says color.background.accent.magenta.subtler."\n/>\n\n### Avoid mixing different accent colors\n\nMaintain visual harmony by combining foreground and background elements with colors from the same\nfamily.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: accentsMixingColorsDoLight, alt: \'\' }}>\n\t\tPair accent background and foreground elements (text, icons, or borders) from the same color to\n\t\tcreate harmonious experiences.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: accentsMixingColorsDontLight, alt: \'\' }}>\n\t\tDon\'t mix accent backgrounds with different colored foreground elements (text, icons, or\n\t\tborders).\n\t</DoDont>\n</DoDontGrid>',
+  keywords: ['accent colors', 'status colors', 'semantic colors', 'success', 'warning', 'error']
+}, {
+  content: '## The palette\n\n<ColorPaletteRamps />\n\n## Picking colors for dark mode\n\nNeutral colors are set up in a way that makes it easy to convert a light theme to a dark theme. If\nyou use our [design tokens](https://atlassian.design/tokens/design-tokens) to apply colors, this\nmapping is done for you.\n\nThere is a light neutral ramp and an equivalent dark neutral ramp. Neutral100 in the light neutral\nramp should equate to DarkNeutral100 in the dark neutral ramp.\n\n<img\n\tsrc={paletteNeutralMapping}\n\talt="How light neutral ramp maps to dark neutral ramp in light and dark mode respectively."\n/>\n\nSaturated colors are also easy to convert from a light theme to a dark theme using symmetry. We\ncurrently have 10 swatches set up in each palette. If the swatches are divided in half, each half\nbecomes a mirror.\n\n<img\n\tsrc={paletteSaturatedMapping}\n\talt="How colors in the blue ramp maps across light and dark mode."\n/>\n\nFor instance, if a button color is 700 in light theme, it will be 400 in dark theme. If a section\nmessage background is 100 in light theme, it will be 1000 in dark theme. Design tokens will handle\nthese conversions for you.\n\n<img\n\tsrc={paletteJiraBoard}\n\talt="Screenshot of a Confluence page, which is shown half in light mode and half in dark mode. The button background uses B700 in light mode and B400 in dark mode. The section message background uses B100 in light mode and B1000 in dark mode."\n/>\n\nUsing symmetry is a great place to start and will cover most use cases. However, it may not work for\nall use cases and color mapping can be adjusted accordingly.\n\n## Dedicated to\n\nThese colors have been dedicated to honor the memory of Rosie and Alexandria, and will be woven into\nAtlassian apps and design for years to come.\n\n<ColorPaletteDedication />',
+  keywords: ['color palette', 'color system', 'brand colors', 'primary', 'secondary']
+}, {
+  content: "Color pickers let users choose colors for elements in their content.\n\nUse design tokens for color pickers to ensure the colors work across different themes and\nexperiences.\n\n<img\n\tsrc={colorPickerExampleLight}\n\talt=\"Confluence page in edit mode with the text color picker open.\"\n/>\n\n## Choosing tokens for color pickers\n\n- [Text color pickers](#text-color-pickers)\n- [Background color pickers](#background-color-pickers)\n- [Chart color pickers](#chart-color-pickers)\n\nA range of colors and shades are available. Determine which ones to include based on the needs of\nyour experience.\n\n### Text color pickers\n\nThere are two accent shades of each text color for a total of 18 text token color options. See the\navailable [text accent tokens](https://atlassian.design/components/tokens/all-tokens#color-text) in\nthe design tokens list.\n\n<img\n\tsrc={colorPickerTextLight}\n\talt=\"A text color picker with two shades per color. There is a label pointing to each shade of purple as well as the white color option. From most bold to subtle, the labels say color.text.accent.purple.bolder, color.text.accent.purple.default, and color.text.inverse.\"\n/>\n\nIf you need additional text colors, you can add a third row of colors using our\n[accent icon colors](https://atlassian.design/components/tokens/all-tokens#color-icon). These meet\nthe right contrasts for large-scale text (at least 18px bold or 24px).\n\n### Background color pickers\n\nThere are four accent shades of each background color for a total of 36 background color options.\nSee the available\n[background accent tokens](https://atlassian.design/components/tokens/all-tokens#color-background)\nin the design tokens list.\n\n<img\n\tsrc={colorPickerBackgroundsLight}\n\talt=\"A background color picker with four shades per color. There is a label pointing to each shade of purple as well as the default color option. From most subtle to bold, the labels say color.background.accent.purple.subtlest, color.background.accent.purple.subtler, color.background.accent.purple.subtle, color.background.accent.purple.bolder, and elevation.surface.\"\n/>\n\n### Chart color pickers\n\nThere are three accent shades of each chart color for a total of 27 chart color options. See the\navailable [chart accent tokens](https://atlassian.design/components/tokens/all-tokens#color-chart)\nin the design tokens list.\n\n<img\n\tsrc={colorPickerChartLight}\n\talt=\"A chart color picker with three shades per color. There is a label pointing to each shade of purple. From most subtle to bold, the labels say color.chart.purple.bold, color.chart.purple.bolder, and color.chart.purple.boldest.\"\n/>\n\n## Best practices\n\n### Use tokens appropriate to the type of picker\n\nText tokens should be used for text color pickers, and background tokens should be used for\nbackground color pickers.\n\n<DoDontGrid>\n\t<DoDont\n\t\ttype=\"do\"\n\t\timage={{\n\t\t\turl: colorPickerChartRoleDo,\n\t\t\talt: 'Color picker showing chart tokens being used for a chart color picker',\n\t\t}}\n\t>\n\t\tUse design tokens appropriate to the type of picker.\n\t</DoDont>\n\t<DoDont\n\t\ttype=\"dont\"\n\t\timage={{\n\t\t\turl: colorPickerChartRoleDont,\n\t\t\talt: 'Color picker showing background tokens incorrectly being used for a chart color picker',\n\t\t}}\n\t>\n\t\tDon't use design tokens solely based on how the color looks.\n\t</DoDont>\n</DoDontGrid>\n\n### Ensure there are accessible color pairing options\n\nConsider how colors will be applied by customers to ensure appropriate options are available to\nsupport the creation of accessible content.\n\nFor example, check how text and background colors will be used together to ensure the emphasis\nlevels required for accessible pairings are available.\n\n<DoDontGrid>\n\t<DoDont\n\t\ttype=\"do\"\n\t\timage={{\n\t\t\turl: colorPickerAccessibleRoleDo,\n\t\t\talt: 'Color picker with text and background color options that can create accessible contrast ratios when paired together',\n\t\t}}\n\t>\n\t\tProvide color options that can be paired in a way that meets accessible contrasts.\n\t</DoDont>\n\t<DoDont\n\t\ttype=\"dont\"\n\t\timage={{\n\t\t\turl: colorPickerAccessibleRoleDont,\n\t\t\talt: 'Color picker with limited color options that cannot create accessible contrast ratios when paired together',\n\t\t}}\n\t>\n\t\tDon't offer colors in color pickers that do not support the creation of accessible content.\n\t</DoDont>\n</DoDontGrid>\n\n### Avoid yellow\n\nWhile yellow accent and chart tokens are available, we recommend not including them in your color\npicker.\n\n<DoDontGrid>\n\t<DoDont\n\t\ttype=\"do\"\n\t\timage={{\n\t\t\turl: colorPickerAvoidYellowTextDo,\n\t\t\talt: 'Color picker showing orange text color option instead of yellow',\n\t\t}}\n\t>\n\t\tConsider using accent tokens other than yellow, such as orange.\n\t</DoDont>\n\t<DoDont\n\t\ttype=\"dont\"\n\t\timage={{\n\t\t\turl: colorPickerAvoidYellowTextDont,\n\t\t\talt: 'Color picker showing yellow text color that appears brown due to contrast requirements',\n\t\t}}\n\t>\n\t\tAvoid using yellow accent tokens, as these become brown to meet contrast requirements.\n\t</DoDont>\n</DoDontGrid>\n\n### Use theme agnostic color descriptions\n\nAlways provide text descriptions for color options in a picker. Text descriptions should be included\nin a tooltip.\n\nUse emphasis levels to describe different shades of the same color, from subtlest to boldest. When\napplied to a background color picker, this might appear like:\n\n- Subtlest {color}\n- Subtler {color}\n- Subtle {color}\n- Bold {color}\n\n<DoDontGrid>\n\t<DoDont\n\t\ttype=\"do\"\n\t\timage={{\n\t\t\turl: colorPickerAgnosticColorDo,\n\t\t\talt: 'Color picker with tooltips showing theme-agnostic descriptions like subtle blue and bold blue',\n\t\t}}\n\t>\n\t\tUse color descriptions that work across light and dark themes, such as 'subtle' and 'bold'.\n\t</DoDont>\n\t<DoDont\n\t\ttype=\"dont\"\n\t\timage={{\n\t\t\turl: colorPickerAgnosticColorDont,\n\t\t\talt: 'Color picker with tooltips showing theme-specific descriptions like light blue and dark blue',\n\t\t}}\n\t>\n\t\tDon't use terms such as 'light' and 'dark' to describe colors, as these descriptions become\n\t\tinaccurate between light and dark themes.\n\t</DoDont>\n</DoDontGrid>\n\nWhen defining text descriptions for inverse or default surface color options, use \"default\" as the\ncolor description where possible. In cases where this doesn't make sense, such as for inverse text,\nthe description can be changed dynamically between light and dark mode.\n\n<img\n\tsrc={colorPickerAgnosticColorLight}\n\talt=\"Color picker in both light mode and dark mode. One swatch option says 'White' in light mode and 'Black' in dark mode.\"\n/>",
+  keywords: ['color picker', 'color swatches', 'text color tokens', 'background color tokens', 'chart color tokens', 'color selection', 'accessible colors', 'color contrast', 'design tokens', 'theme agnostic colors']
+}, {
+  content: "import {\n\tBrandAndNeutralChartTokensTable,\n\tCategoricalChartTokensTable,\n\tSemanticChartTokensTable,\n} from '@af/design-system-docs-ui';\n\nData visualization is the representation of information in pictorial or graphical format, such as\ncharts, graphs, maps, and diagrams. These visuals aid in the communication of complex data so that\ninsights can be more easily drawn.\n\nBecause color can affect our perception of information, the appropriate use of color is critical in\nmaking a data visualization successful.\n\n## Applying color to data visualizations\n\nColor in Atlassian apps experiences are applied using\n[design tokens](https://atlassian.design/tokens/design-tokens). For data visualization, chart color\ntokens are available to ensure appropriate color contrasts can be met. Use chart tokens for lines,\nbars or other UI representing the data. For elements of the chart interface such as axes and text,\nuse border and text tokens.\n\n<img\n\tsrc={dataVisPageAnalyticsLight}\n\talt=\"In this chart example, the title and legend text uses `color.text`, the chart grid lines uses `color.border`, the threshold line uses `color.chart.neutral`, the line representing chart data uses `color.chart.brand`, and the tick labels uses `color.text.subtle`.\"\n/>\n\n- **Title**: `color.text`\n- **Tick label**: `color.text.subtle`\n- **Threshold or reference line**: `color.chart.neutral`\n- **Legend**: `color.text`\n- **Gridline**: `color.border`\n- **Mark**: `color.chart.brand`\n\n## Types of chart colors\n\n- [Single-color charts](https://atlassian.design/foundations/color/data-visualization-color#single-color-charts)\n- [Categorical](https://atlassian.design/foundations/color/data-visualization-color#categorical)\n- [Status and severity](https://atlassian.design/foundations/color/data-visualization-color#status-and-severity)\n- [Custom charts](https://atlassian.design/foundations/color/data-visualization-color#custom-charts)\n\nSequential and divergent chart colors are not currently supported.\n\n### Single-color charts\n\nFor data visualization requiring only one color, use `color.chart.brand` as the default color\nchoice. This ensures all data visualization embodies our brand's visual language.\n\nIf the data represents status or severity, use the appropriate\n[status or severity color token](https://atlassian.design/foundations/color/data-visualization-color#status-and-severity)\ninstead.\n\nTo highlight one piece of data from a data set, use `color.chart.neutral` for the less important\ninformation so that the important data can stand out.\n\n<img\n\tsrc={dataVisPageAnalyticsLight}\n\talt=\"Bar chart showing unit test coverage over time. Today is highlighted in blue.\"\n/>\n\n<BrandAndNeutralChartTokensTable />\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: dataVisColorRoleDo, alt: '' }}>\n\t\tUse a single color as the default for data visualizations. Only add more colors when needing to\n\t\tdifferentiate between data categories.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dataVisColorRoleDont, alt: '' }}>\n\t\tDon't use more than one color in your data visualization if the additional colors don't serve\n\t\tany communication purpose.\n\t</DoDont>\n</DoDontGrid>\n\n### Categorical\n\nUse categorical chart colors when you need to differentiate two or more unrelated data categories\nfrom each other.\n\n<img\n\tsrc={dataVisCategoricalChartLight}\n\talt=\"Line chart using categorical colors to represent different conversion rates.\"\n/>\n\nFollow the same sequence as the numbers in the token names. This ensures each color is visually\ndistinct from its neighbors across all color deficiencies. If the display order can't be controlled\n(in line charts for example), provide\n[additional visual indicators](https://atlassian.design/foundations/color/data-visualization-color#dont-rely-on-color-alone).\n\n<CategoricalChartTokensTable />\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: dataVisCategoricalDo, alt: '' }}>\n\t\tLimit the number of colors presented in your data visualization to 5-6 by grouping additional\n\t\tcategories together.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dataVisCategoricalDont, alt: '' }}>\n\t\tAvoid using more than 5-6 colors in a data visualization. Too many colors can hinder\n\t\tcomprehension.\n\t</DoDont>\n</DoDontGrid>\n\n### Status and severity\n\nThese chart colors use established color associations for status and severity, such as in progress,\nat risk, or high priority. Use these when you want to reinforce meaning through color in your data\nvisualization.\n\nIf more than one set of data exists for a given color association, use bold emphasis to represent\nthe more extreme value. For example, High priority and Highest priority both use danger tokens, but\nHighest uses `color.chart.danger.bold`.\n\nIt's important to note that status and severity colors may be hard for users with color deficiencies\nto tell apart. For this reason, use other\n[visual indicators](https://atlassian.design/foundations/color/data-visualization-color#dont-rely-on-color-alone)\nor consider\n[categorical colors](https://atlassian.design/foundations/color/data-visualization-color#categorical)\nas a better option.\n\n<img src={dataVisStatusSeverityLight} alt=\"Chart representing breakdown by priority.\" />\n\n<SemanticChartTokensTable />\n\n### Custom charts\n\nA generic set of chart color tokens is available to support data visualization experiences where end\nusers can choose their own colors.\n\nThey can also be used to build custom categorical color schemes, although our predefined\n[categorical tokens](https://atlassian.design/foundations/color/data-visualization-color#categorical)\nare recommended for better accessibility and consistency.\n\nThese tokens are available in every hue with three emphasis levels. See all custom chart tokens in\nour [design token reference list](https://atlassian.design/components/tokens/all-tokens#color-chart)\nor get guidance on\n[color picker swatches](https://atlassian.design/foundations/color/color-picker-swatches).\n\n<img src={dataVisCustomChartColorsLight} alt=\"Editing colors on a custom chart in Confluence.\" />\n\n## Interacting with chart data\n\nData visualization often allows users to drill into data by hovering or selecting a data point. Use\nchart hovered tokens to provide visual feedback for these interactions.\n\nAn alternative approach is to fade out data that isn't being interacted with. Use our\n`opacity.disabled` token for this implementation.\n\n<img\n\tsrc={dataVisChartDataLight}\n\talt=\"Two segmented bar chart examples. In the first example, hovering on one of the segments changes its shade. In the second example, hovering on one of the segments applies opacity to everything except the element being hovered on.\"\n/>\n\n## All chart color tokens\n\nFor the full list of chart design tokens and their values, see our\n[design token reference list](https://atlassian.design/components/tokens/all-tokens#color-chart).\nEvery token comes with a description to help you ensure you're using the correct one.\n\n## Chart color accessibility\n\nOur chart colors meet WCAG AA 3:1 contrast ratios when used on any of our\n[elevation surfaces](https://atlassian.design/foundations/elevation#types-of-elevations)\n([WCAG 1.4.11](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html)).\n\nThe following sections provide more guidance to help you achieve better accessibility.\n\n### Apply a border or space between adjacent colors\n\nWhile these chart colors pass 3:1 contrast ratios against surfaces, they don't against each other.\nFor this reason, apply a space or border (`color.border.inverse`) as a visual separator between data\nelements.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: dataVisAdjacentColorDoLight, alt: '' }}>\n\t\tApply a visual separator between chart colors.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dataVisAdjacentColorDontLight, alt: '' }}>\n\t\tDon't place chart colors adjacent to each other.\n\t</DoDont>\n</DoDontGrid>\n\n### Don't place text on chart colors\n\nOur chart colors don't support accessible pairings with text, which need at least a 4.5:1 contrast.\nConsider placing text next to the chart element instead.\n\nFor use cases where text is an essential feature (for example, calendar events), consider using our\nother [color tokens](https://atlassian.design/foundations/color) instead.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: dataVisTextChartsDo, alt: '' }}>\n\t\tPosition text nearby chart data.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dataVisTextChartsDont, alt: '' }}>\n\t\tDon't apply text over chart colors.\n\t</DoDont>\n</DoDontGrid>\n\n### Don't rely on color alone\n\nAvoid using just color to communicate meaning in your data visualization. Incorporate other visual\nindicators such as shapes, line texture, patterns, or direct labels to support users in making sense\nof the data. [Highcharts](https://www.highcharts.com/demo) provide some good examples of these\naccessible chart experiences.\n\nAdditionally, providing the data in alternative formats, such as tables and text-based descriptions,\nwill ensure all users can access the data in their preferred format.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: dataVisLineChartDo, alt: '' }}>\n\t\tIncorporate visual indicators other than color into your data visualization.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dataVisLineChartDont, alt: '' }}>\n\t\tDon't rely on color alone to communicate meaning in your data visualization.\n\t</DoDont>\n</DoDontGrid>\n\n## Data visualization in dark mode\n\nChart color tokens currently support two color themes: light and dark. Each token maps to a\ndifferent value for each theme so their appearance differs depending on which theme is being used.\n\n- To learn the basics of tokens and themes, go to\n  [design tokens](https://atlassian.design/tokens/design-tokens).\n- For detailed mappings from light to dark colors, see\n  [picking colors for dark mode](https://atlassian.design/foundations/color/color-palette#picking-colors-for-dark-mode).\n  Note that if you are using design tokens, you shouldn't have to map your own values.",
+  keywords: ['data visualization', 'charts', 'graphs', 'color coding', 'data colors']
+}, {
+  content: '<SectionMessage title="">\n\tDate and time formatting is tied to a person’s locale and account settings. Because of this, what a customer sees could be different from the guidelines on this page.\n</SectionMessage>\n\n## Date and time for internationalization\n\nEach programming language has an i18n (internationalization) library that automatically localizes time and date strings based on a user’s locale settings/preferences. Time and date strings should never be localized manually by a designer, engineer, or translator.\n\nThe Product Internationalization team is responsible for creating app UI content in non-English languages by localizing externalized code strings provided by our Product Engineers.\n\nEngineers must:\n- Ensure date and time references/strings are not hardcoded \n- Reference the programming i18n library API, which will automatically format time and date strings as per a customer’s detected or selected locale.\n\n## Date formats\n\nAtlassian uses US date formatting (for example: January 12, 2028).\n\nWhen you’re handing designs over to engineers, you need to specify which date format length is needed. The i18n library API will use this information to format the date accordingly. Date and time formats should not be hardcoded.\n\nThere are 4 [date format lengths](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-date-formats): full, long, medium, and short.\n\n### Full date\n\nThe full date format is weekday, month, day, year.\n\n<DoDontGrid>\n\t<DoDont type="do">Sunday, August 14, 2028</DoDont>\n</DoDontGrid>\n\n### Long date\n\nA long date format is month, day, year\n\n<DoDontGrid>\n\t<DoDont type="do">November 8, 2008</DoDont>\n</DoDontGrid>\n\n### Medium date\n\nThe medium date format is abbreviated month, day, year. Only use this format when space is limited.\n\n<DoDontGrid>\n\t<DoDont type="do">Sep 26, 1952</DoDont>\n</DoDontGrid>\n\n#### Abbreviating months and days\n\nIf you need to abbreviate months or days, use the first 3 letters of the month or day.\n\n|Month abbreviation| Month in full| | Day abbreviation| Day in full|\n|------|-------|------|-------|------|\n|Jan | January| |Mon | Monday|\n|Feb | February| |Tue | Tuesday|\n|Mar| March| |Wed | Wednesday|\n|Apr | April| |Thu | Thursday|\n|May | May| |Fri | Friday|\n|Jun | June| |Sat | Saturday|\n|Jul | July| |Sun | Sunday|\n|Aug | August| | | |\n|Sep | September| | | |\n|Oct | October| | | |\n|Nov | November| | | |\nDec | December| | | |\n\n### Short date\n\nShort format dates are written in digits.\n\nIn most cases, avoid short format dates as different countries use the date in a different order, which can cause confusion and effect readability and usability. In the US, 10-8-2026 is October 8, 2026, but in Australia and the UK, it’s August 10, 2026.\n\nHowever, short format dates might be suitable for situations like data storage, sorting or filtering, or data export/import. If using, use the ISO 8601 international standard for numerical date format, which is YYYY-MM-DD.\n\n## Ordinal numbers\n\nDon’t use ordinal numbers (1st, 2nd, 3rd, and so on) in dates.\n\n## Date ranges\n\nIf you have a date range, use ‘to’ and not hyphens. For example: ‘2020 to 2024’. Hyphens are read out by screen readers as ‘hyphen’, which can lead to confusion.\n\nAn exception is financial years, which use a hyphen without spaces on either side. For example: FY2008-09\n\nUse ‘and’ if a range is preceded by ‘between’. For example: He was in Paris between 2025 and 2026.\n\n<DoDontGrid>\n\t<DoDont type="do">2014 to 2015</DoDont>\n\t<DoDont type="dont">2014-15</DoDont>\n</DoDontGrid>\n\n## Time formats\n\nShow time in digits for precision and to give a clearer expression of time.\n\nSpecify to engineers which time format length is needed. The i18n library API will then format the time according to a customer’s account settings. Make sure time is not hardcoded.\n\nUse a colon (:) to separate the hours and minutes (though this might change depending on a user’s locale and account settings).\n\nLike dates, there are 4 [time format lengths](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-time-formats): full, long, medium, and short.\n\n### Full time\n\nThe full time format is hour, minutes, seconds, and time zone spelt out.\n\n<DoDontGrid>\n\t<DoDont type="do">3:30:10 p.m. Pacific Standard Time</DoDont>\n</DoDontGrid>\n\n### Long time\n\nThe long time format is hour, minutes, seconds, and the time zone initials.\n\n<DoDontGrid>\n\t<DoDont type="do">11:18:30 p.m. PST</DoDont>\n</DoDontGrid>\n\n### Medium time\n\nThe medium time format is hour, minutes, and seconds.\n\n<DoDontGrid>\n\t<DoDont type="do">8:50:28 a.m.</DoDont>\n</DoDontGrid>\n\n### Short time\n\nThe short time format is hour and minutes.\n\n<DoDontGrid>\n\t<DoDont type="do">2:40 p.m.</DoDont>\n</DoDontGrid>\n\n### 24-hour time\n\nThe 24-hour format is useful for more serious communications, for example in the case of outages and security comms. The use of the 24-hour format is mostly system-driven by the i18n library API.\n\nThis format numbers hours from 00:00 hours (midnight) to 23:59 and uses 4 digits: the first 2 digits are the hours and the next 2 digits are the minutes. Use a colon (:) to separate the hours and minutes, though this might change depending on someone\'s account settings.\n\n## Writing time\n\n### Duration and timestamps\n\nWhen writing timestamps, labels on graphs, or durations, avoid using zeros before the hour. For example: 5:29. not 05:29. Use a colon between the hours and minutes with no spaces on either side.\n\n### Using a.m. and p.m.\n\nFormat time using ‘a.m.’ and ‘p.m.’ when creating content like blogs, manuals, and instructions.\n- Lowercase ‘a.m.’ and ‘p.m.’\n- Use periods between the letters\n- Add a space between the time and the ‘a.m.’ or ‘p.m.’. For example: 6:30 a.m. (not 6:30a.m.)\n\n### Time range\n\n- If you have a time range that’s entirely in the morning or evening, use \'a.m.\' or \'p.m.\' only once. For example: 6:30 to 10 p.m.\n- If the time range goes from the morning into the evening (or vice versa), use both. For example: 10 a.m. to 2 p.m.\n\n### Noon, midday, and midnight\n\nWhere suitable, use ‘noon’, ‘midday’ or ‘midnight’ instead of ‘12 am’ or ‘12 pm’ as it makes it easier for people to differentiate between these times.\n\n### Avoid using  ‘fortnightly ‘or ‘bi’ for months  and years\n\nAvoid using ‘fortnightly’ and the prefix ‘bi’ to mean either 2 or twice, as these terms can be confusing.\n\nInstead of:\n- **Fortnightly**: write ‘every 2 weeks’\n- **Bimonthly**: write ‘twice a month’ or ‘every 2 months’\n- **Biannual**: write ‘twice a year’ or ‘every 2 years’.\n\n<DoDontGrid>\n\t<DoDont type="do">Your sprint will repeat every 2 weeks.</DoDont>\n\t<DoDont type="dont">Your sprint will repeat fortnightly.</DoDont>\n</DoDontGrid>\n\n## Date and time formats\n\nThere are also full, long, medium, and short format lengths when combining date and time.\n\n### Full date and time\n\n<DoDontGrid>\n\t<DoDont type="do">Wednesday, June 12, 2024 at 6:25:59 p.m. Eastern Standard Time</DoDont>\n</DoDontGrid>\n\n### Long date and time\n\n<DoDontGrid>\n\t<DoDont type="do">April 25, 2027 at 9:05:32 p.m. PST</DoDont>\n</DoDontGrid>\n\n### Medium date and time\n\n<DoDontGrid>\n\t<DoDont type="do">Sep 5, 1999, 1:25:59 a.m.</DoDont>\n</DoDontGrid>\n\n### Short date and time\n\n<DoDontGrid>\n\t<DoDont type="do">2028-10-22, 6:25 p.m. </DoDont>\n</DoDontGrid>\n\n## Relative date and time\n\nIn some cases, like when the exact date is less important, the easiest way to describe something that happened very recently is using the ‘ago’ format.\n\nFor future and past events, use approximate time by rounding down to the largest or most recent date or time.\n\nYou should always provide a way for people to see the actual timestamp, usually via a tooltip.\n\n### Past\n\n| Description                 | Display                      | Display when limited space     |\n| --------------------------- | ---------------------------- | ------------------------------ |\n| Within the last few seconds | just now                     | now                            |\n| Within the last minute      | a minute ago                 | 1 m                            |\n| Within 59 minutes           | x minutes ago                | X m                            |\n| 60 minutes ago              | 1 hour ago                   | 1 h                            |\n| x hours ago                 | x hours ago                  | X h                            |\n| 1 day ago                   | yesterday                    | 1 d                            |\n| 1 day ago (with time)       | yesterday at 5:05 pm         | n/a                            |\n| 2 days ago < 7 days         | x days ago                   | Use the truncated date (Aug 8) |\n| 7 days ago                  | 1 week ago                   | Use the truncated date (Aug 8) |\n| > 7 days ago                | Date stamp: "August 8, 2018" | Use the truncated date (Aug 8) |\n\n### Future\n\n| Description                   | Display                      | Display when limited space     |\n| ----------------------------- | ---------------------------- | ------------------------------ |\n| Within the next few seconds   | shortly                      | now                            |\n| In the next minute            | In 1 minute                  | in 1 m                         |\n| In the next 60 minutes        | In x minutes                 | in X m                         |\n| In 60 minutes                 | In 1 hour                    | in 1 hr                        |\n| In x hours                    | In x hours                   | in X hr                        |\n| In 1 day (by date, not hours) | tomorrow                     | Use the truncated date (Aug 8) |\n| In 2 to 7 days                | In x days                    |                                |\n| In 7 days                     | In 1 week                    |                                |\n| In > 7 days                   | Date stamp: "August 8, 2018" |                                |\n| > 7 days ago                  | Date stamp: "August 8, 2018" |                                |\n\n## Style and punctuation\n\nStyle and punctuation for dates and time can change depending on locale and is determined by the i18n library API.\n\n### Capitalization\n\n- Months and days in English are proper nouns and start with a capital letter.\n- Specific days or periods in history are all proper nouns, so should be capitalized. For example: New Year’s Day, Renaissance, Cold War.\n- Use capital letters for all institutional holidays, religious days, and public events. For example: Ramadan, Yom Kippur, Good Friday, Martin Luther King Jr. Day.\n\n### Apostrophes\n\n- Avoid using apostrophes in UI copy and in developer and support documentation.\n- In more casual writing, you can use an apostrophe to stand in for the missing numerals in the year, such as \'the \'70s’.\n\n## Resources\n\n- [Int.DateTimeFormat constructor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#try_it) - a JavaScript library that devs can use and where designers can check formatting of date and time.\n- [Date formats](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-date-formats)\n- [Time formats](https://cldr.unicode.org/translation/date-time/date-time-patterns#basic-time-formats)',
   keywords: ['date', 'time', 'formatting', 'localization', 'datetime', 'content']
 }, {
   content: 'People care about how apps talk to them. YouTube, GitHub, and Slack all have a distinct voice, tone,\nand personality.\n\nApps engage us, manage to make us feel at home, capture our attention, and earn our loyalty.\n\nPoor messaging contributes to a poor user experience, which leads to dissatisfaction. On the other\nhand, good copy reflects our apps\' voice (personality) and enables us to build a better relationship\nwith our audience.\n\nIn short, good messaging may not be the reason people stay with our apps, but bad messaging could be\nthe reason they decide to leave.\n\n## Choose a message type\n\nUse different types of messages to guide people through their tasks. Each message type has a\nconsistent visual and writing style to help people know what to expect.\n\nUse these guidelines to choose and write the types of messages:\n\n- [Information message](https://atlassian.design/foundations/content/designing-messages/info-messages)\n  — provides additional information to motivate people.\n- [Error message](https://atlassian.design/foundations/content/designing-messages/error-messages) —\n  alerts people of a problem that has occurred and informs them what to do next.\n- [Success message](https://atlassian.design/foundations/content/designing-messages/success-messages)\n  — celebrates success along with the people using our apps.\n- [Warning message](https://atlassian.design/foundations/content/designing-messages/warning-messages)\n  — gives advanced notice of a potential change that may result in loss of data or an error state.\n- [Feature discovery](https://atlassian.design/foundations/content/designing-messages/feature-discovery)\n  — lets people know about a new feature.\n\n## Select the right component\n\nUse the table to identify the right component for your content.\n\nFor example:\n\n- If you want to highlight a new feature to a user, consider a spotlight card, benefits modal, or\n  empty state.\n- If you want to tell someone they\'ve accomplished a task, consider a flag.\n\n| Component                                     | Information message | Success message | Warning message | Error message | Feature discovery |\n| --------------------------------------------- | ------------------- | --------------- | --------------- | ------------- | ----------------- |\n| **Empty state**                               | Yes                 | Yes             |                 |               | Yes               |\n| **Banner**                                    | Yes                 |                 | Yes             | Yes           |                   |\n| **Flag**                                      | Yes                 | Yes             | Yes             | Yes           |                   |\n| **Section message**                           | Yes                 |                 | Yes             | Yes           |                   |\n| **Inline message**                            | Yes                 | Yes             | Yes             | Yes           |                   |\n| **Modal dialog**                              | Yes                 |                 | Yes             |               |                   |\n| **Benefits modal**                            |                     |                 |                 |               | Yes               |\n| **Onboarding (spotlight) and spotlight card** |                     |                 |                 |               | Yes               |\n\n### Empty state\n\nUse empty states to show when there is nothing to display in a view, for example, when a board has\nno tasks, someone clears their inbox, or a search returns no results.\n\nRead guidance on writing effective\n[empty state messages](https://atlassian.design/foundations/content/designing-messages/empty-state).\n\n<img\n\tsrc={messagesEmptyState}\n\talt="Empty state encouraging an admin to add people to a Jira project space."\n/>\n\nAn empty state can appear as a full-screen message or within panels, tables, and other containers.\n\n[Usage guidance for empty state component](https://atlassian.design/components/empty-state/usage).\n\n### Banner\n\nUse banners only for critical system-level messaging for example, warnings about loss of data or\nfunctionality.\n\n<img src={messagesBanner} alt="Banner message example with a red error message." />\n\nBanners appear at the top of the screen and shift the content below them.\n\n[Usage guidance for banner component](https://atlassian.design/components/banner/usage).\n\n### Flag\n\nUse flags for confirmations, alerts, and acknowledgments that require minimal user interaction.\n\n<img\n\tsrc={messagesFlag}\n\talt="Example of a flag message with a green tick icon, the heading \'You are now connected\', and the text describing a group the user is added to."\n/>\n\nFlags are event-driven messages that appear by overlaying content at the bottom left of the screen,\nemerging from the navigation sidebar.\n\n[Usage guidance for flag component](https://atlassian.design/components/flag/usage).\n\n### Section message\n\nUse section messages to alert the user of something that has happened in a specific section of the\nscreen.\n\n<img\n\tsrc={messagesSectionMessages}\n\talt="Example of a section message showing green tick icon, the heading Merged pull request, details of the pull request, and links to the hash and user name, and the time it happened."\n/>\n\nSection messages appear above the affected area (for example, work items in Jira).\n\n[Usage guidance for section message component](https://atlassian.design/components/section-message/usage).\n\n### Inline message\n\nUse inline messages to alert people to a required action or important information.\n\n<img\n\tsrc={messagesInlineDialog}\n\talt="Example of a cursor on a yellow caution icon triggering an inline dialog message."\n/>\n\nInline messages consist of an icon, message, and sometimes secondary text. People can interact with\nthe icon, title, or secondary text to reveal the full inline message.\n\n[Usage guidance for inline message component](https://atlassian.design/components/inline-message/usage).\n\n### Modal dialog\n\nUse modal dialogs to present a short-term task the user needs to perform.\n\n<img\n\tsrc={messagesModal}\n\talt="A modal that presents a task and a dropdown menu, with a clear action."\n/>\n\nModal dialogs display content in a layer above the page.\n\n[Usage guidance for modal dialog component](https://atlassian.design/components/modal-dialog/usage).\n\n### Benefits modal\n\nBenefits modals explain the value of a significant new feature or experience change.\n\nRead guidance on writing effective\n[feature discovery messages](https://atlassian.design/foundations/content/designing-messages/feature-discovery).\n\n<img\n\tsrc={messagesBenefitsModal}\n\talt="A modal for a Jira update that includes the key elements of a benefits modal."\n/>\n\nA benefits modal focuses a person\'s attention on a large or impactful update.\n\n[Usage guidance for benefits modal component](https://atlassian.design/components/onboarding/benefits-modal/usage).\n\n### Onboarding (spotlight) and spotlight card\n\nAn onboarding spotlight introduces new features to users through focused messages or multi-step\ntours. A spotlight card is for onboarding messages that need a more flexible layout, or don\'t\nrequire a dialog.\n\nRead guidance on writing effective\n[feature discovery messages](https://atlassian.design/foundations/content/designing-messages/feature-discovery).\n\n<img\n\tsrc={messagesOnboarding}\n\talt="An example of a spotlight pulse expanded into a spotlight component that encourages people to try the new feature."\n/>\n\n[Usage guidance for onboarding (spotlight) component](https://atlassian.design/components/onboarding/usage)\nand [spotlight card component](https://atlassian.design/components/onboarding/spotlight-card/usage).\n\n## Set the appearance (color and icon)\n\nMessages use colors and icons to help indicate content and urgency.\n\nMake sure you use the right\n[color role for your situation](https://atlassian.design/foundations/color#color-roles). For\nexample, yellow typically implies a warning, while green can imply success.\n\n<img\n\tsrc={colorRolesAndIcons}\n\talt="Icons showing different icons and colors we use in messages. Informative messages use a blue circle icon with an i inside, success is a green check icon, warning is a yelowish triangle icon with an exclamation mark, danger is a red diamond icon with an exclamation mark, and discovery or new is a purple circle with a question mark inside."\n/>\n\nReview [guidelines on using icons](https://atlassian.design/foundations/iconography) and\n[usage guidance for the icon component](https://atlassian.design/components/icon/usage).',
@@ -23,7 +44,7 @@ var guidelinesStructuredContent = exports.guidelinesStructuredContent = [{
   content: "An empty state message appears after someone has completed a task or workflow, or has cleared all\ndata associated with certain functionality. For example, clearing their inbox. These messages are a\nway to celebrate, add energy, and motivate people to get on with their next task.\n\nEmpty states can appear within a particular functionality or as a full-screen message. When crafting\nan empty state message, remember that most people scan text instead of reading everything. Make\nevery word count and avoid irrelevant details.\n\n## Writing best practices\n\n### Titles\n\n- Include an informative, scannable title. Try and limit the number of words as much as possible.\n- Titles are a good place to add wink if it’s appropriate.\n- Write in sentence case and don’t use punctuation unless it's a question.\n- Use the heading to describe the empty state or as an opportunity to tell people what they can do.\n\n### Body copy\n\n- Include the reason for the empty state and where they can go next. If there is nothing for them to\n  do, celebrate finishing a task.\n- Avoid repeating content from the title.\n- Keep messages one to two sentences long. Be considerate of people's time and patience. Be short,\n  to the point, and avoid using jargon.\n- Avoid having people look in another location for more information, but if it can't be avoided, use\n  a link to support content.\n\n### Call to action (CTA)\n\n- When offering an action to perform after an empty state, use imperative verbs such as “Try”,\n  “Remove”, or “Create”, in the CTA to describe what action people will be making instead of vague\n  terms such as “OK”.\n- An option to dismiss or cancel lets people feel reassured that they can opt-out.\n- Limit your CTA to one or two words.\n- Your CTA button should always complement the title of the empty state.\n- Empty states are an opportunity to encourage people to interact further with our apps. While\n  optional they’re a good way to educate people about where they can go next or motivate them to\n  explore.\n\nBe careful of how many call to action buttons are on one page. You don’t want to overwhelm people\nwith too many options.\n\n## Voice and tone\n\nYou want to leave people feeling motivated, supported, and delighted. Convey accurate emotions and\nmake sure people know how to respond. Follow some of the following\n[Atlassian voice and tone principles](https://atlassian.design/foundations/content/voice-tone) to\nbuild your message:\n\n### Motivate by showing possibilities\n\nCompleting a task makes people feel ambitious, inspired, curious. Provide people with the incentive\nand excitement for continued growth in our apps.\n\nShow the possibilities of what can be accomplished by presenting them with next steps, or offer\nopportunities for advanced knowledge. This is always better than leaving people at a dead end.\n\n### Delight with unexpectedly pleasing experiences\n\nWe’re celebrating the success or progress of completing a task. Write to convey excitement. You are\ngiving a pat on the back for a job well done.\n\nBut remember not to overdo it. Timing and repetition are critical. Messages that appear more\nfrequently should be more concise and less delightful, for example clearing notifications. If\nmessages are appearing repeatedly, consider multiple versions. These are low commitment experiences,\nwe want to give flowers not puppies.\n\nMessages that appear after a bigger, optimistic action can be more playful, for example, a modal\ndialog. Remember that depending on the component you use, illustrations can also help to add a wink\nto your message.\n\n## Patterns and UX strategies\n\nIf an empty state has more than one potential cause or solution, try one of the following writing\nstrategies.\n\n### An empty state vs. a blank slate message\n\nAn empty state lets people know when they’ve completed or have cleared a task(s). By contrast, a\nblank slate is a type of message in which people have never come across or tried a new feature\nbefore. Blank slates promote and encourage people to try something new.\n\nUse text, design elements, and visual clues to differentiate where people are in their journeys.",
   keywords: ['empty state', 'messages', 'content', 'designing messages']
 }, {
-  content: 'An error message, different from a warning message, appears **after** someone has taken an action.\nThe message draws their attention to what has happened and what the consequences are, and what\npeople need to do to move forward. Optionally, they can also include why something happened and\nwhether the problem will occur again.\n\nWhen crafting an error message, remember that most people scan text instead of reading everything.\nMake every word count and avoid irrelevant details.\n\n## Writing best practices\n\n### Title\n\n- Titles are optional depending on the component you choose.\n- Include an informative, scannable title. Try and imagine people trying to understand what’s\n  happening by reading the title on its own.\n- Avoid explaining what to do.\n- Limit titles to three to four words where possible, excluding “an”, “a”, or “the”. The character\n  count will depend on the component you choose.\n- Write in sentence case with appropriate punctuation.\n\n### Body\n\n- Include: the reason for the error and the problem, how someone should act and what happens if they\n  don’t act.\n- If you don’t know the reason for an error, don’t make one up – just say that something’s gone\n  wrong and offer a solution for what people can do.\n- Avoid repeating content from the title.\n- Keep messages to 1 to 2 sentences.\n- Avoid putting technical information in the message or having people look in another location. If\n  it can\'t be avoided, use a link to support content.\n\n<DoDont type="do" image={{ url: errorMessagesBodyDo, alt: \'\' }} />\n<DoDont type="dont" image={{ url: errorMessagesBodyDont, alt: \'\' }} />\n\n### Call to action (CTA)\n\n- When an error message invokes a choice, use imperative verbs such as “Save”, “Remove”, or\n  “Create”, in the CTA to describe what action people will be making instead of vague terms such as\n  “OK”.\n- An option to dismiss or cancel lets people feel reassured that they can opt out.\n- Limit your CTA to 1 or 2 words.\n\n## Voice and tone\n\nErrors are high-stakes situations. They can be frustrating at a minimum, or catastrophic at their\nworst – especially when they involve work.\n\nYou want to leave people feeling supported and reassured. Convey an error message with empathy and\ntact. The correct level of urgency will let people understand how to respond. Follow some of the\nfollowing\n[Atlassian voice and tone principles](https://atlassian.design/foundations/content/voice-tone) to\nbuild your message:\n\n### Inform to build trust\n\nBe open and clear about what\'s happening in the app. Be aware that your reader could be new or\nconfused, and tone down the boldness by being more prescriptive.\n\n<DoDont type="do" image={{ url: errorMessagesTrustDo, alt: \'\' }} />\n<DoDont type="dont" image={{ url: errorMessagesTrustDont, alt: \'\' }} />\n\nTreat errors as an opportunity to educate people. Help them understand why they’re experiencing\nsomething and how they can avoid similar issues in the future. You may even be able to teach them\nsomething that can help them understand and manage the technology they use beyond our apps.\n\n### Encourage people along the path\n\nBe consistent and dependable. Avoid messaging that focuses on the problem without offering a\nsolution or way forward. Focus on next steps where possible and stay away from negative words or\nphrases.\n\n<DoDont type="do" image={{ url: errorMessagesEncourageDo, alt: \'\' }} />\n<DoDont type="dont" image={{ url: errorMessagesEncourageDont, alt: \'\' }} />\n\nUse _we_ instead of _you_, as emphasizing the relationship between the person and the problem could\nmake them feel like they’re being held responsible.\n\n### Satisfy by meeting expectations\n\nProvide quick and thorough answers, guidance, actions, and instructions. Give them the information\nthey need then get out of their way.\n\n<DoDont type="do" image={{ url: errorMessagesExpectationsDo, alt: \'\' }} />\n<DoDont type="dont" image={{ url: errorMessagesExpectationsDont, alt: \'\' }} />\n\nAvoid using “please” and “sorry”. Saying "sorry" in error messages can make the situation worse by\ncausing errors to appear more severe than they actually are. Similarly, saying "please" can\nundermine the authority and credibility of your message and lead people to think a required step is\noptional. Unless the error has severe and irreparable consequences, avoid niceties.\n\n## Patterns and UX strategies\n\nIf the error has more than one potential cause or solution, try one of the following writing\nstrategies.\n\n### A warning message vs. an error message\n\nAn error message alerts people of a problem that has already occurred. By contrast, a warning\nmessage alerts people of a condition that might cause a problem in the future.\n\nUse text, design elements, and visual clues to differentiate the difference between where people are\nin their journeys.\n\n### Offer a backup solution\n\nStick to the most likely cause or the simplest solution in the first sentence of the error message\nand offer an alternative backup solution in the second sentence in case the error keeps occurring\n(for example, contacting support). Try to reframe the error as an opportunity to inspire trust and\nconfidence.\n\n<DoDont type="do" image={{ url: errorMessagesBackupDo, alt: \'\' }} />\n<DoDont type="dont" image={{ url: errorMessagesBackupDont, alt: \'\' }} />\n\n### Reveal additional information gradually\n\nFor dead ends, start with something short but kind, and add context or other details only if the\nerror will reoccur.\n\n## Related components\n\nUse error messages in the following components:\n\n- [Flag](https://atlassian.design/components/flag/examples)\n- [Inline message](https://atlassian.design/components/inline-message/examples)\n- [Modal dialog](https://atlassian.design/components/modal-dialog/examples)\n- [Section message](https://atlassian.design/components/section-message/)\n\n## Accessibility\n\n- Use alternative text for illustrations and symbols in your messages\n- Avoid jargon and use simple language\n- Make links as descriptive as possible\n- Make text easily scannable to highlight key information.',
+  content: 'An error message, different from a warning message, appears **after** someone has taken an action.\nThe message draws their attention to what has happened and what the consequences are, and what\npeople need to do to move forward. Optionally, they can also include why something happened and\nwhether the problem will occur again.\n\nWhen crafting an error message, remember that most people scan text instead of reading everything.\nMake every word count and avoid irrelevant details.\n\n## Writing best practices\n\n### Title\n\n- Titles are optional depending on the component you choose.\n- Include an informative, scannable title. Try and imagine people trying to understand what’s\n  happening by reading the title on its own.\n- Avoid explaining what to do.\n- Limit titles to three to four words where possible, excluding “an”, “a”, or “the”. The character\n  count will depend on the component you choose.\n- Write in sentence case with appropriate punctuation.\n\n### Body\n\n- Include: the reason for the error and the problem, how someone should act and what happens if they\n  don’t act.\n- If you don’t know the reason for an error, don’t make one up – just say that something’s gone\n  wrong and offer a solution for what people can do.\n- Avoid repeating content from the title.\n- Keep messages to 1 to 2 sentences.\n- Avoid putting technical information in the message or having people look in another location. If\n  it can\'t be avoided, use a link to support content.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: errorMessagesBodyDo, alt: \'\' }} />\n\t<DoDont type="dont" image={{ url: errorMessagesBodyDont, alt: \'\' }} />\n</DoDontGrid>\n\n### Call to action (CTA)\n\n- When an error message invokes a choice, use imperative verbs such as “Save”, “Remove”, or\n  “Create”, in the CTA to describe what action people will be making instead of vague terms such as\n  “OK”.\n- An option to dismiss or cancel lets people feel reassured that they can opt out.\n- Limit your CTA to 1 or 2 words.\n\n## Voice and tone\n\nErrors are high-stakes situations. They can be frustrating at a minimum, or catastrophic at their\nworst – especially when they involve work.\n\nYou want to leave people feeling supported and reassured. Convey an error message with empathy and\ntact. The correct level of urgency will let people understand how to respond. Follow some of the\nfollowing\n[Atlassian voice and tone principles](https://atlassian.design/foundations/content/voice-tone) to\nbuild your message:\n\n### Inform to build trust\n\nBe open and clear about what\'s happening in the app. Be aware that your reader could be new or\nconfused, and tone down the boldness by being more prescriptive.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: errorMessagesTrustDo, alt: \'\' }} />\n\t<DoDont type="dont" image={{ url: errorMessagesTrustDont, alt: \'\' }} />\n</DoDontGrid>\n\nTreat errors as an opportunity to educate people. Help them understand why they’re experiencing\nsomething and how they can avoid similar issues in the future. You may even be able to teach them\nsomething that can help them understand and manage the technology they use beyond our apps.\n\n### Encourage people along the path\n\nBe consistent and dependable. Avoid messaging that focuses on the problem without offering a\nsolution or way forward. Focus on next steps where possible and stay away from negative words or\nphrases.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: errorMessagesEncourageDo, alt: \'\' }} />\n\t<DoDont type="dont" image={{ url: errorMessagesEncourageDont, alt: \'\' }} />\n</DoDontGrid>\n\nUse _we_ instead of _you_, as emphasizing the relationship between the person and the problem could\nmake them feel like they’re being held responsible.\n\n### Satisfy by meeting expectations\n\nProvide quick and thorough answers, guidance, actions, and instructions. Give them the information\nthey need then get out of their way.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: errorMessagesExpectationsDo, alt: \'\' }} />\n\t<DoDont type="dont" image={{ url: errorMessagesExpectationsDont, alt: \'\' }} />\n</DoDontGrid>\n\nAvoid using “please” and “sorry”. Saying "sorry" in error messages can make the situation worse by\ncausing errors to appear more severe than they actually are. Similarly, saying "please" can\nundermine the authority and credibility of your message and lead people to think a required step is\noptional. Unless the error has severe and irreparable consequences, avoid niceties.\n\n## Patterns and UX strategies\n\nIf the error has more than one potential cause or solution, try one of the following writing\nstrategies.\n\n### A warning message vs. an error message\n\nAn error message alerts people of a problem that has already occurred. By contrast, a warning\nmessage alerts people of a condition that might cause a problem in the future.\n\nUse text, design elements, and visual clues to differentiate the difference between where people are\nin their journeys.\n\n### Offer a backup solution\n\nStick to the most likely cause or the simplest solution in the first sentence of the error message\nand offer an alternative backup solution in the second sentence in case the error keeps occurring\n(for example, contacting support). Try to reframe the error as an opportunity to inspire trust and\nconfidence.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: errorMessagesBackupDo, alt: \'\' }} />\n\t<DoDont type="dont" image={{ url: errorMessagesBackupDont, alt: \'\' }} />\n</DoDontGrid>\n\n### Reveal additional information gradually\n\nFor dead ends, start with something short but kind, and add context or other details only if the\nerror will reoccur.\n\n## Related components\n\nUse error messages in the following components:\n\n- [Flag](https://atlassian.design/components/flag/examples)\n- [Inline message](https://atlassian.design/components/inline-message/examples)\n- [Modal dialog](https://atlassian.design/components/modal-dialog/examples)\n- [Section message](https://atlassian.design/components/section-message/)\n\n## Accessibility\n\n- Use alternative text for illustrations and symbols in your messages\n- Avoid jargon and use simple language\n- Make links as descriptive as possible\n- Make text easily scannable to highlight key information.',
   keywords: ['error messages', 'errors', 'content', 'designing messages']
 }, {
   content: 'These messages highlight a new or recently updated experience. Let people know what\'s changed, and\ninvite them to try something new. A feature discovery message should leave your reader feeling\ncurious, excited, and empowered.\n\nFor more guidance on this messaging type, see the new or updated feature pattern.\n\n## Tips and tricks\n\n- When introducing the new feature, consider what the user is trying to accomplish, what they were\n  just doing, and where they need to go.\n- Titles and messages should clearly indicate user benefits. For example, "Find your work faster"\n  instead of "New search".\n- This should be a positive experience for people, so it\'s okay to be delightful, just don\'t overdo\n  it.\n\n## Voice and tone\n\nDetermine if you need to inform (a feature has moved) or educate (the experience or interaction has\nchanged). Introduce the change, communicate its benefits, and provide a call to action if\nappropriate\n\nBe bold and optimistic about a new feature, especially if there are benefits and improvements for\nthe user. Be clear and practical, and you can add a little “wink” to entice the user to try\nsomething new.\n\n## Examples\n\nThe information flag below promotes the updated search feature, giving the option of learning more\nor trying out the new search.\n\n<img src={featureDiscoveryFlag} alt="Information flag to highlight a new search feature." />\n\nThis example encourages and empowers the user to begin using Jira as intended by adding work items.\n\n<img\n\tsrc={featureDiscoveryStart}\n\talt="Information modal promoting how to add a work item to Jira."\n/>\n\nThis Bitbucket example encourages people to improve their Bitbucket experience by adding branch\npermissions. It clearly states the benefits and ideal state of using this feature.\n\n<img\n\tsrc={featureDiscoveryBitbucket}\n\talt="An information modal for BitBucket highlighting how to add a branch permission."\n/>\n\n## Related components\n\n- [Flag](https://atlassian.design/components/flag/examples)\n- [Benefits modal](https://atlassian.design/components/onboarding/benefits-modal/usage)\n- [Spotlight](https://atlassian.design/components/onboarding/usage)',
@@ -35,15 +56,60 @@ var guidelinesStructuredContent = exports.guidelinesStructuredContent = [{
   content: "A success message appears after someone has taken an action or completed a task. The message is an\nopportunity to confirm the action or congratulate them.\n\nWhen crafting a success message, remember that most people scan text instead of reading everything.\nMake every word count and avoid irrelevant details.\n\n## Writing best practices\n\n### Title\n\n- Titles are optional depending on the component you choose. Avoid using “Success!” or\n  “successfully” in a title.\n- Include an informative, scannable title. Try and imagine people trying to understand what’s\n  happening by reading the title on its own.\n- Limit titles to three to four words where possible, excluding “an”, “a”, or “the”. The character\n  count will depend on the component you choose.\n- Write in sentence case and no use of periods.\n- Avoid using exclamations! We don't want to be overly enthusiastic about everything!\n\n### Body\n\n- Include the reason for the success — confirm what action someone has taken or what task has been\n  completed. If someone has created something give them an opportunity to view it.\n- Avoid repeating content from the title.\n- Keep messages to 1 to 2 sentences. Use a few words of praise followed by one or two sentences of\n  informative insight.\n- Avoid putting technical information in the message or having people look in another location. If\n  it can't be avoided, use a link to support content.\n\nIt’s important to show possibility once someone has achieved something. We want to tell people the\nresult of something, for example ‘you’ve closed the ticket'; how to undo it, for example, ‘ask your\nspace admin to restore the page, if needed’; and the step forward if possible, for example ‘View\nyour new space or set the permissions on your new space’.\n\n### Call to action (CTA)\n\n- CTAs are often optional unless there are any follow-up options. Don’t include a CTA unnecessarily.\n- Always give people an option to dismiss the message.\n- When a success message invokes a choice, use imperative verbs such as “Save”, “Remove”, or\n  “Create”, in the CTA to describe what action people will be making instead of vague terms such as\n  “OK”.\n- Limit your CTA to 1 or 2 words.\n\n## Voice and tone\n\nSuccess messages should leave people feeling empowered, motivated, and satisfied with their efforts.\n\nYou want to confirm the outcome and then get out of people’s way. Follow some of the following\n[Atlassian Voice and Tone principles](https://atlassian.design/foundations/content/voice-tone) to\nbuild your message:\n\n**Delight with unexpectedly pleasing experiences**\n\nWe’re celebrating success or progress once we’ve built trust. Write to convey excitement. You are\ngiving a pat on the back for a job well done.\n\nBut remember not to overdo it. Timing and repetition are critical. Success messages that appear more\nfrequently should be more concise and have less delight. If messages are appearing repeatedly,\nconsider multiple versions if you want to add some humor. These are low commitment experiences, we\nwant to give flowers not puppies.\n\nMessages that appear after a bigger, optimistic action can be more playful, for example a modal\ndialog. Remember that depending on the component you use, illustrations can also help to add a wink\nto your message.\n\n## Related components\n\nUse success messages in the following components:\n\n- [Flag](https://atlassian.design/components/flag/examples)\n- [Banner](https://atlassian.design/components/banner/examples)\n- [Inline message](https://atlassian.design/components/inline-message/examples)\n- [Modal dialog](https://atlassian.design/components/modal-dialog/examples)\n- [Section message](https://atlassian.design/components/section-message/)\n\n## Accessibility\n\n- Use alternative text for illustrations and symbols in your messages.\n- Avoid jargon and use simple language.\n- Make links as descriptive as possible.\n- Make text easily scannable to highlight key information.",
   keywords: ['success messages', 'content', 'designing messages']
 }, {
-  content: "A warning message, different from error messages, appears **before** someone takes an action to\nindicate a significant change or potential loss of data. It draws their attention to a potential\nproblem that may or may not require an action on the user’s part.\n\nWhen crafting warning messages, remember that most people scan text instead of reading everything.\nMake every word count and avoid irrelevant details.\n\n## Writing best practices\n\n### Titles\n\n- Titles are optional depending on the component you choose.\n- Include an informative, scannable title. People should understand what’s happening by reading the\n  title on its own.\n- Avoid explaining what to do.\n- Limit titles to three to four words where possible, excluding “an”, “a”, or “the”. The character\n  count will depend on the component you choose.\n- Write in sentence case with appropriate punctuation.\n\n<DoDont type=\"do\" image={{ url: warningMessagesTitlesDo, alt: '' }}>\n\tYour bill may increase\n</DoDont>\n<DoDont type=\"dont\" image={{ url: warningMessagesTitlesDont, alt: '' }}>\n\tTime to pay up!\n</DoDont>\n\nBy giving people this warning before they add extra members to their team you’re giving them a\nchance to reconsider their options after having all the information. Avoid using a wink in instances\nwhere there could be a problem for people.\n\n### Body copy\n\n- Include: the reason for the warning and the potential problem, how someone should act, and what\n  happens if they don’t act.\n- If you don’t know the reason for a warning, don’t make one up – just say that something’s gone\n  wrong and offer a solution for what they can do.\n- Avoid repeating content from the title.\n- Keep messages to 1 to 2 sentences.\n- Avoid people having to look in another location for more information. If this can't be avoided,\n  use a link to support content.\n\n<DoDont type=\"do\" image={{ url: warningMessagesBodyDo, alt: '' }}>\n\tWe’re running into some difficulties\n</DoDont>\n<DoDont type=\"dont\" image={{ url: warningMessagesBodyDont, alt: '' }}>\n\tYou’ve lost connection\n</DoDont>\n\nUse “we’re” instead of “you’re” to avoid blaming people for issues in the app.\n\n### Call to action (CTA)\n\n- When a warning message invokes a choice, use imperative verbs such as “Save”, “Remove”, or\n  “Create”, in the CTA to describe what action people will be making instead of vague terms such as\n  “Done”.\n- An option to dismiss or cancel lets people feel reassured that they can opt-out.\n- Limit your CTA to 1 or 2 words.\n\n## Voice and tone\n\nYou want to leave people feeling informed, supported and reassured. Convey the correct level of\nurgency and make sure they understand how to respond. Follow the\n[Atlassian voice and tone principles](https://atlassian.design/foundations/content/voice-tone) to\nbuild your message:\n\n### Inform to build trust\n\nInform, but don't alarm. If the warning comes before an action, clearly communicate what will happen\nif the action is taken.\n\n### Encourage them along the path\n\nGive clear, concise advice on which path to take and describe and provide alternatives if possible.\n\n### Satisfy by meeting expectations\n\nUse language that sounds and feels human, is natural and accessible. Explains the situation clearly\nand without assuming they have any advanced knowledge.\n\n## Patterns and UX strategies\n\nConsider the context in which the message appears. The type of warning message required will change\ndepending on the risk, consequences, and immediacy of the problem.\n\n### Raise awareness\n\nWarning messages make people aware of a condition or potential problem, even if they don't have to\ntake immediate action.\n\n<DoDont type=\"do\" image={{ url: warningMessagesAwarenessDo, alt: '' }}>\n\tPayment details needed\n</DoDont>\n<DoDont type=\"dont\" image={{ url: warningMessagesAwarenessDont, alt: '' }}>\n\tWe’re going to close your account\n</DoDont>\n\nThis message describes the condition or problem, the implications and their importance, and offers a\nbutton to dismiss the message.\n\n### Highlight an imminent problem\n\nThis is when someone needs to act immediately to prevent an issue.\n\nHere the message describes what people need to do, explains the condition and why it’s important,\nand offers a button for each of the options.\n\nIt's important to give people a timeline in which to make a certain change. You don’t want to create\npanic and rush people into making changes.\n\n### Confirm a risky action\n\nThis message should ask people whether they want to proceed, explain any reasons why they may not\nwish to proceed, and offer commit buttons for proceeding or canceling an action. You should also\ninform them whether any actions they take can be easily undone.\n\n<DoDont type=\"do\" image={{ url: warningMessagesConfirmDo, alt: '' }}>\n\tConfirm a risky action\n</DoDont>\n<DoDont type=\"dont\" image={{ url: warningMessagesConfirmDont, alt: '' }}>\n\tRisky action\n</DoDont>\n\n## Related components\n\nUse warning messages in the following components:\n\n- [Banner](https://atlassian.design/components/banner/examples)\n- [Flag](https://atlassian.design/components/flag/examples)\n- [Inline message](https://atlassian.design/components/inline-message/examples)\n- [Modal dialog](https://atlassian.design/components/modal-dialog/examples)\n- [Section message](https://atlassian.design/components/section-message/)\n\n## Accessibility\n\n- Use alternative text for illustrations and symbols in your messages\n- Avoid jargon and use simple language\n- Make links as descriptive as possible\n- Make text easily scannable to highlight key information.",
+  content: "A warning message, different from error messages, appears **before** someone takes an action to\nindicate a significant change or potential loss of data. It draws their attention to a potential\nproblem that may or may not require an action on the user’s part.\n\nWhen crafting warning messages, remember that most people scan text instead of reading everything.\nMake every word count and avoid irrelevant details.\n\n## Writing best practices\n\n### Titles\n\n- Titles are optional depending on the component you choose.\n- Include an informative, scannable title. People should understand what’s happening by reading the\n  title on its own.\n- Avoid explaining what to do.\n- Limit titles to three to four words where possible, excluding “an”, “a”, or “the”. The character\n  count will depend on the component you choose.\n- Write in sentence case with appropriate punctuation.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: warningMessagesTitlesDo, alt: '' }}>\n\t\tYour bill may increase\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: warningMessagesTitlesDont, alt: '' }}>\n\t\tTime to pay up!\n\t</DoDont>\n</DoDontGrid>\n\nBy giving people this warning before they add extra members to their team you’re giving them a\nchance to reconsider their options after having all the information. Avoid using a wink in instances\nwhere there could be a problem for people.\n\n### Body copy\n\n- Include: the reason for the warning and the potential problem, how someone should act, and what\n  happens if they don’t act.\n- If you don’t know the reason for a warning, don’t make one up – just say that something’s gone\n  wrong and offer a solution for what they can do.\n- Avoid repeating content from the title.\n- Keep messages to 1 to 2 sentences.\n- Avoid people having to look in another location for more information. If this can't be avoided,\n  use a link to support content.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: warningMessagesBodyDo, alt: '' }}>\n\t\tWe’re running into some difficulties\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: warningMessagesBodyDont, alt: '' }}>\n\t\tYou’ve lost connection\n\t</DoDont>\n</DoDontGrid>\n\nUse “we’re” instead of “you’re” to avoid blaming people for issues in the app.\n\n### Call to action (CTA)\n\n- When a warning message invokes a choice, use imperative verbs such as “Save”, “Remove”, or\n  “Create”, in the CTA to describe what action people will be making instead of vague terms such as\n  “Done”.\n- An option to dismiss or cancel lets people feel reassured that they can opt-out.\n- Limit your CTA to 1 or 2 words.\n\n## Voice and tone\n\nYou want to leave people feeling informed, supported and reassured. Convey the correct level of\nurgency and make sure they understand how to respond. Follow the\n[Atlassian voice and tone principles](https://atlassian.design/foundations/content/voice-tone) to\nbuild your message:\n\n### Inform to build trust\n\nInform, but don't alarm. If the warning comes before an action, clearly communicate what will happen\nif the action is taken.\n\n### Encourage them along the path\n\nGive clear, concise advice on which path to take and describe and provide alternatives if possible.\n\n### Satisfy by meeting expectations\n\nUse language that sounds and feels human, is natural and accessible. Explains the situation clearly\nand without assuming they have any advanced knowledge.\n\n## Patterns and UX strategies\n\nConsider the context in which the message appears. The type of warning message required will change\ndepending on the risk, consequences, and immediacy of the problem.\n\n### Raise awareness\n\nWarning messages make people aware of a condition or potential problem, even if they don't have to\ntake immediate action.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: warningMessagesAwarenessDo, alt: '' }}>\n\t\tPayment details needed\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: warningMessagesAwarenessDont, alt: '' }}>\n\t\tWe’re going to close your account\n\t</DoDont>\n</DoDontGrid>\n\nThis message describes the condition or problem, the implications and their importance, and offers a\nbutton to dismiss the message.\n\n### Highlight an imminent problem\n\nThis is when someone needs to act immediately to prevent an issue.\n\nHere the message describes what people need to do, explains the condition and why it’s important,\nand offers a button for each of the options.\n\nIt's important to give people a timeline in which to make a certain change. You don’t want to create\npanic and rush people into making changes.\n\n### Confirm a risky action\n\nThis message should ask people whether they want to proceed, explain any reasons why they may not\nwish to proceed, and offer commit buttons for proceeding or canceling an action. You should also\ninform them whether any actions they take can be easily undone.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: warningMessagesConfirmDo, alt: '' }}>\n\t\tConfirm a risky action\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: warningMessagesConfirmDont, alt: '' }}>\n\t\tRisky action\n\t</DoDont>\n</DoDontGrid>\n\n## Related components\n\nUse warning messages in the following components:\n\n- [Banner](https://atlassian.design/components/banner/examples)\n- [Flag](https://atlassian.design/components/flag/examples)\n- [Inline message](https://atlassian.design/components/inline-message/examples)\n- [Modal dialog](https://atlassian.design/components/modal-dialog/examples)\n- [Section message](https://atlassian.design/components/section-message/)\n\n## Accessibility\n\n- Use alternative text for illustrations and symbols in your messages\n- Avoid jargon and use simple language\n- Make links as descriptive as possible\n- Make text easily scannable to highlight key information.",
   keywords: ['warning messages', 'warnings', 'content', 'designing messages']
 }, {
-  content: '## Principles for inclusive language\n\n### Use words that reflect our diverse world\n\nInclusive language isn’t about following a list of good and bad words. It’s about taking an approach\nto your writing that avoids assumptions, stereotypes, and treats people with respect.\n\nOur apps are for all kinds of people. The words we use should help them have a great experience.\nConsider how your language is helping or harming people.\n\n### Make content easy to understand\n\nBe inclusive by using plain language. Remove jargon, metaphors, and idioms. Simple wording is proven\nto help people complete their tasks faster and with higher success rates. It also ensures that you\naren’t excluding people by using words that are specific to your context.\n\n### Learn from your audience\n\nRely on the expertise of people who belong to the groups you’re writing about. You can do this by\nreading resources put out by advocacy groups, or consulting with people from diverse communities.\nNever assume people from a diverse community want to educate or give feedback – always ask for\npermission first.\n\n## How to describe people\n\n### Be clear\n\nWhen you need to describe a group of people, use clear language that aligns with how people describe\nthemselves.\n\nWhen you’re not sure, always use person-first language. This language centers the person, rather\nthan their difference. For example, “people with disabilities”, rather than “disabled people” In\nsome circumstances people prefer to use identity-first language to represent themselves, such as in\nthe Deaf community.\n\nYou can reduce inaccurate assumptions or stereotypes by improving the way you describe people’s\ndifferences. For example:\n\n| Good                                                                                     | Better                                                                                       | Reason                                                                                                                                                   |\n| ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Alternative text helps people with visual disabilities interact with the user interface. | Alternative text helps people who use assistive technology interact with the user interface. | Not all people who use assistive technology, like screen readers have visual disabilities. Using this definition is more inclusive, and more accurate.   |\n| 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. |\n\n### Don’t change words used to describe people\n\nDon’t modify phrases to make differences sound positive. Words like “differently abled” or\n“handi-capable” are patronizing, and don’t fit with the full diversity of human experiences.\n\nAvoiding describing people’s differences can reinforce the prejudices of society. Describing race,\nethnicity, disability, age, class, gender, and sexuality isn’t a negative thing, unless these\ndescriptions are being used in discriminatory ways. For example, only use the phrase “people of\ncolor” when you don’t have enough information to be more specific.\n\n## Avoiding microaggressions\n\nMicroaggressions are actions that aren’t intentionally aggressive, but contribute towards an\nenvironment that excludes people towards people who belong to marginalized communities. This makes\npeople feel excluded, fatigued, and unseen.\n\nIn writing, microaggressions are words that are associated with stereotypes, or phrases that have a\nnegative origin, like “long time no see” – a phrase historically used to make fun of people who\nspoke limited English, which has now slipped into casual use.\n\nThese words may seem inoffensive to some people. Remember that our goal is to do more than just\navoid causing offense. We want to create apps that include all people.\n\n### Avoid metaphors and idioms\n\nMetaphors and idioms are non-literal phrases people use in regular speech. Metaphors are when people\ncompare something to something else (such as “they were like a fish out of water”), while idioms are\nphrases where the meaning isn’t conveyed by any of the words (such as “between a rock and a hard\nplace”). Idioms are only understood from cultural familiarity with the phrase, which makes them\nunhelpful if you’re writing for a global audience.\n\nSome metaphors and idioms invoke histories of violence, patriarchy, or colonization. Other metaphors\nand idioms can confuse people outside of the group, country, or culture the phrase originates from.\nThis creates an environment that includes some people more than others.\n\nWhen you’re writing content for a wide audience, be literal. Don’t rely on harmful or confusing\nphrases.\n\n| Example                                                      | Alternative                                      | Reason                                                                                                                                                                                                                                 |\n| ------------------------------------------------------------ | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| blacklist/whitelist                                          | blocklist/allowlist                              | Associating “black” with negative and “white” with positive experiences perpetuates racial inequity.                                                                                                                                   |\n| killing it                                                   | doing great work                                 | Violent words are unnecessary, and can cause negative feelings.                                                                                                                                                                        |\n| Automation in Jira makes work item creation a piece of cake. | Automation helps teams create work items faster. | Some people won’t have heard the phrase “piece of cake” used this way before, especially if English isn’t their first language. This creates an unnecessary barrier to comprehension that you can avoid by being accurate and literal. |\n\n### Word use, appropriation, and reclamation\n\nThe context and identity of the person using a word or phrase can change whether a word or phrase is\nhelpful or harmful. Sometimes words are used for their original purpose, sometimes they are\nappropriated, and sometimes words are reclaimed.\n\nAppropriation is when words are used outside of their original context in ways that are hurtful or\nminimizing to a group of people.\n\n| Appropriation                           | Proper use                                 | Reason                                                                                                            |\n| --------------------------------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- |\n| Let’s have a powwow about the new logo. | I’m taking leave to attend a powwow.       | Powwows are important cultural gatherings, and using this as a throwaway word to describe a meeting is offensive. |\n| I’m so OCD about deleting my emails.    | My experiences getting diagnosed with OCD. | Avoid using medical and disability related terms as metaphors. It reinforces negative stereotypes.                |\n\nReclamation is when a group starts using language that people previously used to harm them, with the\nintention to make it a positive word or phrase. For example, the word ‘queer’ was previously used as\na homophobic term, but now many people describe themselves with the word ‘queer’. Don’t use these\nwords if you don’t belong to the group the word originates from.\n\n### Don’t make assumptions about abilities\n\nDon’t use phrasing that makes assumptions about how people experience your app. For example, by\nmaking claims about how easy your experience is.\n\n| Example                           | Alternative                             | Reason                                                                                               |\n| --------------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------- |\n| It’s easy to set up your project. | Set up your new project in a few steps. | It’s more precise about why the workflow is easy, without excluding people based on their abilities. |\n\n### Words that are misinterpreted as microaggressions\n\nDesigners avoid some words related to disabilities because they’re trying to be inclusive. These\nwords aren\'t microaggressions because words that relate to disabilities aren’t negative words. You\nonly need to avoid using them in a negative context.\n\nYou can use them if they help make things clear.\n\n| Phrasing                                                                                                                | Reason                                                                                                                                                                                                                                                        |\n| ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Words related to vision, like: "View all Jira work items", "Watch the webinar recording", and "See what Trello can do". | People who are blind or low vision aren’t excluded by these words. They still ‘view’ a list of items, in a different way. Where it makes sense to do so, avoid these words. You don’t need to remove them if they’re accurate.                                |\n| 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 good. |\n\n## Techniques for inclusive app experiences\n\n### Use they/them pronouns, and gender neutral language\n\nWhen referring to a person, use the pronouns they tell you to use. When referring to a person or a\ngroup of people you don’t know, use they/them pronouns. This makes the app more gender inclusive.\n\n| Example                                                                     | Alternative                                                            | Reason                                                          |\n| --------------------------------------------------------------------------- | ---------------------------------------------------------------------- | --------------------------------------------------------------- |\n| Ask your project admin to enable editing permissions on his or her account. | Ask your project admin to enable editing permissions on their account. | Using they/them pronouns is more inclusive, and easier to read. |\n\n### Build inclusive forms\n\nWhen you gather data about people, remember that pre-defined categories don’t accurately reflect the\ndiversity of our world. Form fields can prevent people from using software if they\'re unable to fit\ninto the schemas we’ve defined for them.\n\nIf you need to collect information about people’s identities, give people the option to choose not\nto answer, or to give a self-defined answer. When gathering information about names, use a “Full\nname” field instead of separating names by first name, last name, and salutation.\n\nAvoid setting any particular group of people as the default option. This implies that other groups\nare not the norm, not common, or forces them to navigate and configure things more than others.\n\nOne way to avoid this is by not asking for more information than necessary. Often detailed personal\ninformation isn’t relevant to our apps, so ask yourself if you really need people to identify or\ngroup themselves before building this into apps.\n\n### Be accurate\n\nIt can be tempting to keep visual labels short, and hide the descriptive information behind an\naria-label. We’re moving away from this approach, because descriptive language also improves the\nexperience for people who don’t use assistive technology.\n\n| Example                                                                                                                                                            | Alternative                                                                                                                                                                          | Reason                                                                                                                                                                                                        |\n| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Ask Atlassian Intelligence about a project or topic within your company’s knowledge base. [Learn more](https://www.atlassian.com/platform/artificial-intelligence) | Ask Atlassian Intelligence about a project or topic within your company’s knowledge base. [About Atlassian Intelligence](https://www.atlassian.com/platform/artificial-intelligence) | Accurate, descriptive links reduce the cognitive burden we put onto people using our apps. For more examples, read [alternatives to “learn more” (Atlassians only)](https://go.atlassian.com/learn-more-alt). |\n| Atlassian Intelligence is great for speeding up your work, and helping you be productive.                                                                          | 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.                                                                            |\n| Step 1                                                                                                                                                             | Create project (Step 1 of 3)                                                                                                                                                         | Describe tasks accurately, so that people know where they are in their workflow.                                                                                                                              |\n\n### Write helpful examples\n\nIt can be tempting to use the example text for form fields or search boxes to add fun and delight to\nan app or platform.\n\nIf your example includes an example company name or task, make sure that these are accurate enough\nto convey what the example is showing.\n\n| Example                                                                         | Alternative                                                                              | Reason                                                                                                                |\n| ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |\n| Ask AI a question, like “Show me all work items in the ‘Donut Plains’ project.” | Ask AI a question, like “Show me all work items in the ‘Snack Delivery System’ project.” | It’s okay to make your examples fun, but don’t let specific cultural references make it confusing! Keep it universal. |\n\n### Make alt text concise and consistent\n\nIf images provide information, always include alternative text (“alt text”). When you’re writing\nalternative text, consider how that text will change the screen reader experience.\n\nIf you’re working on an app experience with elements that are very repetitive, like iconography,\ndon’t make alternative text too wordy as this will make the experience worse for people who use\nassistive technology. For example:\n\n| Not enough information | Too much information                                          | Just right       |\n| ---------------------- | ------------------------------------------------------------- | ---------------- |\n| Question mark          | Jira customer support question. Created by Jira service desk. | Support question |\n\nIf you’re using the same visuals in multiple places, make sure that you use the same alt text every\ntime it appears. The design system helps with this by providing label guidelines for components like\n[modal dialogs](https://atlassian.design/components/modal-dialog/examples) and\n[spinners](https://atlassian.design/components/spinner/examples).\n\n## Use reference material\n\nLanguage is changing all the time, so we don’t maintain a list of terms to use or avoid. Use\nresources like the\n[APA Inclusive Language Guide](https://www.apa.org/about/apa/equity-diversity-inclusion/language-guidelines)\nor\n[AP Stylebook](https://www.apstylebook.com/ap_stylebook?az_chapter=71&other_chapter=150#chapter_other_tab)\nto learn about specific terms.\n\n<SectionMessage title="We\'ve reorganized this website">\n\tThese guidelines are here to help you use inclusive language when designing apps and platforms.\n\tYou can access the{\' \'}\n\t<Link href="https://go.atlassian.com/global-inclusive-language">\n\t\tarchived global inclusive language guidelines (Atlassians only)\n\t</Link>\n\t, these are deprecated and will be replaced in the future.\n</SectionMessage>',
+  content: '<SectionMessage title="">\n\tThese guidelines are for UI and app content. For broader guidance on inclusive language, view Brand’s{\' \'}\n\t<Link href="https://go.atlassian.com/inclusive-language-guide">\n\t\tInclusive Language Guidelines (Atlassians only)\n\t</Link>\n</SectionMessage>\n\n## Design principles for inclusive language\n\nInclusive 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.\n\n### Make content easy to understand\n\nUse plain language. Simple wording is more inclusive and helps people complete their tasks faster and with higher success rates.\n\nDon’t use [metaphors, idioms](#avoid-metaphors-and-idioms), or jargon.\n\n### Use person-first language when you can’t ask\n\nWhen 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’.\n\nHowever, 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.\n\n### Don’t make assumptions about abilities\n\nDon’t use phrasing that makes assumptions about how people experience your app.\n\nFor example, by making claims about how easy an experience is, it’s less precise and can exclude people based on their abilities.\n\n<DoDontGrid>\n\t<DoDont type="do">Set up your new project in a few steps.</DoDont>\n\t<DoDont type="dont"> It’s easy to set up a new project.</DoDont>\n</DoDontGrid>\n\n### Avoid metaphors and idioms\n\nMetaphors and idioms are non-literal phrases used in regular speech.\n- Metaphors are when people compare something to something else (such as ‘they were like a fish out of water’)\n- Idioms are phrases where the meaning isn’t conveyed by any of the words (such as ‘between a rock and a hard place’).\n\nThey 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.\n\n<DoDontGrid>\n\t<DoDont type="do">Automation helps teams create work items faster.</DoDont>\n\t<DoDont type="dont"> Automation makes creating work items a piece of cake.</DoDont>\n\t<DoDont type="do">Confluence has many useful features.</DoDont>\n\t<DoDont type="dont"> Confluence has more features than you can poke a stick at.</DoDont>\n</DoDontGrid>\n\n## How to describe people\n\n### Be clear\n\nWhen 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](#use-person-first-language-when-you-can’t-ask).\n\nYou can also reduce inaccurate assumptions or stereotypes by improving the way you describe people’s differences. For example:\n\n| Good                                                                                     | Better                                                                                       | Reason                                                                                                                                                   |\n| ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| 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. |\n| 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. |\n\n### Don’t change words used to describe people\n\nAvoiding describing people’s differences can reinforce the prejudices of society.\n\nDescribing 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.\n\nDon’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.\n\n## Words related to disabilities can still be inclusive\n\nDesigners 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.\n\nYou should avoid using them in a negative context, but you can use them if they help make things clear.\n\n| Words                                                                                                                | Reason                                                                                                                                                                                                                                                        |\n| ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| 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.                                |\n| 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. |\n\n## Techniques for inclusive experiences\n\n### Use they/them pronouns and gender-neutral language\n\n- When referring to a person, use the pronouns they tell you to use.\n- 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.\n\n<DoDontGrid>\n\t<DoDont type="do">Ask your project admin to enable editing permissions on their account.</DoDont>\n\t<DoDont type="dont"> Ask your project admin to enable editing permissions on his or her account.</DoDont>\n</DoDontGrid>\n\n\n### Make alt text concise and consistent\n\n- If images provide information, always include alternative text (‘alt text’) so people using assistive technologies can access it.\n- 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?\n- 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.\n\n\n### Write  accurate content, links, and labels\nUse accurate, descriptive language for content and links, as it reduces cognitive load and improves the experience for people who don’t use assistive technology.\n\nDon’t deliberately keep visual labels short and hide the descriptive information behind an aria-label.\n\n| Example                                                                                                                                                            | Alternative                                                                                                                                                                          | Reason                                                                                                                                                                                                        |\n| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Ask Rovo about a topic within your company’s knowledge base. [Learn more](https://www.atlassian.com/software/rovo). | Ask Rovo about a topic within your company’s knowledge base. [About Rovo](https://www.atlassian.com/software/rovo). | Accurate, descriptive links reduce people’s cognitive load.\n| 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.                                                                            |\n| Step 1                                                                                                                                                             | Create project (step 1 of 3)                                                                                                                                                         | Describe tasks accurately so people know where they are in their workflow.                                                                                                                              |\n<br></br>\n\n<SectionMessage title="">\n\tFor examples of descriptive links, read {\' \'}\n\t<Link href="https://go.atlassian.com/learn-more-alt">\n\t\tAlternatives to \'learn more\' (Atlassians only)\n\t</Link>\n</SectionMessage>\n\n### Gather form information thoughtfully\n\n- 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.\n- 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.\n- If you need to collect information about people’s identities, give them the option to not answer or to give a self-defined answer.\n- 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.\n- When gathering information about names, use a ‘Full name’ field instead of separating names by first name, last name, and salutation.\n\n## Additional resources\n\nLanguage is changing all the time, so we don’t maintain a list of terms to use or avoid. Instead, use resources like:\n- [APA Inclusive Language Guide](https://www.apa.org/about/apa/equity-diversity-inclusion/language-guidelines)\n- [Australian Government Style Manual](https://www.stylemanual.gov.au/accessible-and-inclusive-content/inclusive-language)',
   keywords: ['inclusive writing', 'inclusion', 'accessibility', 'content', 'language']
 }, {
-  content: '<SectionMessage title="Atlassian vocabulary">\n\tFor specific vocabulary and to view our internal word list and glossary, head to {\' \'}\n\t<Link href="https://go.atlassian.com/vocab">go/vocab (Atlassians only)</Link>.\n</SectionMessage>\n\n## Style and formatting\n\n### Abbreviations\n\n- Use the full name of features and apps in customer-facing copy.\n- Don’t use \'e.g.\', ‘i.e.’, ‘etc.’, or \'&\' as they\'re not localization friendly and can be confusing for users of assistive technologies.\n\n<DoDont type="do">Ask the experts at Jira Service Desk.</DoDont>\n<DoDont type="dont"> Ask the experts at JSD.</DoDont>\n\n<DoDont type="do">Use an input component. For example, a button or a select.</DoDont>\n<DoDont type="dont"> Use an input component, e.g. a button or a select etc.</DoDont>\n\n#### Plural abbreviations\nDon’t use an apostrophe for plural abbreviations.\n\n<DoDont type="do">1990s, DVDs</DoDont>\n<DoDont type="dont"> 1990’s, DVD’s</DoDont>\n\n### Articles (a, an, the)\n\nAvoid articles in buttons, labels, and action-based headings in the UI.\n\n<DoDont type="do">Create password</DoDont>\n<DoDont type="dont"> Create a password</DoDont>\n\n### Bold\n\nUse bold text to draw the reader’s eye to key phrases and statements in your content,\n  though don\'t over do it.\n- For in-app copy or help articles, use bold when referring to static UI elements like menu items,\n  buttons, or headings.\n- If bold is needed but the UI doesn’t support it — for example in a UI message or a flag where\n  the title is already bold — you can use [italics](#italics).\n\n<DoDont type="do">Go to <b>General configuration</b> then <b>User macros</b>.</DoDont>\n<DoDont type="dont">Go to the <b>settings page and select Configuration</b>.</DoDont>\n\n### Capitalization\n\n- Use sentence case in all titles, headings, menu items, labels, and buttons.\n- Capitalize proper nouns in headings, such as names of people, companies, or apps.\n\n<DoDont type="do">Create work item</DoDont>\n<DoDont type="dont">Create Work Item</DoDont>\n\n<DoDont type="do">Add permissions for Arni Karan</DoDont>\n<DoDont type="dont">Add permissions for arni karan</DoDont>\n\n### Contractions (shortened words)\n\n- Use contractions, where possible, as they convey a conversational, friendly tone.\n- Use curly apostrophes in UI copy\n\t- On a Mac: **option** + **shift** + **]**\n\t- On Windows: **Control** + **\'** (or **alt** + **0146**)\n\n<DoDont type="do">We can’t load this page.</DoDont>\n<DoDont type="dont">We cannot load this page.</DoDont>\n\n### Date and time\n\nView [date and time guidelines](https://atlassian.design/foundations/content/date-time).\n\n### Gender (he, she, they)\n\n- If known, use the pronouns a customer provides. If you don’t know, avoid gendered pronouns wherever\npossible.\n- If it’s not possible, use ’they’ or ’their’ rather than ‘his/her’ or ’he/she’.\n\n<DoDont type="do">Ask your admin to add you.</DoDont>\n<DoDont type="dont">Ask your admin if she can add you.</DoDont>\n\n<DoDont type="do">Add permissions to their account.</DoDont>\n<DoDont type="dont">Add permissions to her account.</DoDont>\n\n### Headings and titles\n\n- Use sentence case. Only capitalize the first word of a sentence, proper nouns, and trademarked\n  names (for example: apps, countries, people\'s names).\n- Don’t use bold or italics.\n- Don\'t use periods.\n- Reconsider using question marks. Preferably rephrase the heading so it’s a statement.\n- Phrase UI and documentation headings with an action verb.\n- Avoid gerunds (the ‘ing’ form of verbs) in UI copy.\n\n<DoDont type="do">Organize your to-do list with Trello</DoDont>\n<DoDont type="dont">Want to Organize <em>Your</em> To-Do List With Trello?</DoDont>\n\n<DoDont type="do">Add a page to your project</DoDont>\n<DoDont type="dont">Adding a page to your project</DoDont>\n\n#### Articles in headings\n\n- Articles (a, an, the) aren’t always needed in UI headings.\n- They\'re better suited to more conversational sections, like product marketing copy and empty states, as they make these sections more approachable and improve understanding.\n\n<DoDont type="do">Create work item</DoDont>\n<DoDont type="dont">Create a work item</DoDont>\n\n### Italics\n\nIn apps, use italics sparingly as it can be difficult to read. Don’t use italics in hyperlinks.\n\nItalics can be used for:\n- UI elements that might change, like a field name or user input.\n- For emphasis if the UI doesn’t support bold. For example, in a flag or UI message.\n\n### Lists\n\nUse lists to draw the reader’s eye and make items easier to scan and follow. Try to limit lists to 6 items or less. If there are more items, make multiple lists.\n\n#### Bulleted list\n\n- Use to list options or when the order of the items doesn’t matter.\n- Phrase each item in a parallel way.\n- Don’t use commas or periods at the end of each item.\n\n##### Fragmented sentences\n\nIf your list has fragmented sentences, use a lowercase letter for each item and don’t use a period at the end of the list. Use a lead-in sentence with a colon before the items.\n\n<DoDont type="do">\n\tDue to security concerns, all employees are required to:\n\t<ul>\n\t\t<li>wear an identification tag</li>\n\t\t<li>use their security pass to enter or leave an office before 7 a.m. and after 6 p.m.</li>\n\t\t<li>alert security if a suspicious package is found</li>\n\t</ul>\n</DoDont>\n\n<DoDont type="dont">\n\tDue to security concerns, all employees are required to;\n\t<ul>\n\t\t<li>Wear an identification tag in the building,</li>\n\t\t<li>You must use your identification tag to enter an office before 7 a.m. and exit after 6 p.m., and</li>\n\t\t<li>If a suspicious package is found, alert security.</li>\n\t</ul>\n</DoDont>\n\n##### Complete sentences\n\nFor lists with complete sentences, start an item with a capital letter and end it with a period. Don’t use a lead-in sentence with a colon.\n\n<DoDont type="do">\n\tAtlassian has updated security requirements for employees.\n\t<p></p>\n\t<ul>\n\t\t<li>Always wear your identification tag when working in an office.</li>\n\t\t<li>Use your identification tag to enter an office before 7 am and when you leave after 6 pm.</li>\n\t</ul>\n</DoDont>\n\n<DoDont type="dont">\n\tAtlassian has updated security requirements for employees:\n\t<ul>\n\t\t<li>always wear your identification tag when working in an office</li>\n\t\t<li>use your identification tag to enter an office before 7 am and when you leave after 6 pm.</li>\n\t</ul>\n</DoDont>\n\n#### Numbered lists\n\nUse numbered lists for tasks or lists where the order of the items matters. Capitalize the first word of each item and end the item with a period.\n\n<DoDont type="do">\n\tTo add a new user macro:\n\t<ol>\n\t\t<li>Go to <b>Settings</b> then <b>General configuration</b> then <b>User macros</b>.</li>\n\t\t<li>Choose <b>Create a user macro</b>.</li>\n\t\t<li>Enter the macro details.</li>\n\t</ol>\n</DoDont>\n\n<DoDont type="dont">\n\tTo add a new user macro -\n\t<ol>\n\t\t<li>go to <b>Settings</b> then <b>General configuration</b> then <b>User macros</b></li>\n\t\t<li>choose <b>Create a user macro</b></li>\n\t\t<li>enter the macro details.</li>\n\t</ol>\n</DoDont>\n\n### Monospaced text\n\nUse `monospaced font` for names of a file or directory. It’s mostly used in attributes, strings, and administrator and developer docs.\n\n<DoDont type="do">The location of the Home directory is stored in a configuration file called <code>confluence-init.properties</code>.</DoDont>\n<DoDont type="dont">The location of the Home directory is stored in a configuration file called <b>confluence-init.properties</b>.</DoDont>\n\n\n### Numbers\n\nUse digits rather than words in most cases.\n\n**Exceptions**:\n\n- If a number starts a sentence, write it out.\n- In common expressions, write the number out. For example: _It’s one thing after another_.\n- When writing long-form or formal content, write out numbers one to nine.\n- Write out the numbers ‘zero’ and ‘one’ if it could be confused for the letters L, I, or O.\n\n<DoDont type="do">Your password should be a minimum of 8 characters. </DoDont>\n<DoDont type="dont">Your password should be a minimum of eight characters.</DoDont>\n\n<DoDont type="do">Loom is one of the best apps for sharing information in a personal way.</DoDont>\n<DoDont type="dont">Loom is 1 of the best apps for sharing information in a personal way.</DoDont>\n\n#### Number ranges\n\nUse ’to’ and not hyphens in number ranges, except if space is limited, like in a table or mobile app.\n\n<DoDont type="do">View rows 1 to 4 in the table.</DoDont>\n<DoDont type="dont">View rows 1-4 in the table.</DoDont>\n\n#### Numbers \'out of\'\n\nUse ‘of’ rather than a forward slash ( / ) to show a number out of another number.\n\n<DoDont type="do">Step 1 of 2</DoDont>\n<DoDont type="dont">Step 1/2</DoDont>\n\n#### Numbers from 1,000\n\nUse a comma to indicate the thousand in a number.\n\n<DoDont type="do">\n\t<ul>\n\t\t<li>4,500</li>\n\t\t<li>10,000</li>\n\t\t<li>1,250,000</li>\n\t</ul>\n</DoDont>\n\n<DoDont type="dont">\n\t<ul>\n\t\t<li>4500</li>\n\t\t<li>10000</li>\n\t\t<li>1250000</li>\n\t</ul>\n</DoDont>\n\n### Spelling words\n\nUse US English in UI copy and code. Check spellings in [Merriam-Webster online dictionary](https://www.merriam-webster.com/).\n\n<DoDont type="do">\n\t<ul>\n\t\t<li>color</li>\n\t\t<li>organization</li>\n\t\t<li>labeled</li>\n\t</ul>\n</DoDont>\n\n<DoDont type="dont">\n\t<ul>\n\t\t<li>colour</li>\n\t\t<li>organisation</li>\n\t\t<li>labelled</li>\n\t</ul>\n</DoDont>\n\n### Truncation\n\nEllipses (…) are used to show that text has been cut off — or truncated — when a message doesn’t fit in a given space.\n- Avoid truncation whenever possible: shorten UI messages or wrap the text.\n- Test your designs using multiple screen widths and magnification levels to ensure it doesn’t truncate.\n- If truncation can’t be avoided, for example in user-generated content or icon buttons, use a [tooltip](https://atlassian.design/components/tooltip/examples) to display the full text for accessibility and usability.\n- In ADS components that truncate, the ellipsis appears without any space next to the last visible character (for example: Work in pro…).\n\n<DoDont type="do" image={{ url: truncationDo, alt: "" }}>\n    Shorten or wrap messages.\n</DoDont>\n<DoDont type="dont" image={{ url: truncationDont , alt: "" }}>\n    Don’t truncate unless it can’t be avoided.\n</DoDont>\n\n### UI elements\n\n- Use sentence case, even if the UI element doesn’t use it.\n- Use bold to emphasize the UI element in a step.\n- If the UI element has an icon, bold both the name and the icon.\n- Avoid using a > symbol where possible, as it is read out as “greater than” by assistive technologies, leading to confusion. Use ‘then’ instead.\n\n<DoDont type="do">Go to <b>More</b>, then <b>Link work item</b>. </DoDont>\n<DoDont type="dont">Go to <b>More</b> > <b>Link Work Item</b>. </DoDont>\n\n## Grammar\n\n### Active voice\n\nUse active voice whenever possible as it improves readability and reflects Atlassian’s [voice and tone](https://atlassian.design/foundations/content/voice-tone).\n\nActive voice:\n- puts the emphasis on the person or thing doing an action.\n- makes content shorter, clearer, friendlier, and more conversational.\n\n<DoDont type="do">Administrators control access to Atlassian Cloud applications.</DoDont>\n<DoDont type="dont">Access to Atlassian Cloud applications is controlled by administrators.</DoDont>\n\n### Pronouns (you, your, we)\n\n- Minimize the use of pronouns.\n- Most of the time they can be avoided. However, when advising a user, indicating that something in the UI is theirs, or in error messages, you can use ‘you’ or ’your’ or ’we’ for a friendlier tone.\n\n<DoDont type="do">Get access to your work items here.</DoDont>\n<DoDont type="dont">Get access to the work items here.</DoDont>\n\n<DoDont type="do">Your projects</DoDont>\n<DoDont type="dont">My projects</DoDont>\n\n<DoDont type="do">We couldn\'t load your page</DoDont>\n<DoDont type="dont">The page couldn\'t be loaded </DoDont>\n\n### Tense\n\n**Present tense** helps make instructions and messages in the UI clear and engaging.\n\n<DoDont type="do">We can’t load work item DSP-32113.</DoDont>\n<DoDont type="dont">We couldn’t load work item DSP-32113.</DoDont>\n\n<DoDont type="do">Validation is required.</DoDont>\n<DoDont type="dont">Validation will be required.</DoDont>\n\n**Past tense** can be used to communicate a completed action, like in error message headings and success flags, or where there could be confusion.\n\n<DoDont type="do">\n\t<ul>\n\t\t<li>Upload failed</li>\n\t\t<li>File created</li>\n\t</ul>\n</DoDont>\n\n<DoDont type="dont">\n\t<ul>\n\t\t<li>Upload fail</li>\n\t\t<li>File create</li>\n\t</ul>\n</DoDont>\n\n## Punctuation\n\n### Apostrophes (\')\n- Use an apostrophe to show possession. The apostrophe is placed before the ‘s’ for singular terms and after the ‘s’ for plurals.\n- If a word ends in an ‘s’ and is singular, add an ‘s after the ‘s’.\n- Use a curly apostrophe for better readability and to differentiate from code.\n\t- On a Mac: **option** + **shift ** + **]**\n\t- On Windows: **Control** + **\'** (or **alt** + **0146**)\n\n<DoDont type="do">\n\t<ul>\n\t\t<li>A week’s time</li>\n\t\t<li>Three weeks’ time</li>\n\t\t<li>James’s work items</li>\n\t</ul>\n</DoDont>\n\n<DoDont type="dont">\n\t<ul>\n\t\t<li>A weeks time</li>\n\t\t<li>Three week\'s time</li>\n\t\t<li>James\' work items</li>\n\t</ul>\n</DoDont>\n\n### Colons (:)\n\n- Use colons to introduce a bulleted list or series of steps.\n- Don’t use colons at the end of headings.\n\n<DoDont type="do">\n\tA password should have:\n\t<ul>\n\t<li>12 characters or more </li>\n\t<li>at least one symbol and one number</li>\n\t<li>a mix of capital and lowercase letters</li>\n\t</ul>\n</DoDont>\n<DoDont type="dont">\n<p><b>Turn on two-factor authentication:</b></p>\n<p>Keep your account safe with an extra layer of security.</p>\n</DoDont>\n\n### Commas (,)\n\nUse an Oxford (or ‘serial’) comma to offset the final item in a list.\n\n<DoDont type="do">Jira, Confluence, Loom, and Bitbucket are all Atlassian apps.</DoDont>\n<DoDont type="dont">Jira, Confluence, Loom and Bitbucket are all Atlassian apps. </DoDont>\n\n### Dashes (—) and hyphens (-)\n\n#### Dashes\n\n- Use dashes in UI content sparingly. If using, use a spaced em dash.\n- In long-form content, use them sparingly to show an abrupt change in a sentence — like this. If the break happens in the middle of a sentence —  ike this — use spaced em dashes on either side of the phrase.\n- If possible, rewrite the sentence or make 2 sentences to avoid a dash. Clear, concise sentences are better for readability and accessibility.\n- Don\'t use a dash or hyphen for ranges of numbers. Use \'to\' instead.\n- When adding the space, use non-breaking spaces (**option** + **shift** + **space**) to avoid the dash shifting to a new line.\n- To make an em dash:\n\t- On a Mac: **option** + **shift** + **hyphen**\n\t- On Windows: **Control** + **Alt** + **-** (or **Alt** + **0151**)\n\n<DoDont type="do">Jira Service Management belongs to Jira\'s family of apps. They’re all built on the same platform and share the same site URL.</DoDont>\n<DoDont type="dont">Jira Service Management belongs to Jira\'s family of apps — they’re all built on the same platform and share the same site URL.</DoDont>\n\n<DoDont type="do">50 to 100</DoDont>\n<DoDont type="dont">50—100</DoDont>\n\n#### Hyphens\n\n- If a noun is described by 2 or more words, use a hyphen to join those words together so they act as a compound adjective (or compound modifier).\n- **Exceptions**: don’t add a hyphen after the word ‘very’ or adverbs ending in -ly.\n- For specific hyphenated word guidance, check [Vocabulary (Atlassians only)](https://hello.atlassian.net/wiki/spaces/AV/pages/1686830783/Atlassian+global+vocabulary+list).\n- Use a hyphen when not doing so could cause confusion or ambiguity. Consult the [Merriam-Webster dictionary](https://www.merriam-webster.com/) if you’re not sure.\n\n<DoDont type="do">\n\t<ul>\n\t<li>system-wide update</li>\n\t<li>character-counter logic</li>\n\t<li>widely communicated update</li>\n\t<li>very cold drink</li>\n\t<li>autocorrect</li>\n\t<li>coworker</li>\n\t<li>preexisting</li>\n\t</ul>\n</DoDont>\n<DoDont type="dont">\n<ul>\n\t<li>system wide update</li>\n\t<li>character counter logic</li>\n\t<li>widely-communicated update</li>\n\t<li>very-cold drink</li>\n\t<li>auto-correct</li>\n\t<li>co-worker</li>\n\t<li>pre-existing</li>\n\t</ul>\n</DoDont>\n\n<DoDont type="do">\n\t<ul>\n\t<li>re-sign the document</li>\n\t<li>re-create the page</li>\n\t</ul>\n</DoDont>\n<DoDont type="dont">\n<ul>\n\t<li>resign the document</li>\n\t<li>recreate the page</li>\n\t</ul>\n</DoDont>\n\n### Ellipses ( … )\n\n- Don’t put spaces in between the periods in an ellipsis.\n- Use the symbol for the ellipsis rather than a string of periods:\n\t- On a Mac: **Option** + **;**\n\t- On Windows: **Ctrl** + **Alt** + **.** (or **Alt** + **0133**)\n\n\n#### Truncation\nEllipses can be used to show that text has been cut off — or truncated — when a message doesn’t fit in a given space. View [truncation guidance](#truncation).\n\n#### Quotes\n\n- When using an ellipsis to omit part of a long quote, include spaces on either side of the ellipsis ( … ).\n- For example: “From medicine and space travel to disaster response … our products help teams all over the planet advance humanity through the power of software.” Atlassian: Discover our story.\n\n### Exclamation marks (!)\n\n- Avoid exclamation marks in UI copy and minimize their use in product marketing copy.\n- They can be considered for exciting or new things, but ask yourself if it’s really that exciting or if one is needed. Don’t use more than one exclamation mark per page.\n\n<DoDont type="do">Project is complete.</DoDont>\n<DoDont type="dont">Project is complete!</DoDont>\n\n### Periods (.)\n\n- Use a period (full stop) at the end of complete sentences, including in helper text, messages, and notifications.\n- Don’t use periods in headers, titles, tooltips, field descriptions, and menu names, even if they are full sentences. While long content is discouraged, an exception is if these elements contain more than 1 sentence.\n- Only use periods in a bulleted list if the item is a complete sentence. Don’t add a period at the end of a list of fragments.\n- Add only one space after a period (full stop).\n\n<DoDont type="do"><p><b>Accessibility principles</b></p>\n<p>Our principles cover the main requirements to design and build accessible experiences.</p></DoDont>\n<DoDont type="dont"><p><b>Accessibility principles.</b></p>\n<p>Our principles cover the main requirements to design and build accessible experiences.</p></DoDont>\n\nIf a link ends a sentence, include a period but don’t hyperlink it.\n\n<DoDont type="do">Atlassian’s work is guided by <a href="https://www.atlassian.com/company/values">5 core values</a>.</DoDont>\n<DoDont type="dont">Atlassian’s work is guided by <a href="https://www.atlassian.com/company/values">5 core values.</a></DoDont>\n\n### Quotation marks (‘’ | “”)\n\nIn the UI, use:\n- single curly quotes, unless you\'re writing in code or there’s a semantic reason to use straight quotes.\n\nIn body copy and long-form content, such as documentation and marketing, use:\n- double quotes (”“) for speech and direct quotes. Don’t use italics.\n- single quotes (‘’) to draw attention to a word you’re defining.\n\n<DoDont type="do">“We have big things planned for the coming year,” said Mike.</DoDont>\n<DoDont type="dont">‘We have big things planned for the coming year,’ said Mike.</DoDont>\n\n<DoDont type="do">They tried to avoid talking about the ‘big’ secret.</DoDont>\n<DoDont type="dont">They tried to avoid talking about the “big“ secret.</DoDont>\n\n#### Emphasis\n\nDon’t use quotation marks to emphasize UI elements, page titles, and other objects. Instead use [bold](#Bold).\n\n<DoDont type="do">Go to <b>Settings</b>.</DoDont>\n<DoDont type="dont">Go to ‘Settings’.</DoDont>\n\n#### Shortcuts\n\n##### Mac\n\n- Double quotes:\n\t- opening marks: **option** + **[**\n\t- closing marks: **option** + **shift** + **[**\n- Single quotes:\n\t- opening marks: **option** + **]**\n\t- closing marks: **option** + **shift** + **]**\n\n##### Windows\n\n- Double quotes:\n\t- opening marks: **Alt** + **0147**\n\t- closing marks: **Alt** + **0148**\n- Single quotes:\n\t- opening marks: **Alt** + **0145**\n\t- closing marks: **Alt** + **0146**',
+  content: '<SectionMessage title="Atlassian vocabulary">\n\tFor specific vocabulary and to view our internal word list and glossary, head to{\' \'}\n\t<Link href="https://go.atlassian.com/vocab">go/vocab (Atlassians only)</Link>.\n</SectionMessage>\n\n## Style and formatting\n\n### Abbreviations\n\n- Use the full name of features and apps in customer-facing copy.\n- Don’t use \'e.g.\', ‘i.e.’, ‘etc.’, or \'&\' as they\'re not localization friendly and can be confusing\n  for users of assistive technologies.\n\n<DoDontGrid>\n\t<DoDont type="do">Ask the experts at Jira Service Desk.</DoDont>\n\t<DoDont type="dont"> Ask the experts at JSD.</DoDont>\n\t<DoDont type="do">Use an input component. For example, a button or a select.</DoDont>\n\t<DoDont type="dont"> Use an input component, e.g. a button or a select etc.</DoDont>\n</DoDontGrid>\n\n#### Plural abbreviations\n\nDon’t use an apostrophe for plural abbreviations.\n\n<DoDontGrid>\n\t<DoDont type="do">1990s, DVDs</DoDont>\n\t<DoDont type="dont"> 1990’s, DVD’s</DoDont>\n</DoDontGrid>\n\n### Articles (a, an, the)\n\nAvoid articles in buttons, labels, and action-based headings in the UI.\n\n<DoDontGrid>\n\t<DoDont type="do">Create password</DoDont>\n\t<DoDont type="dont"> Create a password</DoDont>\n</DoDontGrid>\n\n### Bold\n\nUse bold text to draw the reader’s eye to key phrases and statements in your content, though don\'t\nover do it.\n\n- For in-app copy or help articles, use bold when referring to static UI elements like menu items,\n  buttons, or headings.\n- If bold is needed but the UI doesn’t support it — for example in a UI message or a flag where the\n  title is already bold — you can use [italics](#italics).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tGo to <b>General configuration</b> then <b>User macros</b>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tGo to the <b>settings page and select Configuration</b>.\n\t</DoDont>\n</DoDontGrid>\n\n### Capitalization\n\n- Use sentence case in all titles, headings, menu items, labels, and buttons.\n- Capitalize proper nouns in headings, such as names of people, companies, or apps.\n\n<DoDontGrid>\n\t<DoDont type="do">Create work item</DoDont>\n\t<DoDont type="dont">Create Work Item</DoDont>\n\t<DoDont type="do">Add permissions for Arni Karan</DoDont>\n\t<DoDont type="dont">Add permissions for arni karan</DoDont>\n</DoDontGrid>\n\n### Contractions (shortened words)\n\n- Use contractions, where possible, as they convey a conversational, friendly tone.\n- Use curly apostrophes in UI copy\n  - On a Mac: **option** + **shift** + **]**\n  - On Windows: **Control** + **\'** (or **alt** + **0146**)\n\n<DoDontGrid>\n\t<DoDont type="do">We can’t load this page.</DoDont>\n\t<DoDont type="dont">We cannot load this page.</DoDont>\n</DoDontGrid>\n\n### Date and time\n\nView [date and time guidelines](https://atlassian.design/foundations/content/date-time).\n\n### Gender (he, she, they)\n\n- If known, use the pronouns a customer provides. If you don’t know, avoid gendered pronouns\n  wherever possible.\n- If it’s not possible, use ’they’ or ’their’ rather than ‘his/her’ or ’he/she’.\n\n<DoDontGrid>\n\t<DoDont type="do">Ask your admin to add you.</DoDont>\n\t<DoDont type="dont">Ask your admin if she can add you.</DoDont>\n\t<DoDont type="do">Add permissions to their account.</DoDont>\n\t<DoDont type="dont">Add permissions to her account.</DoDont>\n</DoDontGrid>\n\n### Headings and titles\n\n- Use sentence case. Only capitalize the first word of a sentence, proper nouns, and trademarked\n  names (for example: apps, countries, people\'s names).\n- Don’t use bold or italics.\n- Don\'t use periods.\n- Reconsider using question marks. Preferably rephrase the heading so it’s a statement.\n- Phrase UI and documentation headings with an action verb.\n- Avoid gerunds (the ‘ing’ form of verbs) in UI copy.\n\n<DoDontGrid>\n\t<DoDont type="do">Organize your to-do list with Trello</DoDont>\n\t<DoDont type="dont">\n\t\tWant to Organize <em>Your</em> To-Do List With Trello?\n\t</DoDont>\n\t<DoDont type="do">Add a page to your project</DoDont>\n\t<DoDont type="dont">Adding a page to your project</DoDont>\n</DoDontGrid>\n\n#### Articles in headings\n\n- Articles (a, an, the) aren’t always needed in UI headings.\n- They\'re better suited to more conversational sections, like product marketing copy and empty\n  states, as they make these sections more approachable and improve understanding.\n\n<DoDontGrid>\n\t<DoDont type="do">Create work item</DoDont>\n\t<DoDont type="dont">Create a work item</DoDont>\n</DoDontGrid>\n\n### Italics\n\nIn apps, use italics sparingly as it can be difficult to read. Don’t use italics in hyperlinks.\n\nItalics can be used for:\n\n- UI elements that might change, like a field name or user input.\n- For emphasis if the UI doesn’t support bold. For example, in a flag or UI message.\n\n### Lists\n\nUse lists to draw the reader’s eye and make items easier to scan and follow. Try to limit lists to 6\nitems or less. If there are more items, make multiple lists.\n\n#### Bulleted list\n\n- Use to list options or when the order of the items doesn’t matter.\n- Phrase each item in a parallel way.\n- Don’t use commas or periods at the end of each item.\n\n##### Fragmented sentences\n\nIf your list has fragmented sentences, use a lowercase letter for each item and don’t use a period\nat the end of the list. Use a lead-in sentence with a colon before the items.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tDue to security concerns, all employees are required to:\n\t\t<ul>\n\t\t\t<li>wear an identification tag</li>\n\t\t\t<li>use their security pass to enter or leave an office before 7 a.m. and after 6 p.m.</li>\n\t\t\t<li>alert security if a suspicious package is found</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tDue to security concerns, all employees are required to;\n\t\t<ul>\n\t\t\t<li>Wear an identification tag in the building,</li>\n\t\t\t<li>\n\t\t\t\tYou must use your identification tag to enter an office before 7 a.m. and exit after 6 p.m.,\n\t\t\t\tand\n\t\t\t</li>\n\t\t\t<li>If a suspicious package is found, alert security.</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n##### Complete sentences\n\nFor lists with complete sentences, start an item with a capital letter and end it with a period.\nDon’t use a lead-in sentence with a colon.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tAtlassian has updated security requirements for employees.\n\t\t<p></p>\n\t\t<ul>\n\t\t\t<li>Always wear your identification tag when working in an office.</li>\n\t\t\t<li>\n\t\t\t\tUse your identification tag to enter an office before 7 am and when you leave after 6 pm.\n\t\t\t</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tAtlassian has updated security requirements for employees:\n\t\t<ul>\n\t\t\t<li>always wear your identification tag when working in an office</li>\n\t\t\t<li>\n\t\t\t\tuse your identification tag to enter an office before 7 am and when you leave after 6 pm.\n\t\t\t</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n#### Numbered lists\n\nUse numbered lists for tasks or lists where the order of the items matters. Capitalize the first\nword of each item and end the item with a period.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tTo add a new user macro:\n\t\t<ol>\n\t\t\t<li>\n\t\t\t\tGo to <b>Settings</b> then <b>General configuration</b> then <b>User macros</b>.\n\t\t\t</li>\n\t\t\t<li>\n\t\t\t\tChoose <b>Create a user macro</b>.\n\t\t\t</li>\n\t\t\t<li>Enter the macro details.</li>\n\t\t</ol>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tTo add a new user macro -\n\t\t<ol>\n\t\t\t<li>\n\t\t\t\tgo to <b>Settings</b> then <b>General configuration</b> then <b>User macros</b>\n\t\t\t</li>\n\t\t\t<li>\n\t\t\t\tchoose <b>Create a user macro</b>\n\t\t\t</li>\n\t\t\t<li>enter the macro details.</li>\n\t\t</ol>\n\t</DoDont>\n</DoDontGrid>\n\n### Monospaced text\n\nUse `monospaced font` for names of a file or directory. It’s mostly used in attributes, strings, and\nadministrator and developer docs.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tThe location of the Home directory is stored in a configuration file called\n\t\t<code>confluence-init.properties</code>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tThe location of the Home directory is stored in a configuration file called{\' \'}\n\t\t<b>confluence-init.properties</b>.\n\t</DoDont>\n</DoDontGrid>\n\n### Numbers\n\nUse digits rather than words in most cases.\n\n**Exceptions**:\n\n- If a number starts a sentence, write it out.\n- In common expressions, write the number out. For example: _It’s one thing after another_.\n- When writing long-form or formal content, write out numbers one to nine.\n- Write out the numbers ‘zero’ and ‘one’ if it could be confused for the letters L, I, or O.\n\n<DoDontGrid>\n\t<DoDont type="do">Your password should be a minimum of 8 characters. </DoDont>\n\t<DoDont type="dont">Your password should be a minimum of eight characters.</DoDont>\n\t<DoDont type="do">Loom is one of the best apps for sharing information in a personal way.</DoDont>\n\t<DoDont type="dont">Loom is 1 of the best apps for sharing information in a personal way.</DoDont>\n</DoDontGrid>\n\n#### Number ranges\n\nUse ’to’ and not hyphens in number ranges, except if space is limited, like in a table or mobile\napp.\n\n<DoDontGrid>\n\t<DoDont type="do">View rows 1 to 4 in the table.</DoDont>\n\t<DoDont type="dont">View rows 1-4 in the table.</DoDont>\n</DoDontGrid>\n\n#### Numbers \'out of\'\n\nUse ‘of’ rather than a forward slash ( / ) to show a number out of another number.\n\n<DoDontGrid>\n\t<DoDont type="do">Step 1 of 2</DoDont>\n\t<DoDont type="dont">Step 1/2</DoDont>\n</DoDontGrid>\n\n#### Numbers from 1,000\n\nUse a comma to indicate the thousand in a number.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>4,500</li>\n\t\t\t<li>10,000</li>\n\t\t\t<li>1,250,000</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>4500</li>\n\t\t\t<li>10000</li>\n\t\t\t<li>1250000</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Spelling words\n\nUse US English in UI copy and code. Check spellings in\n[Merriam-Webster online dictionary](https://www.merriam-webster.com/).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>color</li>\n\t\t\t<li>organization</li>\n\t\t\t<li>labeled</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>colour</li>\n\t\t\t<li>organisation</li>\n\t\t\t<li>labelled</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Truncation\n\nEllipses (…) are used to show that text has been cut off — or truncated — when a message doesn’t fit\nin a given space.\n\n- Avoid truncation whenever possible: shorten UI messages or wrap the text.\n- Test your designs using multiple screen widths and magnification levels to ensure it doesn’t\n  truncate.\n- If truncation can’t be avoided, for example in user-generated content or icon buttons, use a\n  [tooltip](https://atlassian.design/components/tooltip/examples) to display the full text for\n  accessibility and usability.\n- In ADS components that truncate, the ellipsis appears without any space next to the last visible\n  character (for example: Work in pro…).\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: truncationDo, alt: \'\' }}>\n\t\tShorten or wrap messages.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: truncationDont, alt: \'\' }}>\n\t\tDon’t truncate unless it can’t be avoided.\n\t</DoDont>\n</DoDontGrid>\n\n### UI elements\n\n- Use sentence case, even if the UI element doesn’t use it.\n- Use bold to emphasize the UI element in a step.\n- If the UI element has an icon, bold both the name and the icon.\n- Avoid using a > symbol where possible, as it is read out as “greater than” by assistive\n  technologies, leading to confusion. Use ‘then’ instead.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tGo to <b>More</b>, then <b>Link work item</b>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tGo to <b>More</b> > <b>Link Work Item</b>.\n\t</DoDont>\n</DoDontGrid>\n\n## Grammar\n\n### Active voice\n\nUse active voice whenever possible as it improves readability and reflects Atlassian’s\n[voice and tone](https://atlassian.design/foundations/content/voice-tone).\n\nActive voice:\n\n- puts the emphasis on the person or thing doing an action.\n- makes content shorter, clearer, friendlier, and more conversational.\n\n<DoDontGrid>\n\t<DoDont type="do">Administrators control access to Atlassian Cloud applications.</DoDont>\n\t<DoDont type="dont">\n\t\tAccess to Atlassian Cloud applications is controlled by administrators.\n\t</DoDont>\n</DoDontGrid>\n\n### Pronouns (you, your, we)\n\n- Minimize the use of pronouns.\n- Most of the time they can be avoided. However, when advising a user, indicating that something in\n  the UI is theirs, or in error messages, you can use ‘you’ or ’your’ or ’we’ for a friendlier tone.\n\n<DoDontGrid>\n\t<DoDont type="do">Get access to your work items here.</DoDont>\n\t<DoDont type="dont">Get access to the work items here.</DoDont>\n\t<DoDont type="do">Your projects</DoDont>\n\t<DoDont type="dont">My projects</DoDont>\n\t<DoDont type="do">We couldn\'t load your page</DoDont>\n\t<DoDont type="dont">The page couldn\'t be loaded </DoDont>\n</DoDontGrid>\n\n### Tense\n\n**Present tense** helps make instructions and messages in the UI clear and engaging.\n\n<DoDontGrid>\n\t<DoDont type="do">We can’t load work item DSP-32113.</DoDont>\n\t<DoDont type="dont">We couldn’t load work item DSP-32113.</DoDont>\n\t<DoDont type="do">Validation is required.</DoDont>\n\t<DoDont type="dont">Validation will be required.</DoDont>\n</DoDontGrid>\n\n**Past tense** can be used to communicate a completed action, like in error message headings and\nsuccess flags, or where there could be confusion.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>Upload failed</li>\n\t\t\t<li>File created</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>Upload fail</li>\n\t\t\t<li>File create</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n## Punctuation\n\n### Apostrophes (\')\n\n- Use an apostrophe to show possession. The apostrophe is placed before the ‘s’ for singular terms\n  and after the ‘s’ for plurals.\n- If a word ends in an ‘s’ and is singular, add an ‘s after the ‘s’.\n- Use a curly apostrophe for better readability and to differentiate from code.\n  - On a Mac: **option** + **shift ** + **]**\n  - On Windows: **Control** + **\'** (or **alt** + **0146**)\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>A week’s time</li>\n\t\t\t<li>Three weeks’ time</li>\n\t\t\t<li>James’s work items</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>A weeks time</li>\n\t\t\t<li>Three week\'s time</li>\n\t\t\t<li>James\' work items</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Colons (:)\n\n- Use colons to introduce a bulleted list or series of steps.\n- Don’t use colons at the end of headings.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tA password should have:\n\t\t<ul>\n\t\t\t<li>12 characters or more </li>\n\t\t\t<li>at least one symbol and one number</li>\n\t\t\t<li>a mix of capital and lowercase letters</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<p>\n\t\t\t<b>Turn on two-factor authentication:</b>\n\t\t</p>\n\t\t<p>Keep your account safe with an extra layer of security.</p>\n\t</DoDont>\n</DoDontGrid>\n\n### Commas (,)\n\nUse an Oxford (or ‘serial’) comma to offset the final item in a list.\n\n<DoDontGrid>\n\t<DoDont type="do">Jira, Confluence, Loom, and Bitbucket are all Atlassian apps.</DoDont>\n\t<DoDont type="dont">Jira, Confluence, Loom and Bitbucket are all Atlassian apps. </DoDont>\n</DoDontGrid>\n\n### Dashes (—) and hyphens (-)\n\n#### Dashes\n\n- Use dashes in UI content sparingly. If using, use a spaced em dash.\n- In long-form content, use them sparingly to show an abrupt change in a sentence — like this. If\n  the break happens in the middle of a sentence —  ike this — use spaced em dashes on either side of\n  the phrase.\n- If possible, rewrite the sentence or make 2 sentences to avoid a dash. Clear, concise sentences\n  are better for readability and accessibility.\n- Don\'t use a dash or hyphen for ranges of numbers. Use \'to\' instead.\n- When adding the space, use non-breaking spaces (**option** + **shift** + **space**) to avoid the\n  dash shifting to a new line.\n- To make an em dash:\n  - On a Mac: **option** + **shift** + **hyphen**\n  - On Windows: **Control** + **Alt** + **-** (or **Alt** + **0151**)\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tJira Service Management belongs to Jira\'s family of apps. They’re all built on the same platform\n\t\tand share the same site URL.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tJira Service Management belongs to Jira\'s family of apps — they’re all built on the same\n\t\tplatform and share the same site URL.\n\t</DoDont>\n\t<DoDont type="do">50 to 100</DoDont>\n\t<DoDont type="dont">50—100</DoDont>\n</DoDontGrid>\n\n#### Hyphens\n\n- If a noun is described by 2 or more words, use a hyphen to join those words together so they act\n  as a compound adjective (or compound modifier).\n- **Exceptions**: don’t add a hyphen after the word ‘very’ or adverbs ending in -ly.\n- For specific hyphenated word guidance, check\n  [Vocabulary (Atlassians only)](https://hello.atlassian.net/wiki/spaces/AV/pages/1686830783/Atlassian+global+vocabulary+list).\n- Use a hyphen when not doing so could cause confusion or ambiguity. Consult the\n  [Merriam-Webster dictionary](https://www.merriam-webster.com/) if you’re not sure.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>system-wide update</li>\n\t\t\t<li>character-counter logic</li>\n\t\t\t<li>widely communicated update</li>\n\t\t\t<li>very cold drink</li>\n\t\t\t<li>autocorrect</li>\n\t\t\t<li>coworker</li>\n\t\t\t<li>preexisting</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>system wide update</li>\n\t\t\t<li>character counter logic</li>\n\t\t\t<li>widely-communicated update</li>\n\t\t\t<li>very-cold drink</li>\n\t\t\t<li>auto-correct</li>\n\t\t\t<li>co-worker</li>\n\t\t\t<li>pre-existing</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="do">\n\t\t<ul>\n\t\t\t<li>re-sign the document</li>\n\t\t\t<li>re-create the page</li>\n\t\t</ul>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<ul>\n\t\t\t<li>resign the document</li>\n\t\t\t<li>recreate the page</li>\n\t\t</ul>\n\t</DoDont>\n</DoDontGrid>\n\n### Ellipses ( … )\n\n- Don’t put spaces in between the periods in an ellipsis.\n- Use the symbol for the ellipsis rather than a string of periods:\n  - On a Mac: **Option** + **;**\n  - On Windows: **Ctrl** + **Alt** + **.** (or **Alt** + **0133**)\n\n#### Truncation\n\nEllipses can be used to show that text has been cut off — or truncated — when a message doesn’t fit\nin a given space. View [truncation guidance](#truncation).\n\n#### Quotes\n\n- When using an ellipsis to omit part of a long quote, include spaces on either side of the ellipsis\n  ( … ).\n- For example: “From medicine and space travel to disaster response … our products help teams all\n  over the planet advance humanity through the power of software.” Atlassian: Discover our story.\n\n### Exclamation marks (!)\n\n- Avoid exclamation marks in UI copy and minimize their use in product marketing copy.\n- They can be considered for exciting or new things, but ask yourself if it’s really that exciting\n  or if one is needed. Don’t use more than one exclamation mark per page.\n\n<DoDontGrid>\n\t<DoDont type="do">Project is complete.</DoDont>\n\t<DoDont type="dont">Project is complete!</DoDont>\n</DoDontGrid>\n\n### Periods (.)\n\n- Use a period (full stop) at the end of complete sentences, including in helper text, messages, and\n  notifications.\n- Don’t use periods in headers, titles, tooltips, field descriptions, and menu names, even if they\n  are full sentences. While long content is discouraged, an exception is if these elements contain\n  more than 1 sentence.\n- Only use periods in a bulleted list if the item is a complete sentence. Don’t add a period at the\n  end of a list of fragments.\n- Add only one space after a period (full stop).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\t<p>\n\t\t\t<b>Accessibility principles</b>\n\t\t</p>\n\t\t<p>Our principles cover the main requirements to design and build accessible experiences.</p>\n\t</DoDont>\n\t<DoDont type="dont">\n\t\t<p>\n\t\t\t<b>Accessibility principles.</b>\n\t\t</p>\n\t\t<p>Our principles cover the main requirements to design and build accessible experiences.</p>\n\t</DoDont>\n</DoDontGrid>\n\nIf a link ends a sentence, include a period but don’t hyperlink it.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tAtlassian’s work is guided by{\' \'}\n\t\t<a href="https://www.atlassian.com/company/values">5 core values</a>.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tAtlassian’s work is guided by{\' \'}\n\t\t<a href="https://www.atlassian.com/company/values">5 core values.</a>\n\t</DoDont>\n</DoDontGrid>\n\n### Quotation marks (‘’ | “”)\n\nIn the UI, use:\n\n- single curly quotes, unless you\'re writing in code or there’s a semantic reason to use straight\n  quotes.\n\nIn body copy and long-form content, such as documentation and marketing, use:\n\n- double quotes (”“) for speech and direct quotes. Don’t use italics.\n- single quotes (‘’) to draw attention to a word you’re defining.\n\n<DoDontGrid>\n\t<DoDont type="do">“We have big things planned for the coming year,” said Mike.</DoDont>\n\t<DoDont type="dont">‘We have big things planned for the coming year,’ said Mike.</DoDont>\n\t<DoDont type="do">They tried to avoid talking about the ‘big’ secret.</DoDont>\n\t<DoDont type="dont">They tried to avoid talking about the “big“ secret.</DoDont>\n</DoDontGrid>\n\n#### Emphasis\n\nDon’t use quotation marks to emphasize UI elements, page titles, and other objects. Instead use\n[bold](#bold).\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tGo to <b>Settings</b>.\n\t</DoDont>\n\t<DoDont type="dont">Go to ‘Settings’.</DoDont>\n</DoDontGrid>\n\n#### Shortcuts\n\n##### Mac\n\n- Double quotes:\n  - opening marks: **option** + **[**\n  - closing marks: **option** + **shift** + **[**\n- Single quotes:\n  - opening marks: **option** + **]**\n  - closing marks: **option** + **shift** + **]**\n\n##### Windows\n\n- Double quotes:\n  - opening marks: **Alt** + **0147**\n  - closing marks: **Alt** + **0148**\n- Single quotes:\n  - opening marks: **Alt** + **0145**\n  - closing marks: **Alt** + **0146**',
   keywords: ['language', 'grammar', 'capitalization', 'truncation', 'content']
 }, {
   content: 'We use the Atlassian voice and tone in all of our properties and content, from user interfaces to\nemail, social media, and other channels.\n\nAny Atlassian who works with customer-facing communications should follow the voice and tone\nguidelines: content designers, engineers, product designers, blog contributors, product managers,\nmarketers... pretty much everyone.\n\nTo help teams do the best work of their lives, we:\n\n- offer solutions that help people at the moment they need it\n- simplify complex problems into easy-to-understand pieces\n- inspire people to try new things\n\nWith a familiar tone, clear language, and a solid knowledge of our audience, we craft messages that\nget teams moving in the right direction, then we get out of their way.\n\nThe Atlassian voice is based on the Atlassian brand personality traits of:\n\n- bold\n- optimistic\n- practical, with a wink\n\nTo provide consistent, friendly, and helpful content for people, use this guidance with our other\nguidelines:\n\n- [Language and grammar](https://atlassian.design/foundations/content/language-and-grammar)\n- [Inclusive language](https://atlassian.design/foundations/content/inclusive-writing)\n- [Vocabulary (Atlassians only)](https://go.atlassian.com/vocab)\n\n## Atlassian’s personality traits\n\nWhen writing with Atlassian\'s voice, we\'re part of the team. We\'re that friend or colleague who is\nalways up on new trends and wants to be helpful and share new wisdom with everyone in a relatable\nway.\n\nWe know when it\'s time to be serious and direct, and when it\'s time to be more casual.\n\nPersonality comes across best in the details. The emphasis of each trait should be contextual to the\naudience and situation.\n\nHere are some questions you can ask yourself during your process to assess whether or not you’re\nleveraging our personality traits well.\n\n- What is the emotional state of the person when encountering your solution during their journey?\n- How might our personality traits help enhance a moment of celebration?\n- How might our personality traits help diffuse a moment of frustration or pain?\n\n### Bold\n\nMotivate teams to do their best work. Offer best practices to get people going in the right\ndirection.\n\nBe bold and offer just enough help to get the work started, and then get out of the way.\n\nGive accurate information so people can make educated decisions. Understand the person\'s struggles\nand desired outcomes and give enough information to let them get where they need to go.\n\n### Optimistic\n\nGo on the journey with people and highlight the key points that will help them the most, right now.\n\nBe in the moment by focusing attention on the important bits first. This gives people confidence in\nour apps.\n\nWeave a consistent story across our fabric and be diligent about vocabulary across all messaging by\nbeing brand-conscious across apps.\n\nCreate a seamless flow across all the things. Let people know that they can jump in and start\nworking, and can expect a familiar experience across all of the things. Keep teams in the loop about\nwhat is happening by informing them of relevant features, apps, and opportunities for success.\n\n### Practical, with a wink\n\nGet to the point and be direct. Be concise.\n\nBe on the lookout for opportunities and be quick to offer a helping hand. Give the user just enough\nto know that something awesome is around the corner and then get out of the way.\n\nWrite clear, accurate, and concise text that makes interfaces more usable and consistent — and\nbuilds trust.\n\nWrite text that is understandable by anyone, anywhere, regardless of their culture or language so\nthat everyone feels they are part of the team.\n\n## Voice and tone principles\n\nA consistent voice creates better relationships with our customers.\n\nBut, there is one caveat.\n\nThere are times when you need to speak to different subsets of people, for instance among different\napps, and your tone might not be quite the same. That\'s okay! We\'ve provided enough guidance to help\nadjust our tone to accommodate for:\n\n- where people are at in their journey\n- their emotional state\n- the app or property you are writing for\n\nThe voice and tone principles:\n\n- [Inform to build trust](https://atlassian.design/foundations/content/voice-tone#inform-to-build-trust)\n- [Empower to inspire action](https://atlassian.design/foundations/content/voice-tone#empower-to-inspire-action)\n- [Encourage people along the path](https://atlassian.design/foundations/content/voice-tone#encourage-people-along-the-path)\n- [Motivate by showing possibilities](https://atlassian.design/foundations/content/voice-tone#motivate-by-showing-possibilities)\n- [Satisfy by meeting expectations](https://atlassian.design/foundations/content/voice-tone#satisfy-by-meeting-expectations)\n- [Delight with unexpectedly pleasing experiences](https://atlassian.design/foundations/content/voice-tone#delight-with-unexpectedly-pleasing-experiences)\n\n### Inform to build trust\n\n**Inform** by being **open** and **clear** on what people are experiencing in our apps.\n\nTell people what they need to know at that moment and nothing more. Be aware of when a user may be\nnew or confused, and tone down the boldness by being more prescriptive. Let people know where they\nare in their journey and what they are looking at in the app.\n\nWrite as a knowledgable member of the team. Show up at the right time and be open, humble, and warm\n— offer direction for the most appropriate next steps and get out of the way.\n\n#### When we need to be less bold\n\nPerson is feeling: apprehension, confusion, annoyance, fear, loathing, anger.\n\nExamples: new users, evaluators, and when introducing a new concept, feature, or app\n\n<img\n\tsrc={lessBoldLight}\n\tsrcDark={lessBoldDark}\n\talt="Slider between less bold and more bold, with the dot much closer to less bold end."\n/>\n\n#### Places we use this principle\n\n- In-app: [flags](https://atlassian.design/components/flag/usage),\n  [error messages](https://atlassian.design/foundations/content/designing-messages/error-messages),\n  and [onboarding (spotlight)](https://atlassian.design/components/onboarding/usage)\n- Being informative and to build trust\n\n### Empower to inspire action\n\n**Educate** where we people need it most. Offer **opportunities** to learn at pivotal times to\n**empower** people to move in the right direction. Offer best practices and recommendations for next\nsteps while suggesting ways to improve and make decisions.\n\nLet people know Atlassian and fellow community members are available to help people make decisions.\n\nWrite as if you are educating. You are a teacher with empathy and an understanding of what it’s like\nto be in the weeds. You expect your audience to have a basic understanding.\n\n#### When we want to be more bold\n\nPerson is feeling: confident, interested, trust, anticipation.\n\nExamples: power users, admins, everyday users\n\n<img\n\tsrc={moreBoldLight}\n\tsrcDark={moreBoldDark}\n\talt="Slider between less bold and more bold, with the dot much closer to more bold end."\n/>\n\n#### Places we use this principle\n\n- In-app: [onboarding (spotlight)](https://atlassian.design/components/onboarding/usage),\n  [benefits modal](https://atlassian.design/components/onboarding/benefits-modal/usage), and\n  [modal dialogs](https://atlassian.design/components/modal-dialog/usage)\n- Something requires an action from the person\n- Educational opportunities\n- Social opportunities — let them know best practices\n\n### Encourage people along the path\n\n**Inspire** initial **optimism** by providing **support** in the right place. Be **consistent** and\n**dependable**.\n\nOffer waypoints, help, and support if people are feeling confused or frustrated at a point in their\njourney. This principle is about being human, giving guidance, support, and encouragement along the\nway.\n\nGuide people by revealing information gracefully. Let them know they are on the right path, they\naren’t alone, and that delivering projects and building teams can be challenging.\n\nWrite in an upbeat, friendly way. Acknowledge the opportunities in the here-and-now and walk through\nit with them.\n\n#### When we need to be less optimistic\n\nPerson is feeling: anticipation, unsupported, confused, uncertain\n\nExamples: new to Atlassian, evaluators, or when introducing a new concept, feature, or app\n\n<img\n\tsrc={lessOptimisticLight}\n\tsrcDark={lessOptimisticDark}\n\talt="Slider between less optimistic and more optimistic, with the dot much closer to the less optimistic end."\n/>\n\n#### Places we use this principle\n\n- In-app:\n  [information messages](https://atlassian.design/foundations/content/designing-messages/info-messages),\n  [error messages](https://atlassian.design/foundations/content/designing-messages/error-messages),\n  and [section messages](https://atlassian.design/components/section-message/usage)\n- Something requires an action from the person\n\n### Motivate by showing possibilities\n\nProvide **incentive** and **excitement** for continued growth.\n\nConsider why someone would want to do this.\n\nShow the possibilities of what can be accomplished by giving examples of how other people accomplish\nthe same task, or by presenting the ideal state. Describe the end result, giving expert testimony,\nor offer opportunities for advanced knowledge.\n\nWrite like an expert. Focus more on the solution than on the problem. Show people the possible\nbenefits.\n\n#### When we want to be more optimistic\n\nPerson is feeling: ambitious, inspired, curious, admiration.\n\nExamples: power users, admins, everyday users\n\n<img\n\tsrc={moreOptimisticLight}\n\tsrcDark={moreOptimisticDark}\n\talt="Slider between less optimistic and more optimistic, with the dot much closer to the more optimistic end."\n/>\n\n#### Places we use this principle\n\n- In-app: [onboarding (spotlight)](https://atlassian.design/components/onboarding/usage) and\n  [modal dialogs](https://atlassian.design/components/modal-dialog/usage)\n- Educational opportunities — it\'s a chance to tell them how other industry leaders do it, give best\n  practices, and tips and tricks\n\n### Satisfy by meeting expectations\n\nGive people what they need.\n\nProvide **quick and thorough** answers, guidance, actions, and instructions. We aren’t trying to\nlead, inspire, motivate, delight, or encourage. Simply tell people what they need to know and get\nout of the way.\n\nAll of our content should be practical at a minimum. Write as if you are explaining to your friend\nhow to travel somewhere you’ve visited regularly.\n\n#### When we need to be practical\n\nPerson is feeling: overwhelmed and stressed.\n\nExamples: people under pressure with deadlines — everyone feels this way sometimes\n\n<img\n\tsrc={lessWinkyLight}\n\tsrcDark={lessWinkyDark}\n\talt="Slider between practical and winky, with the dot much closer to the practical end."\n/>\n\n#### Places we use this principle\n\n- Whenever we can\n- In-app:\n  [warning messages](https://atlassian.design/foundations/content/designing-messages/warning-messages),\n  [information messages](https://atlassian.design/foundations/content/designing-messages/info-messages),\n  and\n  [error messages](https://atlassian.design/foundations/content/designing-messages/error-messages)\n\n### Delight with unexpectedly pleasing experiences\n\n“Wink” where appropriate. We deliver appropriate **delight** — celebrate **success** or **progress**\nonce we’ve built **trust**.\n\nBut don’t overdo it. These are little flourishes: we give flowers, not puppies.\n\nPay particular attention to people’s state of mind. Think about the timing, and how frequently they\nwill see this.\n\n#### When we can share a little delight\n\nPerson is feeling: successful, joy, pride, relief.\n\nExamples: evaluators, power users, during social interactions\n\n<img\n\tsrc={moreWinkyLight}\n\tsrcDark={moreWinkyDark}\n\talt="Slider between practical and winky, with the dot much closer to the winky end."\n/>\n\n#### Places we use this principle\n\n- In-app:\n  [success messages](https://atlassian.design/foundations/content/designing-messages/success-messages)\n  and [modal dialogs](https://atlassian.design/components/modal-dialog/usage)\n- Social interactions and while introducing new experiences',
   keywords: ['voice', 'tone', 'writing', 'content', 'brand']
+}, {
+  content: 'import {\n\tTokenElevationBackgroundChangeExample,\n\tTokenElevationChangeExample,\n} from \'../../../components/interactive-elevations\';\n\n\n\n\n\nElevations are the layered surfaces that form the foundation of the UI. They create a blank canvas\nwhere other UI will be placed, such as text, icons, backgrounds, and borders.\n\n![](./_assets/elevation-layers.png)\n\nMost elevations consist of surfaces and shadows. Together, surfaces and shadows give the impression\nof lift or depth. Elevations can guide focus through layering, or indicate that the UI can be\nscrolled, slid, or dragged.\n\n## Applying elevations\n\nThe elevations use [design tokens](https://atlassian.design/tokens/design-tokens) to apply different\nsurface levels. The highest two elevation surfaces, raised and overlay, are paired with shadows to\ncreate more depth.\n\n![](./_assets/applying-elevations-light.png)\n\n### Elevations in dark theme\n\nShadows can be harder to see in dark mode, so dark mode elevations also rely on different surface\ncolors. Imagine that the surfaces are distantly lit from the front — the higher the elevation, the\nlighter the surface looks.\n\n![](./_assets/applying-elevations-dark-1.png)\n\nRaised and overlay surfaces are still paired with shadows for added depth and consistency in dark\nmode.\n\n![](./_assets/applying-elevations-dark-2.png)\n\n## Types of elevations\n\nThere are four basic elevation levels:\n\n1. [Sunken](#sunken)\n2. [Default](#default)\n3. [Raised](#raised)\n4. [Overlay](#overlay)\n\nThere is also one "[overflow](#overflow)" elevation for special cases.\n\n### Sunken\n\nSunken is the lowest elevation available. The sunken surface creates a backdrop (or well) where\nother content sits. Columns on a Kanban board are a good example of the sunken elevation.\n\nOnly use sunken surfaces on the default surface level. Don’t apply sunken elevations on raised or\noverlay elevations. To differentiate areas of the UI in other ways, use whitespace or borders\ninstead.\n\n![](./_assets/elevation-sunken-1.png)\n\n#### Using `elevation.surface.sunken` vs `color.background.neutral`\n\nAlthough `elevation.surface.sunken` and `color.background.neutral` tokens may appear similar in\nlight mode, they behave differently in dark mode. Here are the main differences between the two:\n\n`elevation.surface.sunken` is an opaque (solid) token that darkens in both light and dark modes. Use\nthis token as a backdrop to group content or elements together (such as a kanban board) on the\ndefault surface.\n\n![](./_assets/elevation-sunken-2.png)\n\n`color.background.neutral` is a token that uses a transparent color. It darkens in light mode and\nlightens in dark mode. Use this token when you need the background to adapt to different elevations,\nwhich is relevant in dark mode since surfaces change depending on what elevation you’re on.\n\n![](./_assets/elevation-sunken-3.png)\n\n### Default\n\nThe default elevation is the baseline with respect to all other layers. It represents a flat UI\nsurface with no visual lift, such as a Confluence page.\n\nUse `elevation.surface` as the starting point for body content when building a UI. To create flat\ncards, pair with a border.\n\n![](./_assets/elevation-surface-1.png)\n\n### Raised\n\nRaised elevations sit slightly higher than default elevations. They are reserved for cards that can\nbe moved, such as Jira and Trello cards. In special circumstances, they can be used for cards as a\nway to provide additional heirarchy or emphasis.\n\nAlways pair `elevation.surface.raised` with `elevation.shadow.raised`. This is particularly\nimportant in dark mode, where raised surfaces are lighter to help differentiate elevations.\n\n![](./_assets/elevation-raised-1.png)\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tUse raised elevations intentionally. If using for emphasis, limit to one section or focal point\n\t\tof the screen.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tRaised elevations can create visual noise, so don’t use to group content when a border or white\n\t\tspace would suffice.\n\t</DoDont>\n</DoDontGrid>\n\n### Overlay\n\nOverlay is the highest elevation available. It is reserved for a UI that sits over another UI, such\nas modals, dialogs, dropdown menus, floating toolbars, and floating single-action buttons.\n\nAlways pair `elevation.surface.overlay` with `elevation.shadow.overlay`. This is important in dark\nmode, where overlay surfaces are lighter to help differentiate elevations.\n\nOverlays can stack on top of other overlays.\n\n![](./_assets/elevation-overlay-1.png)\n\n### Overflow\n\nOverflow is a shadow indicating content has [scrolled](#scrolled) outside a view. It can be used for\nvertical or horizontal scroll. An example of overflow shadows is the horizontal scroll in tables on\na Confluence page.\n\n![](./_assets/elevation-overflow-1.png)\n\nIf box shadows are not technically feasible, use the combination of\n`elevation.shadow.overflow.spread` and `elevation.shadow.overflow.perimeter` to replicate the\noverflow shadow.\n\n## Interaction states\n\n### Hovered and pressed\n\nElevations use surface color changes to communicate hovered and pressed states. Use the hovered and\npressed elevation tokens to create these visual changes.\n\n![](./_assets/elevation-hovered.png)\n\nTransitions between elevations can be used as an alternative to hovered and pressed tokens, but only\nfor default and raised elevations (not overlays):\n\n- Transition to overlay elevation on hover\n- Transition to raised elevation on press\n\nThis approach should be used sparingly to avoid excessive animation. It should not be used for very\nsmall UI, as elevation changes are harder to see than surface color changes at this size.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tUse the recommended hovered and pressed tokens for interaction states on elevations.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tDon’t combine elevation transitions and hovered and pressed tokens for interactive states. Use\n\t\tone or the other.\n\t</DoDont>\n</DoDontGrid>\n\n#### Background change example\n\n<TokenElevationBackgroundChangeExample />\n\n#### Elevation change example\n\n<TokenElevationChangeExample />\n\n### Dragged\n\nUse the overlay elevation for any UI that is being dragged. Once moved, it returns to its original\nelevation.\n\n![](./_assets/elevation-dragged-1.png)\n\n### Scrolled\n\nWhen scrollable content exceeds the available area, a border or [overflow](#overflow) shadow can be\napplied at the point the content is cut off to indicate there is hidden content that can be scrolled\nback into view.\n\nA border is the default approach for scrolled content and can be seen in modal sticky headers and\nfooters, and top and side navigation.\n\n![](./_assets/elevation-scrolled.png)\n\n[Overflow](#overflow) shadows are reserved for experiences where a border might be easily missed,\nsuch as in very small UI or tables that use borders to separate cells.\n\nBoth approaches should apply the appropriate surface token where the content is being hidden.\n\n## All elevation tokens and values\n\nFor the full list of elevation design tokens and their values, see our\n[design token reference list](https://atlassian.design/components/tokens/all-tokens). Every token\ncomes with a description to help you ensure you’re using the correct one.\n\n## Best practices\n\n### Follow the recommended surface and shadow pairings\n\nRaised and overlay elevations have dedicated surface and shadow pairings.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: pairingDo, alt: \'\' }}>\n\t\tWhen creating elevations, always pair matching surface and shadow tokens.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: pairingDont, alt: \'\' }}>\n\t\tDon\'t mix different shadow and surface elevation tokens.\n\t</DoDont>\n</DoDontGrid>\n\n### Replace elevation surfaces with background colors only when required\n\nElevation surfaces use our\n[neutral palettes](https://atlassian.design/foundations/color#neutral-colors). If a different color\nis needed, surface tokens can be swapped for any solid background token. When using background\ntokens, align to the behavior of\n[interaction states for color tokens](https://atlassian.design/foundations/color#interaction-states).\n\n![](./_assets/background-colors.png)\n\n### Avoid excessive use of raised and overlay elevations\n\nThe shadows and surfaces of raised and overlay elevations can create busy UI if not applied\nintentionally. Follow the recommended guidance when considering these elevations.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: groupingDo, alt: \'\' }}>\n\t\tLimit the use of overlay elevations by grouping related buttons together in a floating toolbar\n\t\tif they are required to sit over another UI.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: groupingDont, alt: \'\' }}>\n\t\tDon’t have more than one floating button next to each other.\n\t</DoDont>\n</DoDontGrid>\n\n### Check contrast ratios\n\nAlways make sure your elevation and background choices are accessible.\n\n<DoDontGrid>\n\t<DoDont type="do">\n\t\tCheck the contrast ratio for UI on overlay surfaces in dark mode to ensure it meets\n\t\taccessibility requirements.\n\t</DoDont>\n\t<DoDont type="dont">\n\t\tDon\'t assume that because UI is accessible in light mode, it will be in dark mode. Some UI may\n\t\tneed tweaking.\n\t</DoDont>\n</DoDontGrid>\n\n## Z-index\n\nThe z-index determines the stacking order of elements. Elements with a higher z-index always sit in\nfront of elements with a lower z-index.\n\nDifferent UI can have the same elevation style, but each UI should apply a different z-index to\nindicate the layer(s) order in a stack (or where the elements touch).\n\n| Z-index | Example usage                                                                     | Elevation level |\n| ------- | --------------------------------------------------------------------------------- | --------------- |\n| 100     | None                                                                              | None            |\n| 200     | [Atlassian navigation](https://atlassian.design/components/atlassian-navigation/) | Default         |\n| 300     | [Inline dialog](https://atlassian.design/components/inline-dialog/)               | Overlay         |\n| 400     | [Popup](https://atlassian.design/components/popup/)                               | Overlay         |\n| 500     | [Blanket](https://atlassian.design/components/blanket/)                           | None            |\n| 510     | [Modal](https://atlassian.design/components/modal-dialog/)                        | Overlay         |\n| 600     | [Flag](https://atlassian.design/components/flag/)                                 | Overlay         |\n| 700     | [Spotlight](https://atlassian.design/components/onboarding/)                      | Overlay         |\n| 800     | [Tooltip](https://atlassian.design/components/tooltip/)                           | None            |\n\n## Related\n\n- Learn about the basics of [design tokens](https://atlassian.design/tokens/design-tokens).\n- See the list of [all design tokens](https://atlassian.design/components/tokens/all-tokens) for\n  full descriptions and values for all tokens.',
+  keywords: ['elevation', 'shadow', 'depth', 'z-index', 'layering', 'design tokens']
+}, {
+  content: '## Grid anatomy\n\nThe layout grid structure has three elements:\n\n- **Columns** divide the page into equal vertical sections, and are used to organise content.\n- **Gutters** are the gaps between the columns, and separate content in a consistent way.\n- **Margins** define the outer edges of the grid, and prevent content from spilling out over the\n  viewable regions.\n\n![](./_assets/grid-anatomy.png)\n\nThis grid documentation is for designers only. Engineers should refer to the\n[page layout](https://atlassian.design/components/page-layout/examples) component.\n\n## Grid types\n\nThere are two types of grid: fluid and fixed. Both grid types use breakpoints to determine whether\nthe layout needs to change between viewport sizes.\n\nMore guidance for [applying grid](https://atlassian.design/foundations/grid-beta/applying-grid/) in\nyour designs.\n\n### Fluid\n\nThe fluid grid stretches across the screen to fill all available space in the main content area.\nThis means the columns and the content placed within them scale and resize to fill the available\nspace.\n\n![](./_assets/grid-fluid.png)\n\nThey are best used for information-dense pages, such as kanban boards, to maximise screen real\nestate. Here’s how a fluid grid is applied in Jira:\n\n![](./_assets/grid-fluid-jira.png)\n\n### Fixed\n\nThe fixed grid applies the ideal maximum width to page containers according to the elements being\ndisplayed. There is both a fixed-narrow and fixed-wide grid, so content can be displayed using the\nmost appropriate width.\n\n![](./_assets/grid-fixed.png)\n\n**Fixed-narrow** grids are best used for content-focused pages, such as blogs and articles, to limit\nline length and improve readability. Some internal elements, such as headers, may break out of the\ngrid to span across the page. Here’s how a fixed-narrow grid is applied in Confluence:\n\n![](./_assets/grid-fixed-narrow.png)\n\n**Fixed-wide** grids are best used for content-dense pages, such as data tables, to balance screen\nreal estate and readability. Internal table columns do not need to align to the grid. Here’s how a\nfixed-wide grid is applied in Atlas:\n\n![](./_assets/grid-fixed-wide.png)\n\n## Breakpoints\n\nEach [breakpoint](https://atlassian.design/components/primitives/responsive/breakpoints/examples) is\nthe threshold at which the website’s layout changes, to ensure optimal user experience. In\nresponsive design, a breakpoint range determines the most appropriate number of columns for that\nviewport size, plus recommended widths for margins and gutters.\n\nOur grid aligns to the 6 Atlassian Design System breakpoints:\n\n<BreakpointsTable />\n\n## Column span and offset\n\n### Column span\n\nOur grid has 12 columns for\n[aligning content](https://atlassian.design/foundations/grid-beta/applying-grid/#step-4-align-content-to-grid).\nContent should span across 3 or more columns, up to a maximum of 12. For flexibility, mix and match\nthe number of columns used to unlock a variety of layouts across different breakpoints.\n\nA 12 column grid with content blocks spanning different numbers of columns, such as 12, 6 and 4\n\n![](./_assets/column-span.png)\n\n### Column offset\n\nContent does not need to span across all 12 columns. It can span a smaller set of columns, resulting\nin a layout with content centered on a 12 column grid.\n\n![](./_assets/column-offset.png)\n\n## Layout anatomy\n\n<SectionMessage title="Caution" appearance="warning">\n\tWe are in the process of building a new{\' \'}\n\t<Link href="https://atlassian.design/components/navigation-system/layout/examples">\n\t\tLayout (Early Access)\n\t</Link>{\' \'}\n\tcomponent which will replace this layout anatomy.\n</SectionMessage>\n\nLayout regions are the building blocks for any web page. They are composed of elements and\ncomponents that share similar functions. Atlassian’s layout grid starts below the top navigation,\nand provides structure to the main content.\n\n![](./_assets/layout-anatomy.png)\n\n### Side navigation and aside\n\nUse an aside to display supporting content on a screen, such as help panels or secondary tasks. The\nlayout grid typically fills the full width of the viewport, but when the side navigation or aside is\npresent, the grid should resize to fit the remaining area of the page.\n\n![](./_assets/aside.png)\n\nSome panels can be manually resized by users. Start with these standard sizes:\n\n<SideNavigationAsideTable />\n\nAsides have two states: default and collapsed.\n\n![](./_assets/aside-state.png)',
+  keywords: ['grid', 'layout', 'responsive', 'spacing', 'alignment', 'design system']
+}, {
+  content: '<SectionMessage title="Caution" appearance="warning">\n\tWe are in the process of building a new{\' \'}\n\t<Link href="https://atlassian.design/components/navigation-system/layout/examples">\n\t\tLayout (Early Access)\n\t</Link>{\' \'}\n\tcomponent which will change how you apply grid.\n</SectionMessage>\n\n## Usage guidelines\n\nOur new grid component has inbuilt side panels, including the side navigation and aside, which\nautomatically resizes the grid to cover the main content area. To set up the grid:\n\n1. Determine grid **type**\n2. Select grid **breakpoint**\n3. Configure **sideNavigation** and **aside**\n4. Align content to grid\n\n![](./_assets/grid-figma.png)\n\n## Step 1: Determine grid type\n\nThere are 2 [grid types](https://atlassian.design/foundations/grid-beta/#grid-types):\n\n- **Fluid** grids fill the width of the screen\n- **Fixed** grids stretch to a max-width and then remain centered\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: gridFluidDo, alt: \'\' }}>\n\t\tUse fluid grids for information-dense pages, such as kanban boards, to maximise screen real\n\t\testate.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: gridFluidDont, alt: \'\' }}>\n\t\tDon’t use fluid grids for content-focused pages. Long line lengths impair readability.\n\t</DoDont>\n\t<DoDont type="do" image={{ url: gridFixedDo, alt: \'\' }}>\n\t\tUse fixed grids for content-focused pages, such as blogs and articles, to improve readability.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: gridFixedDont, alt: \'\' }}>\n\t\tDon’t use fixed grids for information-dense pages. Limiting screen space will truncate important\n\t\tcontent.\n\t</DoDont>\n</DoDontGrid>\n\n## Step 2: Select grid breakpoint\n\nThere are 6 [grid breakpoints](https://atlassian.design/foundations/grid-beta/#breakpoints):\n\n- **XXS**, **XS** and **S** for small viewports from 320-1023px\n- **M**, **L** and **XL** for large viewports from 1024+px\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: gridBreakpointSpanDo, alt: \'\' }}>\n\t\tSpan only the main content container. Exclude the side navigation and asides.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: gridBreakpointSpanDont, alt: \'\' }}>\n\t\tDon’t span the entire screen width or include asides. The grid spacing is suitable for main\n\t\tcontent only.\n\t</DoDont>\n\t<DoDont type="do" image={{ url: gridBreakpointWidthDo, alt: \'\' }}>\n\t\tSet the grid breakpoint to the full viewport width.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: gridBreakpointWidthDont, alt: \'\' }}>\n\t\tDon’t set the breakpoint to the container width. The grid spacing is scaled for the full\n\t\tviewport width.\n\t</DoDont>\n\t<DoDont type="do" image={{ url: gridBreakpointChangeDo, alt: \'\' }}>\n\t\tChange the breakpoint using the component variant.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: gridBreakpointChangeDont, alt: \'\' }}>\n\t\tDon’t change the breakpoint by resizing the grid container. The linked grid styles will map\n\t\tincorrectly.\n\t</DoDont>\n\t<DoDont type="do" image={{ url: gridBreakpointDesignsDo, alt: \'\' }}>\n\t\tProvide designs for at least 2 breakpoints, preferably more and for different devices.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: gridBreakpointDesignsDont, alt: \'\' }}>\n\t\tDon’t provide designs for only 1 breakpoint. Engineers need layout guidance for other\n\t\tbreakpoints too.\n\t</DoDont>\n</DoDontGrid>\n\n## Step 3: Configure side navigation and aside\n\nThere are 2 types of panels:\n\n- **Side navigation**: generally on the left, with collapsed and default states\n- **Aside**: generally on the right, with collapsed and default states where widths change at\n  different breakpoints\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: gridAsideDo, alt: \'\' }}>\n\t\tFollow the standard aside widths that are defined in the grid component properties.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: gridAsideDont, alt: \'\' }}>\n\t\tDon’t create custom aside sizes. This leads to inconsistent page layouts.\n\t</DoDont>\n</DoDontGrid>\n\n## Step 4: Align content to grid\n\nThe vast majority of content should align to the grid, but exceptions can be made based on context.\nUse [spacing tokens](https://atlassian.design/foundations/spacing/) and\n[layout primitives](https://atlassian.design/foundations/spacing/primitives/) to structure content\nthat doesn’t align to the grid.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: gridAlignFigmaDo, alt: \'\' }}>\n\t\tUse auto layout in Figma to align content, with appropriate spacing tokens.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: gridAlignFigmaDont, alt: \'\' }}>\n\t\tDon’t manually align content or set custom (non-token) values. This is not scalable and creates\n\t\troom for error.\n\t</DoDont>\n\t<DoDont type="do" image={{ url: gridAlignElementsDo, alt: \'\' }}>\n\t\tAlign large content elements, such as cards to the grid.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: gridAlignElementsDont, alt: \'\' }}>\n\t\tDon’t align small content elements, such as button groups, to the grid. Instead, use layout\n\t\tprimitives.\n\t</DoDont>\n\t<DoDont type="do" image={{ url: gridAlignColumnsDo, alt: \'\' }}>\n\t\tAlign content across any number of columns required.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: gridAlignColumnsDont, alt: \'\' }}>\n\t\tDon’t allow content to overflow into gutters and margins, as this does not align with the grid.\n\t</DoDont>\n</DoDontGrid>',
+  keywords: ['grid usage', 'responsive design', 'breakpoints', 'columns', 'gutters']
+}, {
+  content: 'Icons are symbols designed to represent concepts or specific features. A company\'s iconography style\ncan express a lot about a brand and its values.\n\nAtlassian\'s iconography has rounded corners and curves to align with our typography and other\nrounded UI elements, whilst square end terminals add boldness to create a harmonious app expression\nof Atlassian\'s broader design language.\n\n## Iconography principles\n\nFollow these principles to design and use Atlassian icons in a cohesive, useful, and legible way.\n\n**Design for universal understanding**\n\nDesign icons that use widely recognized symbols and established visual metaphors. Ensure icons are\neasily understood by a diverse audience by avoiding specific cultural or language aspects.\n\n**Balance simplicity and detail to create legibility**\n\nCraft icons that are simple enough for quick recognition, yet detailed enough to convey meaning\neffectively, even at small sizes.\n\n**Maintain visual harmony**\n\nEnsure icons work together as a cohesive system by adhering to consistent size, shape, and style\nguidelines across the entire set.\n\n**Use icons intentionally**\n\nIcons are powerful signifiers that can aid comprehension and help with navigation. They can also add\nclutter or confuse people when used poorly. Use text labels to support icons wherever possible, and\navoid using icons where they aren’t necessary.\n\n## Using Atlassian icons\n\nAtlassian icons are available as a component (React), Figma library, and in our documentation:\n\n- [View Atlassian icons](https://atlassian.design/components/icon)\n- [Icon component usage](https://atlassian.design/components/icon/usage)\n- [Icon tile component](https://atlassian.design/components/icon/icon-tile)\n- [Figma library of Atlassian icons (Atlassian employees only)](https://go.atlassian.com/ads-icons-figma)\n\n## Visual style\n\nAtlassian’s icon style has a 1.5px stroke width with shapes that pair rounded corners with sharp\ninterior corners and square line caps.\n\n### Simplicity and metaphor\n\nWherever possible, use [existing icons](https://atlassian.design/components/icon) to maintain\nconsistency and reinforce visual concepts across Atlassian apps so they become familiar to\ncustomers.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: consistencyDo, alt: \'\' }}>\n\t\tUse an existing icon or visual metaphor for consistency and clarity wherever possible.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: consistencyDont, alt: \'\' }}>\n\t\tCreate a new icon if a suitable one already exists to represent the same metaphor.\n\t</DoDont>\n</DoDontGrid>\n\nUse simplified shapes with the minimum detail required to express a metaphor. The goal of an icon is\nto aid clear, quick comprehension — excess detail can distract and do the opposite. The small size\nof icons makes it harder to see fine details, so optimise for simplicity and legibility.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: simplifiedShapesDo, alt: \'\' }}>\n\t\tUse simple shapes with the minimum detail required to express a metaphor with clarity and\n\t\tlegibility.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: simplifiedShapesDont, alt: \'\' }}>\n\t\tDon’t add excess detail. This may distract and be challenging to understand at a small sizes.\n\t</DoDont>\n</DoDontGrid>\n\nWhen creating a new icon, use symbols that clearly represent a concept. Try to use metaphors with\nclear and established associations wherever possible.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: metaphorsDo, alt: \'\' }}>\n\t\tUse familiar symbols with clear and established associations that clearly represent a concept.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: metaphorsDont, alt: \'\' }}>\n\t\tUse caution when creating an icon that isn’t a widely recognized symbol. It may be confused with\n\t\tanother concept or misunderstood.\n\t</DoDont>\n</DoDontGrid>\n\n### Perspective and angles\n\nShapes should appear straight on or from a full 90 degree profile. Don’t use diagonal perspectives\nto create 3D shapes because these can be hard to discern at a glance, especially for people with\nsome cognitive disabilities.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: perspectiveDo, alt: \'\' }}>\n\t\tUse shapes that appear straight on without dimensionality.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: perspectiveDont, alt: \'\' }}>\n\t\tDon’t use diagonal perspectives to create 3D shapes as they can be hard to discern at a glance.\n\t</DoDont>\n</DoDontGrid>\n\n### Size and spacing\n\nSystem icons are drawn within a 16 × 16px bounding box and are available in two sizes:\n\n#### Medium (16px) — use in most cases\n\nMedium icons are 16 × 16px in size and are the **default** size in our system. This size balances\nharmoniously with body text and the density of Atlassian’s apps.\n\n#### Small (12px) — Use sparingly\n\nSmall icons are 12 × 12px in size and are downscaled from their 16px counterpart. This size should\nbe used sparingly as they aren\'t as legible as 16px icons. Limit usage of 12px icons to the\nfollowing uses:\n\n- **Chevrons** — always use 12px chevrons, particularly within buttons, icon buttons, and dropdowns\n  to maintain cohesion with Atlassian\'s visual language.\n\n- **Field validation messaging** — use 12px status icons for information, warnings, and errors.\n\n- **Within small contained elements** — 12px icons balance with small text within tags, badges,\n  statuses, and other similar compact elements.\n\n- **App affiliation** — use 12px icons for "Powered by Atlassian Intelligence" or other Atlassian\n  app affiliations.\n\n- **Secondary actions** — use 12px icons to communicate hierarchy between primary way-finding icons\n  and secondary actions so they don’t compete for attention.\n\n- **Supporting role** — use 12px icons for supporting actions that shouldn\'t draw attention away\n  from important content.\n\n![](./_assets/icon_sizing_options.png)\n\nTo apply spacing around an icon, we recommend placing it within a Box primitive with a padding value\napplied from our spacing system.\n\nWhen larger icons sizes are needed for decorative purposes, consider using an\n[icon tile](https://atlassian.design/components/icon/icon-tile) which places the icon on a colored\nbackground tile. Icon tiles are available in multiple sizes and provides accessible icon and\nbackground color pairings.\n\n### Shapes\n\nIcons use consistent shapes to ensure a consistent look and feel across the set. We’ve designed each\nshape for optical scale and balance, so that taller, thinner shapes don’t feel like a different\nscale from shorter or wider shapes.\n\n![](./_assets/Keyline_shapes.png)\n\nWhen designing new icons, you can use our icon template with built-in keyline shapes to guide your\ndesigns.\n\nReusing existing shapes from other icons can also help with consistency across the set. Make sure to\nuse shapes that best represent the object metaphor you are expressing.\n\n### Corners and curves\n\nCurved edges lend to a friendlier feel, but keep internal edges sharp to maintain clarity.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: cornersDo, alt: \'\' }}>\n\t\tWhere possible, keep internal angles sharp.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: cornersDont, alt: \'\' }}>\n\t\tDon’t apply curves on internal anchor points.\n\t</DoDont>\n</DoDontGrid>\n\n### End caps\n\nEnd points should be squared off, not rounded.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: endPointsDo, alt: \'\' }}>\n\t\tSet end point style to "none" to ensure the path aligns with a pixel edge to prevent blurry\n\t\tresults.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: endPointsDont, alt: \'\' }}>\n\t\tDon’t use "round" or "square" stroke end point styles.\n\t</DoDont>\n</DoDontGrid>\n\n### Color\n\nLike most elements in our system, icons use design tokens for colors. Icons can use icon-specific\ncolor tokens or text color tokens for when you\'re matching an icon and text color. You can set the\ncolor of the icon using the\n[icon component](https://atlassian.design/components/icon/code#UNSAFE_IconNew-color).\n\nBoth icon and text color tokens are designed to have enough color contrast against backgrounds and\nsurfaces in Atlassian apps.\n\n## Contribution and adding new icons\n\nCurrently Atlassian teams can contribute icons to our system for new designs and features.\n\n- Before contributing an icon, look at our existing icon library and consider the following\n  questions:\n- Is the icon I’m contributing very similar to another system icon?\n- Can I use an existing multi-purpose icon?\n- Could my icon be confused with another concept that exists in apps?\n- Does this design really require an icon at all? Would a text label, button, or other approach\n  provide a clearer affordance for customer understanding?\n\nTo contribute a new icon, follow the\n[contribution guide (Atlassian employees only)](https://go.atlassian.com/ads-icon-contribution).\n\n## Related\n\n- Browse all icons and learn how to use them in apps with the\n  [icon component](https://atlassian.design/components/icon).',
+  keywords: ['iconography', 'icons', 'visual design', 'symbols', 'brand', 'component design']
+}, {
+  content: 'import {\n\tTypographyPrinciples,\n\tTypographyHeadingTable,\n\tTypographyBodyTable,\n\tTypographyMetricTable,\n\tTypographyCodeTable,\n} from \'@af/design-system-docs-ui\';\n\n\n\nimport {\n\tAtlassianLogoCard,\n\tAttributionCards,\n\tPropertyCards,\n\tAppCards,\n} from \'./_logo-asset-cards.partial\';\n\n\n\n\n\n\n\n\n\n<SectionMessage title="Download logos" appearance="information">\n\t<Text>\n\t\tThe full set of app (product) logos are available in{\' \'}\n\t\t<Link href="https://orangedam.atlassian.com/">Atlassian Mosaic</Link>\n\t</Text>\n</SectionMessage>\n\nThis page includes downloadable logo files for use in marketing contexts as well as specific usage\nguidance for app or marketing contexts.\n\nIf you want to add logos to app (product) experiences, use the\n[logo component](https://atlassian.design/components/logo/examples).\n\n## Download the logos\n\nEach downloadable file includes variations of color and layout in approved formats and the below\nelements combined together:\n\n- logomarks – the icon portion of a logo\n- wordmarks – the name of the app (product) or property\n- straplines or other secondary text.\n\nAssets for isolated logomarks are also included.\n\n![Annotated graphic of the Atlassian logo, showing the logomark, strapline and wordmark.](./_assets/logo-anatomy.png)\n\n### Our iconic Atlassian logo\n\nOur iconic company logo.\n\nInclude `Atlassian` as the alt-text for the logo in digital experiences.\n\n<AtlassianLogoCard />\n\n#### Atlassian app strapline\n\nThe Atlassian logomark and wordmark can be coupled with a list of app (product) names under it.\nFollow the below guidance when using logos that contain straplines:\n\n- Always centre the app names under the logo and don’t scale the logo below 280px wide.\n- Write Atlassian and the app name in the alt-text in digital experiences.\n\n![Logo strapline with Jira, Confluence, Trello and Bitbucket wordmarks center-aligned beneath the Atlassian logo.](./_assets/logo-centered.png)\n\n### Attribution logos\n\nThe attribution logos are a type of lockup that combine app (product) or property logomarks with the\nAtlassian strapline.\n\nThey create consistency in our portfolio, and help customers connect them with our overall Atlassian\nbrand. Follow the below guidance when using attribution logos:\n\n- Only use attribution logos when the Atlassian context is not clear. For example, in\n  advertisements, videos, and white papers. You don’t need to use them on Atlassian properties like\n  [www.atlassian.com](https://www.atlassian.com) or in app (product) user interfaces.\n- Never compose your own attribution logos or deconstruct the official assets.\n- Write the name of the app (product)/property and Atlassian in the alt-text for in digital\n  experiences.\n\n<AttributionCards />\n\n### Property logos\n\nThe Atlassian program and property logos are a lockup of the Atlassian logomark and wordmark and the\nname in Charlie Sans. Follow the below guidance when using property logos:\n\n- On a white background, the program name is rendered in neutral with the logo in primary blue. On\n  darker backgrounds, both program and logo are white.\n- Write `Atlassian` and the name of the property as the alt-text in digital experiences.\n\n<PropertyCards />\n\n### App (product) logos\n\nWith the Atlassian System of Work and collections framework our primary products, secondary products\nand plaftform features are now referred to as apps.\n\nWe’ve updated our logos to reflect this change, using marks that symbolize functionality, contained\nin a tile. An app’s glyph is chosen based on the apps functionality; its tile color refers to its\ncollection.\n\nThe logomarks are contained by a tile shape, colored with their associated collection. Follow the\nbelow guidance when using App (product) logos:\n\n- Use when the Atlassian context is clear.\n- If you need to connect the app to Atlassian, use an attribution logo instead. For example, in a\n  video or advertisement.\n- Write the name of the apps in the alt-text in digital experiences.\n\nAssets include both isolated logomarks and lockups with wordmarks.\n\n<AppCards />\n\n#### Logomarks\n\nA logomark is a symbol or icon shown without the app (product)/property name or brand workmark. For\nan app (product), this refers to the tile. Follow the below guidance when using logomarks:\n\n- If you’re including the logomark in product experiences, use the\n  [icon](https://atlassian.design/components/logo/examples#icon) variant of the logo component.\n- Only use logomarks on their own when the context is very clear and where possible pair with\n  descriptive text.\n- Write `Atlassian` or the app/property name in the alt-text in digital experiences.\n\n![](./_assets/lockups-nav.png)\n\nLogomarks are paired with native text in top navigations.\n\n![](./_assets/logos-contained-logomarks.png)\n\nLogomarks are suitable when rendering the app name natively in its environment is more legible and\nuser-friendly.\n\n![](./_assets/logos-jira-app-store.png)\n\nLogomarks can be used when environmental restrictions do not allow for proper clearance guidelines\nto be followed for full logos.\n\n#### Logomark shape and size\n\nThe [logo](https://atlassian.design/components/logo) component comes in specific sizes and the\nlogomark has a pre-defined radius. These should not be altered.\n\nThe exception to this is when appearing on external sources such as Apple mobile apps and Google\nMarketplace where specific container shapes need to be used.\n\nLogomarks should never be nested inside additional containers.\n\n<DoDontGrid>\n\t<DoDont type="do" image={{ url: tileRadiusDo, alt: \'\' }}>\n\t\tUse the default radius values that are applied to the backgrounds of app logo icons.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: tileRadiusDont, alt: \'\' }}>\n\t\tDon’t adjust the radius values of the backgrounds of product logo icons.\n\t</DoDont>\n\t<DoDont type="do" image={{ url: containersDo, alt: \'\' }}>\n\t\tAllow breathing room around product logo icons.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: containersDont, alt: \'\' }}>\n\t\tDon’t add unnecessary containers around app logo icons.\n\t</DoDont>\n</DoDontGrid>\n\n### Aligning logos\n\n#### Align logomarks with other elements\n\n- Middle align with the logo mark when the copy is less than the height of the container.\n- Top-align or stack below with center-alignment if it’s taller than the container.\n\n![](./_assets/logos-alignment-ratio.png)\n\n#### Aligning app (product) logos\n\nWhere app (product) logos are arranged in a vertical or horizontal list, use the height or weight of\nthe logomark portion to align.\n\n![](./_assets/tile-align-horizontal.png) ![](./_assets/tile-align-vertical.png)\n\n## Logo clearance\n\nWhen displaying logos outside of an app UI, surround them with clear space free of type, graphics,\nand other elements that might cause visual clutter.\n\n#### Ideal clearance — Atlassian logo\n\n![](./_assets/clearance-horizontal.png) ![](./_assets/clearance-vertical.png)\n\n#### Minimum clearance — Atlassian logo\n\nUse the capital "A" of the Atlassian wordmark to define the minimum clearance around the logo.\n\n![](./_assets/top-bottom-clearance-atlassian.png)\n\n#### Ideal clearance — app (product) logo\n\n![](./_assets/logos-ideal-clearance-app.png)\n\n#### Minimum clearance — app (product) logo\n\nUse the height and width of the logo wordmark to find the minimum clearance around the logo.\n\n![](./_assets/top-bottom-clearance-app.png)\n\n## Color options\n\nLogos are available in three color options to suit different colored environments – Brand, inverse\nand neutral.\n\n![](./_assets/logo-stack-colors.png)\n\nDon’t edit or place logos in ways that reduce the clarity and legibility of the image.\n\n<DoDontGrid>\n\t<DoDont type="dont" image={{ url: colorDont, alt: \'\' }}>\n\t\tDon’t use unapproved color combinations.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: shadowDont, alt: \'\' }}>\n\t\tDon’t use a drop shadow.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: legibilityDont, alt: \'\' }}>\n\t\tDon’t use the logo on top of complex backgrounds.\n\t</DoDont>\n\t<DoDont type="dont" image={{ url: outlineDont, alt: \'\' }}>\n\t\tDon’t outline the logo.\n\t</DoDont>\n</DoDontGrid>',
+  keywords: ['logos', 'brand', 'identity', 'logo usage', 'brand guidelines']
+}, {
+  content: '## About radius tokens\n\nRadius tokens standardize corner roundness, ensuring consistency and cohesion throughout all of our\napps. Pair radius tokens with radius focus tokens to bring focus to the selected element. This helps\nusers identify which element is active.\n\n## Radius tokens and usage guidelines\n\nUse radius tokens to apply roundness across different states and use cases.\n\n<Stack space="space.200">\n\t<RadiusTable />\n\t<Text>* Token values are subject to change and should be used as an indication only.</Text>\n</Stack>\n\n## Radius examples and usage\n\n### Extra small\n\nUse the `radius.xsmall` token for extra small detail elements like badges, checkboxes, avatar\nlabels, and keyboard shortcuts.\n\n![Two examples, one of checkboxes and one of keyboard shortcuts in a tooltip, both of which use the "radius.xsmall" token.](./_assets/radius-xsmall.png)\n\n### Small\n\nUse the `radius.small` token for small elements like labels, lozenges, timestamps, tags, dates,\ntooltip containers, imagery inside tables, and compact buttons.\n\n![Examples of lozenges, tooltips, dates and photos in a section that all use the "radius.small" token.](./_assets/radius-small.png)\n\n### Medium\n\nUse the `radius.medium` token for interactive elements like buttons, inputs, text areas, selects,\nnavigation items, and smart links.\n\n![Examples of buttons, smart links, text fields, dropdowns, and navigation menu items all using the "radius.medium" token.](./_assets/radius-medium.png)\n\n### Large\n\nUse the `radius.large` token for elements like cards, in-page containers, floating UIs, and dropdown\nmenus.\n\n![Two examples, one of a progress summary card and one of a Jira work item on a board, both of which use the "radius.large" token.](./_assets/radius-large.png)\n\n### Extra large\n\nUse the `radius.xlarge` token for full-page containers, large containers, modal dialogs, Kanban\ncolumns, and tables.\n\n![Two examples, one of a confirmation dialog and one of a table, both of which use the "radius.xlarge" token.](./_assets/radius-xlarge.png)\n\n### Extra extra large\n\nUse the `radius.xxlarge` token for video players.\n\n![An example of the Loom video player using the "radius.xxlarge" token.](./_assets/radius-xxlarge.png)\n\n### Full\n\nUse the `radius.full` token for avatars, names, user-related UI, and emoji reactions. This token can\nalso be used for dividers and other pill-shaped elements since it results in a fully round radius.\n\n![A mix of circular and pill-shaped examples of avatars, user mentions, and name cursors all using the "radius.full" token.](./_assets/radius-full.png)\n\n### Tile\n\nUse the `radius.tile` token exclusively for tile components, such as icon tile or object tile. This\ntoken should not be used outside of tiles.\n\n![An example of tile objects all using the "radius.tile" token.](./_assets/radius-tile.png)\n\n## Radius token for focus state\n\nA component\'s focus state is critical for accessibility. The corner radius of the focus ring must\nalign visually with the component it surrounds.\n\n### Focus state design specifications\n\n![Diagram showing an interactive element with a blue focus ring offset by 2px. A note explains “Focus ring radius = element radius + 2px,” illustrating how the focus ring\'s corner radius is calculated relative to the component.](./_assets/focus-ring-1.png)\n\nThe focus ring is implemented in two key ways:\n\n1. **Offset**: The focus ring is positioned 2px away from the component\'s bounding box.\n2. **Radius value**: The corner radius of the focus ring is always +2px greater than the component’s\n   base corner radius value.\n\n### How to implement the focus ring for code and design\n\nThe focus ring is managed differently between code and design:\n\n- **In code**: When you’re using interactive design system components, focus rings are automatically\n  applied. When you’re building custom components, use the\n  [focusable component](https://atlassian.design/components/primitives/focusable/examples). The 2px\n  visual offset and the radius calculation (component radius +2px) are automatically handled by the\n  focusable component\'s logic. This means developers never need to apply a separate radius token for\n  the focus state.\n- **In design**: Automatic calculations aren’t possible in design tools, so designers must use a\n  dedicated set of tokens to enforce the correct radius relationship. These tokens mirror the\n  component radius names but carry the calculated +2px value to ensure visual accuracy in design\n  files.\n\n![Diagram of a button showing the base radius of "radius.medium" and its corresponding focus‑state radius token "radius.focus.medium" relationship.](./_assets/focus-ring-2.png)\n\n<Stack space="space.200">\n\t<RadiusFocusTable />\n\t<Text>* Token values are subject to change and should be used as an indication only.</Text>\n</Stack>',
+  keywords: ['radius', 'border radius', 'corners', 'roundness', 'design tokens', 'visual consistency']
+}, {
+  content: "The consistent and intentional use of a spacing system creates a more harmonious experience for the\nend user. A spacing system also lays a foundation for responsive design and customisable UI density\nin the future, which will enhance the overall quality and accessibility of our apps.\n\n## 8 pixel base unit\n\nOur spacing system is built around a base unit of 8 pixels. This base unit determines the spacing\nscale and ensures visual consistency across apps.\n\n## Scale\n\nBuilding off of the 8px base unit, the main foundation of our spacing system is the spacing scale.\nThis scale is a limited set of space values that can be used to lay out UI elements in a consistent\nway.\n\nEach spacing value is a multiple of the base unit and ranges from 0px to 80px to allow for\nflexibility while still maintaining consistency across different layouts.\n\n## Space tokens\n\nThe 8px base unit also forms the basis of our space token system, as the base unit `space.100`.\nEvery space token is a multiple of this base unit, the number suffix representing the percentage of\nthe base unit.\n\nFor example, `space.200` is 200% of the size of the base unit, therefore represents 16px.\n\nEach space token should be used in place of the raw pixel or REM values when adding space between\ncomponents or objects on a page. Usage examples are detailed below.\n\n<SpacingTokensTable />\n\n### Negative values\n\nOur space token system also includes\n[negative values](https://atlassian.design/components/tokens/all-tokens#space) from\n`space.negative.025` to `space.negative.400` (-2px to -32px) available in code. These can be useful\nfor breaking out of a container's padding or for overlapping elements. Before reaching for negative\ntokens, see if you can use the\n[Bleed primitive](https://atlassian.design/components/primitives/bleed/example) which is designed\nspecifically to handle negative whitespace.\n\n## Spacing usage\n\nDifferent use cases require different ranges of spacing units to achieve the best outcomes. Our\nspacing scale can be broken into three different size ranges:\n\n![A horizontal number scale diagram with 0 pixels on the left hand side and 80 pixels on the right hand side, these are the minimum and maximum values on the scale. The 8 pixel unit is highlighted as the space.100 base token. The scale is then broken up into three sections through purple highlighting. There are Small token values from 0 pixels to 8 pixels, Medium token values from 12 pixels to 24 pixels and Large token values from 32 pixels to 80 pixels.](./_assets/spacing-scale.png)\n\n### Small values - 0px to 8px\n\nUse the tokens from `space.0` to `space.100` (0px to 8px) for small and compact pieces of UI.\n\n#### Examples\n\n- Gap between small icons and text\n- Container padding of small components (ie badges, icon buttons, table cells)\n- Gap between repeating elements (ie button groups)\n- Padding within input components\n- Vertical spacing between elements in a card (ie a title and description, a description and\n  actions)\n- Gap between the trigger and elevated element (ie between dropdown button & menu)\n\n### Medium values - 12px to 24px\n\nUse the tokens `space.150` to `space.300` (12px to 24px) for larger and less dense pieces of UI.\n\n#### Examples\n\n- Container padding of larger components (ie buttons)\n- Space between avatar/large icon and content (ie section messages)\n- Vertical spacing between elements in cards\n- Spacing between items in less densely packed or larger components\n\n### Large values - 32px to 80px\n\nUse the tokens `space.400` to `space.1000` (32px to 80px) for the largest pieces of UI and for\nlayout elements.\n\n#### Examples\n\n- The space between content on the page (ie spacing between top of page and header)\n- Alignment within larger pieces of content (ie alignment of content in Flag)\n\n## Layout guidelines\n\nA layout is composed of UI elements and components as well as the space between them. Applying these\nguidelines helps customers quickly understand the relationship between elements, allowing them to\nscan and digest page content with ease.\n\nUse these guidelines in combination with space tokens to create layouts that are consistent and easy\nto understand.\n\n### Group by similarity\n\nUsers expect elements to be grouped semantically, or grouped in such a way that it provides greater\ncontext around the information provided.\n\nUsing consistent spacing around elements lends them a visual similarity that helps the user\nunderstand their semantic relationship. For example, a table or list of items should be spaced\nconsistently to create the sense of a cohesive unit or collection.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: similarityDo, alt: '' }}>\n\t\tGroup similar items together using similar spacing.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: similarityDont, alt: '' }}>\n\t\tGroup similar items differently.\n\t</DoDont>\n</DoDontGrid>\n\n### Group by proximity\n\nThe distance between elements creates semantic meaning, elements that are placed close to one\nanother are assumed to be related.\n\nUse this principle to create meaning by placing more related objects closer together, and less\nrelated objects further apart. For example, place elements that are part of the same flow or user\naction closer together so users can understand their relation.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: proximityDo, alt: '' }}>\n\t\tGroup related items close together so that users can scan the content more easily.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: proximityDont, alt: '' }}>\n\t\tGroup related items far apart.\n\t</DoDont>\n</DoDontGrid>\n\n### Create order and hierarchy\n\nUsers look for order in visual information to reduce the mental effort required to scan and process\ndata. Therefore, the ordering of elements on a page can be used to encourage users to follow a\ncertain flow or journey.\n\nHierarchy is used to rank elements and influence the order in which users view them. The sizing of\ndifferent elements lends more importance to larger elements by drawing focus, and less to\nsmaller-sized elements. Similarly, varying the amount of whitespace around an element can be used to\ngroup elements together or separate them to impart greater importance.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: hierarchyDo, alt: '' }}>\n\t\tUse scale and whitespace to rank elements.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: hierarchyDont, alt: '' }}>\n\t\tGive every element the same visual importance.\n\t</DoDont>\n</DoDontGrid>\n\n### Introduce visual rhythm\n\nPatterns of alternating elements and white space create visual rhythm, which influences way users\nscan a page and focus their attention.\n\nUsing a pattern of similar spacing between elements (such as in a table or list) creates a\npredictable rhythm for the user to follow. This consistent rhythm reinforces the similarity in\nimportance of each of these elements.\n\nVarying the spacing between and sizing of objects creates a more organic flow and guides the user\nthrough a page or experience naturally. Variation creates points of attention and contrast between\nobjects on the page and improves scannability.\n\n![](./_assets/visual-rhythm.png)\n\n### Use optical adjustment\n\nWhile using a spacing system improves consistency, the visual harmony of a page may not be perfect\nthe first time. The visual weight of an element affects the size and spacing that may be required to\ncreate balance on the page, and may deviate from standard spacing patterns. Optical adjustments\nshould be used to correct these imbalances and maintain the page’s flow.\n\nOptical adjustments require using the spacing scale units and visual intuition to make minor changes\nto the spacing between objects in order to create visual harmony.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: opticalAdjustmentDo, alt: '' }}>\n\t\tAdjust spacing to create visual balance.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: opticalAdjustmentDont, alt: '' }}>\n\t\tUse standard spacing without considering its alignment with other elements.\n\t</DoDont>\n</DoDontGrid>\n\n## Related\n\n- Learn more about [design tokens](https://atlassian.design/tokens/design-tokens)\n- [List of all design tokens](https://atlassian.design/components/tokens/all-tokens)",
+  keywords: ['spacing', 'whitespace', 'gaps', 'margins', 'padding', 'design tokens', 'layout']
+}, {
+  content: 'Primitive components are a new type of component that assist with layout and the visual placement of\nchild elements. They act as building blocks to compose different parts of the user experience, from\nthe smallest design decisions (for example the spacing around an icon) to more complex layout\ndecisions with multiple primitives used in conjunction (for example how a page is structured).\n\nPrimitives are designed to work hand in hand with\n[design tokens](https://atlassian.design/tokens/design-tokens), to provide opinionated solutions for\ncommon low-level design decisions, such as\n[color choice](https://atlassian.design/foundations/color) or\n[spacing between elements](https://atlassian.design/foundations/spacing). They make it easier to\nimplement our design tokens and best practices.\n\n![](./_assets/primitives.png)\n\nPrimitive components are implemented in code, but it is important for designers to understand how\nthey may be used in their designs. There are currently three primitives available for use, and each\nis responsible for a different layout behaviour.\n\n## Box\n\nA generic container with managed access to design tokens. Box is a flexible and fundamental building\nblock for a UI, and can be the primary way to apply styling to its contents.\n\nIn the example below, a box encapsulates the card components and is used to set both the margin\nspacing, as well as the background color styling.\n\nIt’s important to note that a box could also be used for each of the cards themselves to apply\nfurther spacing and specific styling.\n\n![](./_assets/box.png)\n\n## Inline\n\nA layout container that lays out child elements horizontally (inline with each other).\n\nIn the example below, an inline contains the card components and sets the horizontal spacing between\nthem.\n\n![](./_assets/inline.png)\n\n## Stack\n\nA layout container that stacks child elements vertically.\n\nIn the example below, a stack is used to vertically divide the heading from the card components, and\na second stack is used to vertically divide the card components, each with different spacing.\n\n![](./_assets/stack.png)\n\n## Figma auto layout\n\nFor designers using Figma, auto layout is the tool of choice for creating responsive layouts. Auto\nLayout works by applying vertical or horizontal layouts to Frames. These Frames can then be nested\nand have specific spacing applied (using the `space between items` control in dimensions) in order\nto create more complex but flexible designs.\n\nPrimitives behave in very similar way to frames using Figma auto layout:\n\n- A Box can be thought of as a frame through which specific styling can be applied to the contents,\n  and the `horizontal padding` and `vertical padding` applied around it.\n- An Inline can be thought of as a frame with `horizontal space between items` applied.\n- A Stack can be thought of as a frame with `vertical space between items` applied.\n\nWhen working in Figma a designer is combining the concept of a box as a container with either an\ninline or stack to create layouts. In code, these layers are represented separately, with a box\noften being an outer container with an inline or stack nested inside (with potentially more nested\nprimitives inside).\n\nJust as it’s very unlikely to use only a single Frame in your design, Primitives are designed to be\nused in conjunction with one another in order to fully represent more complex designs.\n\n## Handover\n\nBecause primitive components are not surfaced in Figma, designers will not be using these components\ndirectly. However, it’s important for designers to understand how they work and how they might be\nused in code, as primitives will increase parity between components in designs and code.\n\nThe most useful way designers can help with the implementation of primitives is using Figma Auto\nLayout in their designs thoughtfully, and ensuring that designs use space tokens in their designs\nwhere possible.\n\n## Related\n\n- [Implementing Primitive components in code](https://atlassian.design/components/primitives/overview)\n- [Use box for a generic container with access to design tokens](https://atlassian.design/components/primitives/box/examples)\n- [Manage horizontal layout using an inline component](https://atlassian.design/components/primitives/inline/examples)\n- [Manage vertical layout using a stack component](https://atlassian.design/components/primitives/stack/examples)',
+  keywords: ['spacing primitives', 'space tokens', 'measurement', 'consistency', 'spacing scale']
+}, {
+  content: "Design tokens are the new way to apply visual foundations in Atlassian app experiences. We’re\nrolling out tokens to standardize colors, elevations, spacing, and other styles in Atlassian apps.\n\n## What are design tokens?\n\nDesign tokens are name and value pairings that represent small, repeatable design decisions. A token\ncan be a color, font style, unit of white space, or even a motion animation designed for a specific\nneed.\n\nFor example, instead of choosing one of many shades of green for an icon, we can apply a design\ntoken that is consistent with all similar usages across our apps: `color.icon.success`.\n\n![](./_assets/elevation-token-image.png)\n\n## What are themes?\n\nA theme is a collection of token values designed to achieve a certain look or style. Themes are how\nwe switch color schemes and styles everywhere using a single set of tokens.\n\nLight mode, dark mode, and high-contrast mode are all examples of theming. Non-color themes are also\npossible: think cozy/comfortable/compact views, reduced motion, or custom typography styles.\n\n![](./_assets/dark-mode-light-mode.png)\n\n## Why use design tokens?\n\n- Features like global theming (dark mode), responsive design, and user customization are possible\n  with tokens.\n- Design tokens simplify the design and development by streamlining decision making and handover\n  between crafts.\n- As Atlassian's visual language evolves, changes can be made once across the system and apps. No\n  more finding and replacing hard-coded values everywhere.\n- We have automated tooling to help designers and developers start using tokens faster.\n- Tokens are how we'll implement our newest visual foundations. This will deliver visual consistency\n  and other improvements to Atlassian UI.\n\n## How to read design token names\n\nKnowing how to read token names will help you find the right token faster when working in designs\nand in code.\n\n![](./_assets/color_token_name.png)\n\nA design token’s name describes how it should be used, and each part communicates one piece of its\nusage.\n\n1. **Foundation**: The type of visual design attribute or foundational style, such as color,\n   elevation, or space.\n2. **Property**: The UI element the token is being applied to, such as a border, background, shadow,\n   or other property.\n3. **Modifier**: Additional details about the token’s purpose, such as its color role, emphasis, or\n   interaction state. Not every token has a modifier. For example, color.text is our default body\n   text color.\n\nNote that token names might look different in different environments and tools:\n\n![](./_assets/Tokens-variable-breakdown.png)\n\n## Find and use tokens\n\nFind all of our available design tokens and their usage descriptions in\n[all tokens](https://atlassian.design/components/tokens/all-tokens).\n\nSearch and filter the token list, or use our token picker for extra help.\n\n### Best practices\n\nChoose tokens based on meaning where applicable, not specific values.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: doIconColorImage, alt: '' }}>\n\t\tUse design tokens with names and descriptions that fit your specific situation.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: dontIconColor, alt: '' }}>\n\t\tDon't use a token just because the colors appear to match. This can break the experience in\n\t\tother themes.\n\t</DoDont>\n</DoDontGrid>\n\nCheck our foundations for [color](https://atlassian.design/foundations/color),\n[elevation](https://atlassian.design/foundations/elevation), and\n[spacing](https://atlassian.design/foundations/spacing) for additional usage guidance.\n\n## Design token examples\n\nUse these examples to get a better understanding of how different tokens work.\n\n### Color tokens\n\nHere’s an example of color design tokens in use: the default text color and the background color for\na \"danger\" button on hover.\n\n![](./_assets/color-token-example.png)\n\nThere are dedicated color tokens for text, links, icons, backgrounds, borders, blankets, charts, and\nskeleton loaders.\n\nFor more on color token usage, see our\n[color foundation](https://atlassian.design/foundations/color).\n\n### Elevation tokens\n\nElevation tokens apply to the perceived surface level and shadow.\n\n![](./_assets/elevation-token-image.png)\n\nFor more on how and when to apply elevations, see our\n[elevation foundation](https://atlassian.design/foundations/elevation).\n\n### Opacity tokens\n\nOpacity tokens apply transparency to an element. Use `opacity.disabled` for interactive images that\nare disabled (such as disabled avatar), and `opacity.loading` to content sitting underneath a\nloading spinner.\n\n### Space tokens\n\nSpace tokens reduce decision making and allow for consistent spacing between elements in a page\nlayout. These tokens are designed to be use for horizontal and vertical spacing, in a variety of\ncontexts.\n\nFor more on how our spacing system, and how to use space in your designs, see our\n[spacing foundation](https://atlassian.design/foundations/spacing).\n\n![](./_assets/token-spaceheading_2.png)\n\n### Typography tokens\n\nTo visually align typography across Atlassian apps, typography tokens include font values, including\nfont family, font size, font weights, and line heights for all text styles.\n\nFor more on how to start working with typography tokens, see our\n[typography foundation](https://atlassian.design/foundations/typography).\n\n![](./_assets/token-typeheading_2.png)\n\n## What's next\n\n- Learn how to [Migrate to tokens](https://atlassian.design/tokens/migrate-to-tokens)\n- [Use tokens in designs](https://atlassian.design/tokens/use-tokens-in-design)\n- [Use tokens in code](https://atlassian.design/tokens/use-tokens-in-code)\n- For additional component examples and code samples, see\n  [components examples](https://atlassian.design/components/tokens/examples).",
+  keywords: ['design tokens', 'tokens', 'design system', 'theming', 'variables', 'customization']
+}, {
+  content: 'import {\n\tcodeMigrateToTokensJS,\n\tcodeMigrateToTokensCSS,\n\tcodeTokensCodemmod,\n\tcodeCodemodCli,\n} from \'../../../../snippets/code/migrate-to-tokens\';\n\nRead this guide to learn how to migrate an Atlassian app to tokens, and what’s changing for\ndesigners and developers.\n\n## Before you begin\n\nMake sure you understand the basics of\n[design tokens](https://atlassian.design/tokens/design-tokens).\n\n## How to migrate an app to tokens\n\nTeams will apply and test tokens across an experience before releasing new colors (dark mode) or\nother tokens publicly.\n\n### Changes for designers\n\nUse our Figma libraries to apply updated colors, design tokens, and themed components to your\ndesigns. We also have a Figma plugin to help you migrate design styles to tokens and generate\ndark-mode previews.\n\n![](./_assets/figma-plugin.png)\n\nAs migration continues, you\'ll also help test and review changes in your app with our\n[Chrome extension (Atlassians only)](https://go.atlassian.com/dst-chrome-theme-plugin).\n\nGet set up to [use tokens in designs](https://atlassian.design/tokens/use-tokens-in-design).\n\n### Changes for developers\n\nTo use and apply tokens in code:\n\n1. [Set up theming](https://atlassian.design/tokens/use-tokens-in-code#set-up-themes-and-theme-switching)\n   in your application.\n2. Update any design system components to the latest versions (these already have tokens built-in).\n3. Replace raw CSS values (e.g. colors, padding, or typography values) with the tokens (our codemod\n   speeds this up). See instructions in\n   [use tokens in code](https://atlassian.design/tokens/use-tokens-in-code).\n\nConversion in code generally looks like this:\n\n<CodeBlock language="diff" text={codeMigrateToTokensJS} shouldWrapLongLines />\n<br></br>\n\n<CodeBlock language="css" text={codeMigrateToTokensCSS} shouldWrapLongLines />\n<br></br>\n\n<SectionMessage\n\ttitle="Rolling out color tokens in Marketplace apps and integrations"\n\tappearance="information"\n\tactions={[\n\t\t<SectionMessageAction href="https://community.developer.atlassian.com/t/start-using-design-tokens-in-your-apps-and-try-dark-theme-in-jira-cloud/64147">\n\t\t\tDeveloper community updates\n\t\t</SectionMessageAction>,\n\t\t<SectionMessageAction href="https://developer.atlassian.com/cloud/jira/platform/connect-theming/">\n\t\t\tInstructions for theming connect apps\n\t\t</SectionMessageAction>,\n\t]}\n>\n\tBefore any Atlassian app launches dark mode publicly, we’ll provide support and updates in our\n\tdeveloper community so that apps can prepare.\n</SectionMessage>\n\n#### Use our codemod for migration assistance\n\nWhen you run the\n[codemod](https://developer.atlassian.com/cloud/framework/atlassian-frontend/codemods/intro-to-codemods/),\nit goes into every single color in the target files and suggests tokens based on context of the\nsurrounding code.\n\nThis is what it looks like after running the codemod.\n\n<CodeBlock language="diff" text={codeTokensCodemmod} shouldWrapLongLines />\n<br></br>\n\nUse `@atlaskit/codemod-cli` to run the codemod cli\n\n<CodeBlock language="shell" text={codeCodemodCli} shouldWrapLongLines />\n<br></br>\n\nThe CLI will show a list of components and versions. Select `@hypermod/cli: theme-to-design-tokens`\n(for CSS in JS) or `@hypermod/cli: css-to-design-tokens` (for vanilla CSS) and your code will be\nmigrated.\n\nThe codemod only provides token suggestions, so manual review is required after running the codemod.\n\n#### Test changes with the Chrome extension\n\nTo view progress and toggle between themes in an app during migration, use our\n[Chrome extension (Atlassians only)](https://go.atlassian.com/dst-chrome-theme-plugin).\n\nYou can also pin the extension to your browser\'s toolbar for easy access from the Extension popup.\n\n## What\'s next\n\n- [Use tokens in design](https://atlassian.design/tokens/use-tokens-in-design)\n- [Use tokens in code](https://atlassian.design/tokens/use-tokens-in-code)\n- Learn our new [color](https://atlassian.design/foundations/color),\n  [elevation](https://atlassian.design/foundations/elevation), and other foundation guidelines\n- Search for tokens in the [all tokens list](https://atlassian.design/components/tokens/all-tokens)\n\n## Get help\n\n- Atlassians can get help with token migrations in\n  [Slack](https://go.atlassian.com/help-design-system).\n- Other developers who need help with tokens can post in the public\n  [developer community](https://community.developer.atlassian.com/).\n- For general help with the Atlassian Design system,\n  [contact us](https://atlassian.design/contact-us).',
+  keywords: ['migrate tokens', 'token migration', 'refactoring', 'design system adoption']
+}, {
+  content: 'import {\n\tcodeSetUpThemes,\n\tcodeHtmlTheme,\n\tcodeUseTokens,\n\tcodeBabelPlugin,\n\tcodeBabelPluginUsage,\n\tcodeBabelPluginCompiled,\n\tcodeFallbackRemovalCodemod,\n\tcodeLintRules,\n} from \'../../../../snippets/code/use-tokens-in-code\';\n\nThis page explains how to set up and use\n[design tokens and themes](https://atlassian.design/tokens/design-tokens) in code.\n\n## Before you begin\n\nMake sure you’re\n[set up to use the Atlassian Design System](https://atlassian.design/get-started/develop). In\nparticular, make sure `@atlaskit/tokens` is installed as a dependency and use our\n[linting rules](https://atlassian.design/components/eslint-plugin-design-system/usage) to stay up to\ndate.\n\n## Set up themes and theme switching\n\nFor themes to work properly for users, theming must be set up in two places: the Atlassian\napplication and in any Marketplace apps extending that app experience.\n\nUse the [setGlobalTheme](https://atlassian.design/components/tokens/code#setglobalthemethemestate)\nmethod to switch themes globally at runtime in an Atlassian app or stand-alone application.\n\n<CodeBlock language="jsx" text={codeSetUpThemes} shouldWrapLongLines />\n<br></br>\n\nMake sure theming is set up by inspecting your app HTML. You should see something like this:\n\n<CodeBlock language="html" text={codeHtmlTheme} shouldWrapLongLines />\n<br></br>\n\nPay special attention to the `data-color-mode="dark"` attribute, and also note the\n`data-theme="dark:dark light:light ..."` attribute. These reflect the current theme state. They also\nmatch CSS selectors within the theme files so the appropriate CSS variables can be activated in\nresponse to theme changes.\n\n### Set up Atlassian fonts\n\nTo bring [Atlassian Sans and Atlassian Mono](https://atlassian.design/foundations/typography) web\nfonts into your app, follow our\n[setup guide (Atlassians only)](https://go.atlassian.com/set-up-fonts).\n\nThe typography theme is enabled by default when using `setGlobalTheme()`.\n\n### Set up themes for apps (Connect, Forge, Marketplace)\n\nFor Connect and Forge apps, see the following dedicated resources:\n\n- [Theming Connect apps](https://developer.atlassian.com/cloud/jira/platform/connect-theming/)\n- [Theming Forge apps](https://developer.atlassian.com/platform/forge/design-tokens-and-theming/)\n\n### Server-side rendering\n\nIf your application is using SSR (server-side rendering) ensure themes appear at the right time\nusing our\n[SSR theming utilities](https://atlassian.design/components/tokens/code#server-side-rendering-ssr-utilities).\n\n## Use tokens\n\nYou can access individual tokens using the CSS custom properties mounted to the page, however, it\'s\nbest to use the `token()` method. This ensures you have proper prefixes, type checking, and linting\nso you\'ll know if a token ever changes, is deleted, or is used incorrectly.\n\nThe `token()` function takes a dot-separated token name and returns a valid CSS custom property for\nthe corresponding token. This method will warn you if an unknown token is provided.\n\n<CodeBlock language="jsx" text={codeUseTokens} shouldWrapLongLines />\n<br></br>\n\nIf you\'re migrating a lot of values to tokens,\n[use our codemod](https://atlassian.design/tokens/migrate-to-tokens#use-our-codemod-for-migration-assistance).\n\n### Migration to tokens\n\nThe `token()` function accepts two arguments: the first is the token, and the second is an optional\nfallback value (the value that is rendered when the theme is not set up). During the theme rollout\n(i.e., migration from raw values to tokens), it is recommended to use the function without\nspecifying fallback value. In such cases, this value will be automatically supplied by the\nbuild-time Babel plugin, ensuring that properties have valid values even if the theme is not yet\nenabled.\n\nAt times, token values may not perfectly align with the raw values used in the codebase. To maintain\nconsistent user experience, it is recommended to use the values provided by tokens whenever\npossible. However, if no appropriate token exists for a specific value that must be retained, it is\npreferable to leave the value unchanged (without converting it to a token) rather than adding it as\na fallback.\n\nFallback values were mostly used historically for large app migrations and are not recommended\nanymore.\n\nDesign tokens are the new way to apply visual foundations in Atlassian app experiences. We’re\nrolling out tokens to standardize colors, elevations, spacing, and other styles in Atlassian apps.\n\n#### Babel plugin\n\nOur build-time Babel plugin is required to optimize the runtime performance of tokens by replacing\nany calls to the `token()` function in `@atlaskit/tokens` with the corresponding CSS value the\nfunction would return.\n\nIf no fallback is provided, the plugin automatically retrieves the token value from the default\nAtlassian light theme and sets it as the fallback. This behavior can be disabled by setting the\nplugin second option `shouldUseAutoFallback` to `false`.\n\n<CodeBlock language="diff" text={codeBabelPlugin} shouldWrapLongLines />\n<br></br>\n\nBy default, the plugin is configured to ignore explicit fallback values optionally provided in the\nsecond argument of the token() function. This behavior can be overridden by explicitly setting the\nplugin configuration option `shouldForceAutoFallback` to `false`.\n\n**Usage**\n\nAdd the plugin to your babel configuration:\n\n<CodeBlock language="json" text={codeBabelPluginUsage} shouldWrapLongLines />\n<br></br>\n\nIf your codebase uses [Compiled](https://compiledcssinjs.com/docs/installation#babel), then add the\nplugin to its configuration as well:\n\n<CodeBlock language="json" text={codeBabelPluginCompiled} shouldWrapLongLines />\n<br></br>\n\n### Removing existing token fallbacks\n\nIf fallback values were used during the migration to tokens, it is essential to remove them from the\ncodebase once migration is complete and themes are enabled. This helps to improve performance by\nreducing the critical CSS size and simplifies development efforts.\n\n#### Prerequisites\n\nEnsure the following before proceeding:\n\n- **Babel plugin enabled**: The `@atlaskit/tokens/babel-plugin` should be active with\n  `shouldUseAutoFallback` set to `true`. This ensures fallback values are automatically handled\n  during build time.\n- **Themes enabled**: Verify that ADS themes are applied in your app. Fallbacks can only be safely\n  removed for token categories with active themes (e.g color, space, or typography tokens).\n\n#### Steps for fallback removal\n\n1. **Implicit Fallback Removal**:\n   - Update your Babel plugin configuration to include `shouldForceAutoFallback: true`. This setting\n     forces the plugin to ignore any explicit fallbacks in the code, using default theme values\n     instead.\n   - Define `forceAutoFallbackExemptions` for token categories that do not currently have an active\n     theme. This ensures the preservation of existing token fallbacks rendered in the app,\n     preventing unintended UI changes.\n\n2. **Explicit fallback removal**:\n   - Install the codemod: https://www.npmjs.com/package/@atlaskit/codemod-cli\n   - Run the codemod to remove fallback values from your codebase:\n     <CodeBlock language="shell" text={codeFallbackRemovalCodemod} shouldWrapLongLines />\n   - Use `--skipTokens` to align with `forceAutoFallbackExemptions` for any themes that are not yet\n     enabled (note that currently radius tokens are automatically exempted).\n   - Use `--forceUpdate` to remove fallbacks regardless of their values. Without the option it would\n     preserve fallbacks that differ from the token value. Omitting this option is only valuable when\n     you don’t have `shouldForceAutoFallback` enabled or are unsure if themes are enabled in the app\n     and therefore would like to remove fallbacks gradually starting with the ones that won’t have\n     UI impact if removed.\n   - Use `--addEslintComments` to automatically add eslint suppressions for the fallbacks that\n     shouldn’t be removed, such as the ones configured in `forceAutoFallbackExemptions`.\n\n3. Use ESLint to ensure fallbacks are not used in the future. This can be done by enabling the\n   `@atlaskit/design-system/no-unsafe-design-token-usage`\n   [ESLint rule](https://www.npmjs.com/package/@atlaskit/eslint-plugin-design-system) with\n   `fallbackUsage: \'none\'` to prevent new fallbacks from being added.\n\n## Stay up to date\n\nAs our color system is applied to new apps, changes to our tokens will be released regularly. To\nstay up to date, install our linting support tools:\n\n- For CSS in JS applications, use\n  [ESLint](https://atlassian.design/components/eslint-plugin-design-system/usage).\n- For CSS (vanilla), Less, Sass, use\n  [Stylelint](https://atlassian.design/components/stylelint-design-system/usage).\n\nThese will warn you if you’re using deprecated tokens, and will assist in updating your app to the\nlatest tokens.\n\n<CodeBlock language="js" text={codeLintRules} shouldWrapLongLines />\n\n## What\'s next\n\n- Search the list of [all design tokens](https://atlassian.design/components/tokens/all-tokens) for\n  full descriptions and token values.\n- See design token [code examples](https://atlassian.design/components/tokens/examples).\n- Browse our [token API reference and changelog](https://atlassian.design/components/tokens/code).\n- Use the [image component](https://atlassian.design/component/image) to theme images.\n\n## Get help\n\n- Atlassians can get help with tokens in [Slack](https://go.atlassian.com/help-design-system).\n- Partners and other developers who need help with tokens can post in the\n  [developer community](https://community.developer.atlassian.com/).\n- For general help with the Atlassian Design system,\n  [contact us](https://atlassian.design/contact-us).',
+  keywords: ['use tokens', 'token implementation', 'coding', 'development', 'engineering']
+}, {
+  content: "Understand how to use design tokens when applying our foundations in your designs.\n\n## Before you begin\n\nMake sure you understand the basics of\n[design tokens](https://atlassian.design/tokens/design-tokens).\n\n## Using tokens in Figma\n\n1. Get access to our Figma libraries with design tokens built-in as styles and in components.\n   [Access Figma libraries](https://atlassian.design/get-started/figma-libraries).\n\n2. Install and use the\n   [Atlassian Design Tokens Figma plugin](https://www.figma.com/community/plugin/1144189860740169808/Atlassian-Design-Tokens)\n   to simplify finding and applying Atlassian design tokens in your designs.\n   ![](./_assets/figma-plugin.png)\n\n3. (Atlassian employees only) Use the Figma plugin convert old design files to use design tokens,\n   and to convert your designs to dark mode.\n\n## Review tokens and styles in your app\n\nView new colors and styles in your app during migration using the\n[Chrome plugin (Atlassians only)](https://go.atlassian.com/dst-chrome-theme-plugin).\n\nNew colors and other values won’t be visible until each app officially releases their changes when\nafter testing is complete. The chrome plugin allows you to view the latest tokens behind the scenes\nduring testing.\n\n## What's next\n\n- Search all of our available design tokens and their descriptions in\n  [all tokens](https://atlassian.design/components/tokens/all-tokens).\n- For extra help choosing the right token, use our\n  [Token picker](https://atlassian.design/components/tokens/all-tokens?isTokenPickerOpen=true).\n- Review new usage guidance in our color, elevation, and spacing\n  [foundations](https://atlassian.design/foundations).\n- Check out our\n  [design tokens onboarding video resources (for Atlassians only)](https://go.atlassian.com/design-token-onboarding).\n\n## Get help\n\n- Atlassians can get help with tokens in [Slack](https://go.atlassian.com/help-design-system).\n- For general help with the Atlassian Design system,\n  [contact us](https://atlassian.design/contact-us).",
+  keywords: ['design tokens in design', 'figma', 'design tools', 'design workflow']
+}, {
+  content: "import {\n\tTypographyPrinciples,\n\tTypographyHeadingTable,\n\tTypographyBodyTable,\n\tTypographyMetricTable,\n\tTypographyCodeTable,\n} from '@af/design-system-docs-ui';\n\n## Overview\n\nWe have moved our app suite to a refreshed typography system. Using our\n[app (product) typefaces](https://atlassian.design/foundations/typography/product-typefaces-and-scale),\nAtlassian Sans and Atlassian Mono, will create a consistent experience across all browsers. As apps\nmove to this system, we provide support to help transition smoothly between systems.\n\n## Typographic principles\n\nFollow these principles to create legible and visually balanced typography. Use in conjunction with\nthe Atlassian [color tokens](https://atlassian.design/foundations/color) and\n[space tokens](https://atlassian.design/foundations/spacing) in app experiences.\n\n<TypographyPrinciples />\n\n## Brand fonts\n\nWhen you need to express the Atlassian brand, such as in marketing, we use our custom brand font,\nCharlie Sans. Only authenticated users can download our\n[brand fonts](https://brandfolder.com/atlassian-brand-creative-library/atlassian-public-asset-library).\n\n![](./_assets/brand-banner.png)\n\n## App fonts\n\nFor all in-app experiences, we use our Atlassian fonts,\n[Atlassian Sans](https://atlassian.design/foundations/typography/product-typefaces-and-scale#atlassian-sans)\nand\n[Atlassian Mono](https://atlassian.design/foundations/typography/product-typefaces-and-scale#atlassian-mono).\nThis ensures the UI is optimized, performs well and is frictionless as you move between Atlassian\napps and experiences regardless of platform. For apps not yet using our refreshed system, we use\nsystem fonts via our modernized or legacy systems.\n\nAll app fonts are available for download in [Atlassian Mosaic](https://orangedam.atlassian.com/) in\nTTF format.\n\n![](./_assets/app-fonts.png)\n\n## Text styles and tokens\n\nText styles and typography tokens are made up of specific font values, including font family, font\nsize, and line height. Where text styles appear in design and Figma, typography tokens are used in\ncode.\n\nUse heading, body and code text styles and tokens in your designs. Each style has optimized spacing\nvalues based on font size, and is designed to work with our other foundations such as spacing and\ncolor. These typographic decisions are built into typography tokens and will enable typography\ntheming in the future.\n\nWe also recommend using heading and text components in code to simplify implementation of typography\ntokens.\n\nLearn more about\n[applying typography tokens and text styles](https://atlassian.design/foundations/typography/applying-typography/).\n\n![](./_assets/text-styles.png)\n\n### Rem units in tokens\n\nTypography tokens use\n[rem units](https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Values_and_units)\ninstead of pixel values for font-size and line-heights. Font size is calculated dynamically by\nmultiplying the rem unit with the browser default size of 16px (i.e. 1rem is equal to 16px).\n\nUnlike pixels which are absolute (or fixed), rem are relative units that adjust according to the\nroot element (html) size. Using rem units allow users to adjust the size of text depending on their\nneeds or browser size, improving the responsiveness and accessibility of designs.\n\n### Heading\n\nUse headings for page titles or subheadings to introduce content. Headings are sized to contrast\nwith content, increase visual hierarchy, and help readers easily understand the structure of\ncontent.\n\nHeadings should be used to introduce a new section of content. Use heading styles, rather than bold\nor a change of font size, as they’re important for accessibility.\n\nHeading levels help users navigate a page, especially users of screen readers and other assistive\ntechnology. Using the right heading levels also helps to group content so it’s easier to scan.\n\nHeading levels (`<h1>` to `<h6>`) should be used in a descending sequence. Only use one h1 per page\n(usually the page title) and don’t skip a level (for example, use an h2 then an h4).\n\n![](./_assets/heading1.png)\n\nHeadings come in a range of sizes, for use in different contexts:\n\n- **XXL** and **XL** are suitable for brand and marketing content.\n- **XL** and **L** are suitable for page titles in apps such as a form title.\n- **M** can be used in large components where space is not limited and perfectly balances with Body\n  M, such as modals.\n- **S** and **XS** are for titles in small components where space is limited, such as flags.\n- **XXS** should be used sparingly and is suitable when matched with Body S, for example, in fine\n  print.\n\n![](./_assets/heading2.png) ![](./_assets/heading3.png)\n\n<TypographyHeadingTable />\n\n### Body\n\nUse body text for main content. They typically appear after headings or subheadings as detailed\ndescriptions and messages, but also as standalone text in components. Body text includes additional\nparagraph spacing for readability and flow in blocks of text.\n\nBody text comes in three sizes, for use in different contexts:\n\n- **Body L** is the default size for long-form content. Use this size for a comfortable reading\n  experience such as in blogs.\n- **Body M (Default)** is the default size in components or where space is limited, for detailed or\n  descriptive content such as primary descriptions in flags.\n- **Body S** should be used sparingly and is for secondary level content such as fine print or\n  semantic messaging.\n\n![](./_assets/body-l.png) ![](./_assets/body-m.png) ![](./_assets/body-s.png)\n\n<TypographyBodyTable />\n\n\\* See paragraph spacing below.\n\n#### Paragraph spacing\n\nParagraph spacing is set in Figma text style libraries only. To represent paragraphs in code, use\nseparate text components for each paragraph and manage paragraph spacing with the\n[stack component](https://atlassian.design/components/primitives/stack/examples).\n\n#### Body font weight\n\nFont weight is applied through the choice of text style in Figma, or through font weight tokens in\ncode. Three weights are available for body text:\n\n- **Regular** weight is for generic paragraphs to contrast with headings, and medium text in\n  components.\n- **Medium** weight is for alignment with iconography. Use this weight in most components and\n  whenever text could be seen beside line icons.\n- **Bold** weight is for unique cases where text needs to be differentiated or given more emphasis.\n  Use this weight sparingly.\n\n![](./_assets/weight-regular.png) ![](./_assets/weight-medium.png) ![](./_assets/weight-bold.png)\n\n### Metric\n\nUse metric when you want to emphasize certain numbers. Understand when to use this style, with our\ndo and don’t examples.\n\n[Metric style do and don't examples](https://atlassian.design/foundations/typography/applying-typography#metric)\n\n![](./_assets/metric1.png) ![](./_assets/metric2.png)\n\n<TypographyMetricTable />\n\n### Code\n\nThe code text style is reserved for representing code in our\n[code block component](https://atlassian.design/components/code/code-block/).\n\n<TypographyCodeTable />\n\nCode can also appear [inline](https://atlassian.design/components/code/examples) following the style\nsettings of the block of text it sits within. In this context, this token is relative to its\ncontainer's font size. Assuming a container font size of 14 px (0.875 rem), this token will have a\nfont size of 12.25 px. The line height is equal to the font size.",
+  keywords: ['typography', 'typeface', 'fonts', 'text', 'readability', 'design tokens']
+}, {
+  content: "## Typography tokens and text styles\n\nUse text styles when designing in Figma, and typography tokens and components in code. Use the\n[heading component](https://atlassian.design/components/heading/examples) for heading text, and the\n[text component](https://atlassian.design/components/primitives/text/examples) for body text. To\nlearn how to apply our typography styles in Figma, go to our Figma Typography Playground for step by\nstep instructions and helpful tips.\n\nThe following table outlines our Figma text styles, their corresponding typography tokens, and\nsuggestions for when and where to apply them.\n\n<TypographyTextStyleTable />\n\n## Usage guidelines\n\nFollow these guidelines when using tokens and text styles, to create a seamless and consistent user\nexperience across platform experiences.\n\nUse [space tokens](https://atlassian.design/foundations/spacing) and\n[color tokens](https://atlassian.design/foundations/color) in conjunction with typography to align\nto the design foundations.\n\n### Accessibility\n\nTypography tokens and components have been designed with accessibility considerations in mind. Some\npeople need to read text on different screen sizes or at different magnification levels. Coding your\ntypographic experiences correctly helps assistive technology interpret the structure of your\ncontent.\n\nTo ensure app experiences are accessible for all of our users, ensure that you do the following:\n\n- Use responsive text, typography tokens, use relative values (rem) to determine font size on\n  different browser default sizes.\n- Use text styles (in Figma) and typography tokens and components (in code) to ensure a legible font\n  family, font size, and visual hierarchy between text styles.\n- Use the correct heading levels for an accessible experience. Use heading styles (in Figma) and\n  typography tokens and components (in code) to establish the correct hierarchy of heading levels.\n  Use headings to group related content and help users navigate and scan a page.\n- Use [text color tokens](https://atlassian.design/components/tokens/all-tokens#color-text) to\n  achieve minimum color contrast for legibility.\n- Apply correct HTML tag hierarchy to ensure assistive technologies interpret your experiences\n  correctly.\n- Follow established experience patterns for interactions using text.\n\nThe general guidance for comfortable reading is to use a minimum font size of 16px for long-form\ntext such as blogs. The smallest font size available in the Atlassian Design System typography\ntokens is 12px. Avoid using this, except for in fine print.\n\nVisit our [accessibility documentation](https://atlassian.design/foundations/accessibility/) to\nunderstand more about accessible design.\n\n### Heading\n\nUse headings for page titles and subheadings to introduce content. They help readers scan and\nunderstand the structure of content.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: clearHeadingsDo, alt: '' }}>\n\t\tWrite succinct and clear headings to summarise content on a page or section.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: clearHeadingsDont, alt: '' }}>\n\t\tDon’t write overly long titles. Use shorter titles that can be viewed easily on all screen\n\t\tsizes.\n\t</DoDont>\n\t<DoDont type=\"do\" image={{ url: largeHeadingsDo, alt: '' }}>\n\t\tUse large headings to draw attention to content.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: largeHeadingsDont, alt: '' }}>\n\t\tDon’t use heading sizes smaller than the body font size. Use headings equal or less than twice\n\t\tthe body font size.\n\t</DoDont>\n\t<DoDont type=\"do\" image={{ url: differentiateHeadingsDo, alt: '' }}>\n\t\tClearly differentiate heading sizes to create hierarchy.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: differentiateHeadingsDont, alt: '' }}>\n\t\tDon’t use similar heading sizes for different heading levels. Use between 2-4 heading size\n\t\tdifference between levels.\n\t</DoDont>\n</DoDontGrid>\n\n### Body\n\nUse body text for the main content. You can use body text after headings or subheadings, for example\nas detailed descriptions and messages, but it may also be used as standalone text in components.\n\nIn Figma, paragraph spacing is set for body text styles only. To represent paragraphs in code, use\nseparate [text components](https://atlassian.design/components/primitives/text/examples) for each\nparagraph and manage paragraph spacing with the\n[stack component](https://atlassian.design/components/primitives/stack/).\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: useBodyTextDo, alt: '' }}>\n\t\tUse body text for paragraphs of text such as descriptions or blogs.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: useBodyTextDont, alt: '' }}>\n\t\tDon’t use body text for headings. That’s what headings are for!\n\t</DoDont>\n\t<DoDont type=\"do\" image={{ url: componentsDo, alt: '' }}>\n\t\tUse body text in components such as buttons, inputs, lozenges and menus.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: componentsDont, alt: '' }}>\n\t\tDon’t use heading text in components, instead use body text with a heavier font weight to create\n\t\tgreater contrast.\n\t</DoDont>\n\t<DoDont type=\"do\" image={{ url: textStylesDo, alt: '' }}>\n\t\tUse the text styles and typography tokens. Body text has optimized line height for reading\n\t\tcomfortably.\n\t</DoDont>\n</DoDontGrid>\n\n### Metric\n\nUse metric style when you want to emphasize certain numbers. Numbers you can apply this style to\ninclude:\n\n- **metrics and standalone numbers** (for example, 45%, 100)\n- **numbers with units** (for example, 12 km, 8 hours, 4 days)\n- **currency, totals, and pricing** (for example, $70, Total $550.00)\n\nNumbers can be accompanied with symbols such as %, $, #, or \\*. For numbers that you don’t want to\nemphasize, use body styles that are smaller than the highlighted metric. For example, use body style\nsmall for other small chart content like chart keys, legends, and axes.\n\n#### Apply metric style to numbers and text\n\nMetric can also be applied to numbers and text. This works best for short words. For example:\n\n- ‘10% capacity’\n- ‘55% complete’\n- ‘3 in review’\n\n#### Apply metric style in sizes S, M, or L\n\nThere are 3 sizes for metric. Use the sizes in these scenarios:\n\n- Use S for numbers in the middle of small donut charts and single-value tiles.\n- Use M for numbers in the middle of medium donut charts.\n- Use L for numbers in the middle of large donut charts.\n\nTo apply metric correctly, check these examples of what to do and what to avoid.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: emphasiseMetricDo, alt: '' }}>\n\t\tUse metric to emphasize a number in a donut chart. For example ‘10%’. Use body style small\n\t\tregular for the subtext. For example ’capacity’.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: emphasiseMetricDont, alt: '' }}>\n\t\tDon’t apply metric to the subtext under a number in a donut chart. For example, don’t apply it\n\t\tto ‘capacity’.\n\t</DoDont>\n\t<DoDont type=\"do\" image={{ url: smallTextDo, alt: '' }}>\n\t\tUse body style small for other small chart content like chart keys, legends, and axes. For\n\t\texample, On track 12, Off track 6, At risk 4.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: smallTextDont, alt: '' }}>\n\t\tDon’t use metric for the numbers on the chart key. For example, On track 12, Off track 6, At\n\t\trisk 4.\n\t</DoDont>\n\t<DoDont type=\"do\" image={{ url: shortStatementDo, alt: '' }}>\n\t\tUse metric to emphasize a short statement with words and numbers. For example ‘2 complete’, ‘3\n\t\tin review’ in single-value tiles.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: shortStatementDont, alt: '' }}>\n\t\tDon’t use metric for longer statements. For example ‘Teams with work item cycle time under or\n\t\tover 7 days’.\n\t</DoDont>\n\t<DoDont type=\"do\" image={{ url: chartTitleDo, alt: '' }}>\n\t\tUse heading styles for chart titles.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: chartTitleDont, alt: '' }}>\n\t\tDon’t use metric for chart titles.\n\t</DoDont>\n\t<DoDont type=\"do\" image={{ url: totalDo, alt: '' }}>\n\t\tUse metric for a total in a chart. For example $100.00.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: totalDont, alt: '' }}>\n\t\tDon’t use metric for a total in a billing screen. For example USD 500.00. Use 16px body style\n\t\tinstead.\n\t</DoDont>\n</DoDontGrid>\n\n### Code\n\nUse code text to represent code only, either inline or in code blocks.\n\n![](./_assets/code-text.png)\n\n### Font weights\n\nThere are four font weights available in our system: regular, medium, semibold and bold. We selected\nthese based on our fallback fonts to minimise the visual differences across operating systems.\n\n![](./_assets/font-weights.png)\n\nWe recommend using the following default weights for our text styles:\n\n- Body in **regular** weight for paragraphs.\n- Body in **medium** weight for use in components and alongside icons.\n- Body in **bold** weight should be used in unique cases where text needs to be differentiated or\n  given more emphasis. Use this weight sparingly.\n\nSemibold weight is also available but use this weight with caution. Our fallback fonts don’t support\nthis weight and will default to bold.\n\n![](./_assets/body-weights.png)\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: fontWeightDo, alt: '' }}>\n\t\tUse bold weight in headings to contrast with regular weight body content.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: fontWeightDont, alt: '' }}>\n\t\tDon’t use regular or bold weights when text is beside an icon. Icon stroke width is designed to\n\t\talign with medium weight text.\n\t</DoDont>\n</DoDontGrid>\n\n### Links\n\nUse [`color.link`](https://atlassian.design/components/tokens/all-tokens#color-link) tokens for\ninline links, and see [Link](https://atlassian.design/components/link) and\n[Link button](https://atlassian.design/components/button/link-button) for more guidance.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: linksDo, alt: '' }}>\n\t\tUse design tokens to follow inline link styling and provide visual clues to identify links in\n\t\tstatic text.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: linksDont, alt: '' }}>\n\t\tDon’t show inline links in the same colour as surrounding text or ignore styling patterns for\n\t\tinteractive text.\n\t</DoDont>\n</DoDontGrid>\n\n## Best practices\n\n### All caps\n\nAtlassian writing guidance specifies avoiding the use of all caps. For readability, accessibility\nand localisation reasons, avoid the use of all caps unless text is an acronym. However, the lozenge\ncomponent will continue to use all caps for the foreseeable future.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: allCapsDo, alt: '' }}>\n\t\tUse all caps for acronyms, such as issue IDs.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: allCapsDont, alt: '' }}>\n\t\tDon’t use all caps for full words.\n\t</DoDont>\n</DoDontGrid>\n\n### Truncation\n\nNever truncate text. If you do use truncated text, for example if you are displaying user generated\ncontent of an unknown length, make sure that there's another option for people to expand and read\nthe text.\n\n<DoDontGrid>\n\t<DoDont type=\"do\" image={{ url: truncationDo, alt: '' }}>\n\t\tDisplay content using the maximum character count allowed within components, especially if it is\n\t\timportant information.\n\t</DoDont>\n\t<DoDont type=\"dont\" image={{ url: truncationDont, alt: '' }}>\n\t\tDon’t truncate content, if you must truncate make sure there is an option for people to expand\n\t\tand read the full text.\n\t</DoDont>\n</DoDontGrid>\n\n### Line length\n\nWide lines of body text are difficult to read. Readers may choose a wide layout but it’s good\npractice to design for the ideal line length.\n\nFor the English language, optimal line length is between 60 and 80 characters per line including\nspacing, or approximately 10-12 words.\n\nThis can vary based on font, font size and how it will be displayed. For example, line lengths need\nto be shorter when reading text on smaller devices.\n\n![](./_assets/line-length.png)\n\n### Visual hierarchy\n\nCreating hierarchy means using different font weights and sizes to let people easily see what\ncontent is the most important.\n\nOur typography system allows visual hierarchy to be achieved in multiple ways. Using some or all of\nthe below suggestions are ways to create extra levels of meaning and hierarchy to your work.\n\nUse text styles and font weights to draw attention to titles and important content.\n\n![](./_assets/visual-hierarchy-1.png)\n\nUse text size and color to differentiate between primary and secondary level content.\n\n![](./_assets/visual-hierarchy-2.png)\n\n### Writing\n\nRead more about writing style and content guidelines in our\n[content documentation](https://atlassian.design/content).\n\n## Service and educational typography\n\nThe Atlassian Design System’s focus is app UI, however our service sites use a mixture of both\nmarketing and app typography. The appropriate typography can be assessed on a case-by-case basis\ndepending on the following considerations:\n\n- Atlassian messaging vs. user-generated or modified content\n- editorial content vs. technical content\n- brand marketing visual styles vs. app UI visual styles\n- consistency across sites vs. one-off solutions\n\nPlease work directly with the Creative & Design teams when assessing typography for these types of\nproperties.\n\nVisit [Atlassian Brand documentation](https://brandfolder.com/atlassian-brand-creative-library) for\nmore assets and guidance (authenticated users only).\n\n## Data Center apps\n\nFor all new features, we recommend using Atlassian Design System and other\n[Atlaskit components](https://atlaskit.atlassian.com/packages). For existing code, you can continue\nto use [Atlassian User Interface (AUI)](https://aui.atlassian.com/aui/latest/docs/typography.html).",
+  keywords: ['applying typography', 'text styles', 'typography usage', 'font sizes', 'line heights']
+}, {
+  content: '## Our typefaces\n\nWe use two typefaces, Atlassian Sans for headings and body copy and Atlassian Mono for all instances\nof code within our apps.\n\n### Atlassian Sans\n\nAtlassian Sans is our derivative of the [Inter Variable typeface](https://rsms.me/inter/) which\nstreamlines the font to optimize for certain type features to create an app (product) typeface that\ncompliments our brand font. We use this typeface for all UI in our apps other than instances where\nwe are representing code.\n\n![](./_assets/atlassian-sans.png)\n\n#### OpenType features\n\nWe use a select set of type features to enhance legibility and readability of our UI. Most are used\nconsistently but some are more case specific such as the slashed zero.\n\n<FontFeaturesTableSans />\n\n### Atlassian Mono\n\nAtlassian Mono is our derivative of the\n[JetBrains Mono typeface](https://www.jetbrains.com/lp/mono/) which seamlessly integrates with\nAtlassian Sans. We use this typeface for all instances of code in our apps.\n\n![](./_assets/atlassian-mono.png)\n\n#### OpenType features\n\nWe are using specific type settings that enhance the usability and clarity of this font when applied\nin real-world scenarios.\n\n<FontFeaturesTableMono />\n\n## Scale\n\n### Typescale\n\nWe use a minor third type scale for our typography system. Sizes scale up or down by a factor of 1.2\nrounded to the nearest multiple of 4 and are formed around a base rem unit of 16px.\n\n![](./_assets/typescale1.png)\n\n![](./_assets/typescale2.png)\n\n### Line height\n\nTo determine line heights in headings, we multiply the font sizes by ~1.2 times and for body ~1.5\ntimes. These are also rounded to the nearest multiple of 4 to align with other foundations like\nspacing and iconography.\n\n![](./_assets/line-height1.png)\n\n![](./_assets/line-height2.png)',
+  keywords: ['typefaces', 'font scale', 'type system', 'font family', 'font sizing']
 }];