import components from old website

apps/site/src/content/design-system/components/a11y/index.yaml

@@ -0,0 +1,6 @@
+name: A11y
+description: >-
+  This is a developer-only accessibility package that is used to ensure an
+  optimal experience for users of assistive technologies.
+design: []
+accessibility: []

apps/site/src/content/design-system/components/alert/index.yaml

@@ -13,6 +13,3 @@ accessibility:
   - title: Accessibility features
   - title: Keyboard support
   - title: Accessibility API
-relatedInformation:
-  - components/button-group
-  - components/colors

apps/site/src/content/design-system/components/badge/accessibility/Accessibility API/content.mdoc

@@ -0,0 +1 @@
+No specific accessibility attributes required.

apps/site/src/content/design-system/components/badge/accessibility/Accessibility features/content.mdoc

@@ -0,0 +1 @@
+The Badge shape and text content is visible in Windows High Contrast Mode (WHCM). The ‘look’ styling (colour) is not visible in WHCM.

apps/site/src/content/design-system/components/badge/accessibility/Keyboard support/content.mdoc

@@ -0,0 +1 @@
+No keyboard interaction needed.

apps/site/src/content/design-system/components/badge/accessibility/Notes on accessibility/content.mdoc

@@ -0,0 +1,17 @@
+All components comply with WCAG 2.1 AA guidelines and Success Criteria. These fall under the [four principles of accessibility](/design-system/accessibility/design-system-accessibility) – Perceivable, Operable, Understandable and Robust. Below are some specific ways in which this component follows these principles:
+
+### Perceivable
+
+The Design System components have been designed to adhere to colour contrast ratios for both text and non-text elements. They have been coded to include text alternatives when required, and allow component text and labels to be resized. They do not use colour alone to convey information.
+
+### Operable
+
+The Design System components have been coded to be navigable using a keyboard and other assistive technologies. WCAG compliance recommends being aware of the time it takes for people to complete tasks and to not automatically move focus. Animation should be controlled and simple so as not to cause seizures, and it’s important to provide the ability to perform the same task in multiple ways where possible. These rules have been followed where navigation and interaction is included in Design System components or patterns.
+
+### Understandable
+
+WCAG compliance requires consistent and predicable interactions, clear and simple language, concise labels, no jargon or abbreviations and clear error messaging. These rules have been followed where content and interactions are included in Design System components or patterns.
+
+### Robust
+
+All Design System components have been coded so they can be clearly announced, understood and navigated using all modern assistive technologies.

apps/site/src/content/design-system/components/badge/design/Badge styles/content.mdoc

@@ -0,0 +1,13 @@
+Badges come in 2 different styles, _Default_ and _Pill._ Each style has 8 colour options, the Reserved colours as well as 4 brand colours. In general, badges can be used to highlight that something requires attention.
+
+### Badges - Default
+
+Loading...
+
+### Badges - Pill
+
+Loading...
+
+### Usage examples
+
+Loading...

apps/site/src/content/design-system/components/badge/design/Dos and don’ts/content.mdoc

@@ -0,0 +1,2 @@
+*   Avoid using long text labels.
+*   Avoid using badges alone as buttons or links.

apps/site/src/content/design-system/components/badge/design/User experience/content.mdoc

@@ -0,0 +1,7 @@
+**Default style** badges are designed to highlight a word. The commonly seen usage is when indicating a function or feature in an application that is new or when onboarding.
+
+**Pill style** badges are designed to highlight a number. The most common usage is to indicate the number of unread emails or messages that need to be addressed.
+
+Badges are most effective at drawing attention when they appear and disappear as needed, or when the number they are highlighting changes. For example, in the ‘Unread emails’ scenario, when all the emails have been read the badge should no longer be visible. Or when being used to indicate a new feature, the label should hide once the feature is no longer new. This behaviour helps make them more prominent to a user when they do appear.
+
+Used incorrectly or too often runs the risk that future uses of badges will be ignored.

apps/site/src/content/design-system/components/badge/design/Visual design/content.mdoc

@@ -0,0 +1 @@
+Badges inherit styles from the button and alert components which provides a wide range of colour options. They can be used alone, with text links or inside buttons. Unlike most components, badges are designed to be more prominent and attract attention.

apps/site/src/content/design-system/components/badge/index.yaml

@@ -0,0 +1,14 @@
+name: Breadcrumb
+description: >-
+  Breadcrumbs are styled navigational links used to indicate the user’s location
+  within your site. They are a simple, effective and proven method to aid
+  orientation.
+design:
+  - title: Breadcrumbs
+  - title: User experience
+  - title: Visual design
+accessibility:
+  - title: Notes on accessibility
+  - title: Accessibility features
+  - title: Keyboard support
+  - title: Accessibility API

apps/site/src/content/design-system/components/breadcrumb/accessibility/Accessibility API/content.mdoc

@@ -0,0 +1,4 @@
+- `<nav aria-label="Breadcrumb">`: Provides a label that describes the type of navigation
+- `<ol role="list">`: Links are within an ordered list to provide additional semantic meaning—crumbs are quantifiable and part of a hierarchy, each descendants of a higher-priority crumb. The list has a “list” *role* because removing standard bullet styling affects how VoiceOver announces lists (see [VoiceOver and list-style-type: noneCopyright © 2023 by Westpac Banking Corporation. All rights reserved.](https://unfetteredthoughts.net/2017/09/26/voiceover-and-list-style-type-none/)).
+- `<a aria-current="page">`: Applied to the last link in the set to indicate that it represents the current page
+- `<span aria-hidden="true">`: Hides the visual separator icon SVGs from assistive technologies; they are visual embellishment

apps/site/src/content/design-system/components/breadcrumb/accessibility/Accessibility features/content.mdoc

@@ -0,0 +1,7 @@
+- The set of links is structured using an ordered list
+- A `<nav>` element labeled “Breadcrumb” identifies the structure as a breadcrumb trail and makes it a navigation landmark so that it is easy to locate
+- The links do not use ‘link’ colour or underline styling, however they are sufficiently identifiable as links by use of a link coloured (separator) icon, similar to [Link list](/design-system/components/lists?tab=design#other-lists) bullets
+- The visual separator icons are hidden to prevent announcement in screen readers. The separators are part of the visual presentation that signifies the breadcrumb trail, which is already semantically represented by the `<nav>` element with its label of “Breadcrumb”.
+- The breadcrumb list is announced as expected in all screen readers including VoiceOver
+- An indicator outline appears around the links when focused
+- The breadcrumb trail and separator icons are visible in Windows High Contrast Mode

apps/site/src/content/design-system/components/breadcrumb/accessibility/Keyboard support/content.mdoc

@@ -0,0 +1 @@
+Keyboard users navigate the breadcrumb links as they would with a standard list of links.

apps/site/src/content/design-system/components/breadcrumb/accessibility/Notes on accessibility/content.mdoc

@@ -0,0 +1,17 @@
+All components comply with WCAG 2.1 AA guidelines and Success Criteria. These fall under the [four principles of accessibility](/design-system/accessibility/design-system-accessibility) – Perceivable, Operable, Understandable and Robust. Below are some specific ways in which this component follows these principles:
+
+### Perceivable
+
+The Design System components have been designed to adhere to colour contrast ratios for both text and non-text elements. They have been coded to include text alternatives when required, and allow component text and labels to be resized. They do not use colour alone to convey information.
+
+### Operable
+
+Using breadcrumbs in your site or application aids navigation and orientation, and is an essential part of an accessible experience. As well as helping users determine where they are, they also provide another way to locate and navigate to pages. Using breadcrumbs will help you to comply with the core Success Criterion of the 'Navigable' guideline from WCAG 2.1.
+
+### Understandable
+
+WCAG compliance requires consistent and predicable interactions, clear and simple language, concise labels, no jargon or abbreviations and clear error messaging. These rules have been followed where content and interactions are included in Design System components or patterns.
+
+### Robust
+
+All Design System components have been coded so they can be clearly announced, understood and navigated using all modern assistive technologies.

apps/site/src/content/design-system/components/breadcrumb/design/Breadcrumbs/content.mdoc

@@ -0,0 +1,3 @@
+Breadcrumbs come in one style for navigational consistency across all touch-points.
+
+Loading...

apps/site/src/content/design-system/components/breadcrumb/design/User experience/content.mdoc

@@ -0,0 +1,9 @@
+Breadcrumbs provide a hierarchical overview of where a user is in your site. This is particularly helpful when navigation is deep or complex, and is also helpful for giving context when a user arrives on the page from another source (deep linking) rather than drilling down hierarchically. They also provide another way to quickly navigate to previous levels.
+
+Some things to keep in mind when using breadcrumbs:
+
+- Breadcrumbs should display the location of the current page in the site’s hierarchy – not the path through the site that the user has travelled. The browser back button is already designated this task.
+- Web convention dictates breadcrumbs usually sit toward the top of the page near the primary navigation.
+- Breadcrumbs should start with a link to the home page (except when truncating, see below) and end with the current page as the last item, which should not be a link.
+- You do not need to use breadcrumbs if your site has only one or two levels.
+- If your breadcrumb trail is becoming too long for its dedicated space, you can consider truncating it by only showing the last few links – this is especially important for small screen sizes ie mobile.

apps/site/src/content/design-system/components/breadcrumb/design/Visual design/content.mdoc

@@ -0,0 +1 @@
+Breadcrumbs have been designed with accessibility and functionality at the forefront. They’re intended to be as simple and understated as possible so as not to clutter the UI although (even with truncation) this can happen if page labels are too verbose or the information architecture is too deep.

apps/site/src/content/design-system/components/breadcrumb/index.yaml

@@ -1 +1,15 @@
 name: Breadcrumb
+description: >-
+  Breadcrumbs are styled navigational links used to indicate the user’s location
+  within your site. They are a simple, effective and proven method to aid
+  orientation.
+design:
+  - title: Breadcrumbs
+  - title: User experience
+  - title: Visual design
+accessibility:
+  - title: Notes on accessibility
+  - title: Accessibility features
+  - title: Keyboard support
+  - title: Accessibility API
+relatedInformation: []

apps/site/src/content/design-system/components/button-dropdown/accessibility/Accessibility API/content.mdoc

@@ -0,0 +1,3 @@
+*   `<button aria-expanded="false|true" aria-controls="{PANEL_ID}">`: Identifies a button element that toggles a content collapse and indicates the state of a collapsible element below. The _aria-controls_ attribute creates an association between toggle button and collapsible element (panel)
+*   `<div id="{PANEL_ID}">`: The panel must have a unique _id_ value. The toggle button _aria-controls_ and panel _id_ attribute values must match.
+*   `<span aria-hidden="true">`: The toggle button’s dropdown icon element has _aria-hidden_ to hide it from assistive technologies as it is decorative. The icon is a design convention to indicate a dropdown interface. Assistive technologies utilise the features listed above to provide users with an indication of this dropdown interface.

apps/site/src/content/design-system/components/button-dropdown/accessibility/Accessibility features/content.mdoc

@@ -0,0 +1,5 @@
+*   The user interacts with the button to toggle the panel – consistently whether using mouse, touch or keyboard. To hide the panel the user may toggle the button again, perform a ‘blur’ event (focusing elsewhere via click or keyboard) or press the ‘Esc’ key.
+*   As with similar components that hide/show content, this component follows a ‘user is in control’ approach. Rather than programmatically moving focus to the panel when shown, the toggle button has an _aria-expanded_ attribute; the assistive technology user can choose to ‘arrow down’ to announce the panel content if they wish.
+*   When the panel closes, focus returns to the button that originally toggled the panel
+*   An indicator outline appears around the button toggle when focused
+*   The button shape, text, icon content and panel is visible in Windows High Contrast Mode (WHCM). The button ‘look’ styling (colour) is not visible in WHCM.

apps/site/src/content/design-system/components/button-dropdown/accessibility/Keyboard support/content.mdoc

@@ -0,0 +1,2 @@
+*   Keyboard users navigate toggle buttons as they would with a standard button
+*   ‘Esc’ key closes the currently active panel

apps/site/src/content/design-system/components/button-dropdown/accessibility/Notes on accessibility/content.mdoc

@@ -0,0 +1,17 @@
+All components comply with WCAG 2.1 AA guidelines and Success Criteria. These fall under the [four principles of accessibility](/design-system/accessibility/design-system-accessibility) – Perceivable, Operable, Understandable and Robust. Below are some specific ways in which this component follows these principles:
+
+### Perceivable
+
+The Design System components have been designed to adhere to colour contrast ratios for both text and non-text elements. They have been coded to include text alternatives when required, and allow component text and labels to be resized. They do not use colour alone to convey information.
+
+### Operable
+
+The Design System components have been coded to be navigable using a keyboard and other assistive technologies. WCAG compliance recommends being aware of the time it takes for people to complete tasks and to not automatically move focus. Animation should be controlled and simple so as not to cause seizures, and it’s important to provide the ability to perform the same task in multiple ways where possible. These rules have been followed where navigation and interaction is included in Design System components or patterns.
+
+### Understandable
+
+WCAG compliance requires consistent and predicable interactions, clear and simple language, concise labels, no jargon or abbreviations and clear error messaging. These rules have been followed where content and interactions are included in Design System components or patterns.
+
+### Robust
+
+All Design System components have been coded so they can be clearly announced, understood and navigated using all modern assistive technologies.

apps/site/src/content/design-system/components/button-dropdown/design/Button dropdown menu sizes/content.mdoc

@@ -0,0 +1 @@
+Loading...

apps/site/src/content/design-system/components/button-dropdown/design/User experience/content.mdoc

@@ -0,0 +1,5 @@
+The Button dropdown is a highly configurable component and is useful if space is at a premium. Triggered on click/tap it can hold switches, checkboxes, radios etc. Headlines can also be used to separate content in the dropdown.
+
+Use a button dropdown as a way for your user to choose from a list of actions.
+
+Although a button dropdown saves on screen space it does mean the action you want the user to perform is hidden behind an interaction ie a button dropdown. Where possible, surface actions and choices at the page or screen level for discoverability and faster completion of tasks.

apps/site/src/content/design-system/components/button-dropdown/design/Visual design/content.mdoc

@@ -0,0 +1 @@
+As with all UI elements the dropdown is designed to be understated so as not to detract from the content. Generous padding and a deep shadow ensure that the dropdown stands out when opened over a content heavy interface.

apps/site/src/content/design-system/components/button-dropdown/index.yaml

@@ -1 +1,13 @@
-name: Button-Dropdown
+name: Button dropdown
+description: >-
+  Button dropdowns are essentially select boxes that contain a list of elements
+  to choose from. Use a button dropdown to display a styled list of actions.
+design:
+  - title: Button dropdown menu sizes
+  - title: User experience
+  - title: Visual design
+accessibility:
+  - title: Notes on accessibility
+  - title: Accessibility features
+  - title: Keyboard support
+  - title: Accessibility API

apps/site/src/content/design-system/components/button-group/accessibility/Accessibility API/content.mdoc

@@ -0,0 +1,2 @@
+*   `<input type="radio" id="{OPTION_ID}" name="{NAME}">`: Each item option is defined as a (hidden) radio _input_ and must have a unique _id_ value. A consistent _name_ attribute value is required on all inputs for toggling to operate correctly. \[React component: refer to _name_ prop, _id_ is auto-generated\]
+*   `<label for="{OPTION_ID}">`: Each radio _input_ is wrapped with a _label_ element and uses explicit association (connected to the input using a _for_ attribute) for optimal support in assistive technologies. \[React component: _for_ is auto-generated\]

apps/site/src/content/design-system/components/button-group/accessibility/Accessibility features/content.mdoc

@@ -0,0 +1,3 @@
+*   Option buttons behave as radio inputs for assistive technology users. Leveraging standard HTML form inputs to maintain state and store data provides optimal support in assistive technologies.
+*   An indicator outline appears around the button option when focused
+*   The button shape, text and icon content is visible in Windows High Contrast Mode (WHCM). The ‘look’ styling (colour) is not visible in WHCM. The current option button has thicker top and bottom borders to indicate the selected state in WHCM.

apps/site/src/content/design-system/components/button-group/accessibility/Keyboard support/content.mdoc

@@ -0,0 +1 @@
+*   Navigation pattern is consistent with radio inputs; arrow keys change the selection

apps/site/src/content/design-system/components/button-group/accessibility/Notes on accessibility/content.mdoc

@@ -0,0 +1,17 @@
+All components comply with WCAG 2.1 AA guidelines and Success Criteria. These fall under the [four principles of accessibility](/design-system/accessibility/design-system-accessibility) – Perceivable, Operable, Understandable and Robust. Below are some specific ways in which this component follows these principles:
+
+### Perceivable
+
+The Design System components have been designed to adhere to colour contrast ratios for both text and non-text elements. They have been coded to include text alternatives when required, and allow component text and labels to be resized. They do not use colour alone to convey information.
+
+### Operable
+
+The Design System components have been coded to be navigable using a keyboard and other assistive technologies. WCAG compliance recommends being aware of the time it takes for people to complete tasks and to not automatically move focus. Animation should be controlled and simple so as not to cause seizures, and it’s important to provide the ability to perform the same task in multiple ways where possible. These rules have been followed where navigation and interaction is included in Design System components or patterns.
+
+### Understandable
+
+WCAG compliance requires consistent and predicable interactions, clear and simple language, concise labels, no jargon or abbreviations and clear error messaging. These rules have been followed where content and interactions are included in Design System components or patterns.
+
+### Robust
+
+All Design System components have been coded so they can be clearly announced, understood and navigated using all modern assistive technologies.

apps/site/src/content/design-system/components/button-group/design/Button groups/content.mdoc

@@ -0,0 +1,11 @@
+**Sizes:** There are four button group sizes, make sure when laying out forms that your button group size and field sizes are aligned.
+
+Loading...
+
+**Multiple items:** We recommend only using up to 3 items in a button group, any more can become too difficult to scan and can become problematic at smaller viewports. Is also best to keep the labels short.
+
+Loading...
+
+**Block level:** Using block level button groups will allow the group to stretch the full width of the view port. This is useful for smaller viewports.
+
+Loading...

apps/site/src/content/design-system/components/button-group/design/Dos and don’ts/content.mdoc

@@ -0,0 +1,3 @@
+*   Only use up to 3 items in a group
+*   Do keep the labels short to aid scanability and avoid text wrapping
+*   If you have long labels, or more than 3 options, use [radio buttons](/design-system/components/radios?b=WBC).

apps/site/src/content/design-system/components/button-group/design/User experience/content.mdoc

@@ -0,0 +1,7 @@
+Button groups are a series of buttons grouped together on a single line to create a toggle. Behind the scenes in code, they work much the same way as radio buttons.
+
+As button groups tend to break on small screen sizes especially when using more than two (see do's and don'ts) and when using long copy (the text wraps inside the button), it is recommended to use sparingly. If the label lengths are too long or there are too many choices, they become hard to scan, losing efficacy. Our eyes lose the shape of the words as they are housed in 'block containers', making it more difficult to distinguish each word/choice, slowing down the user and increasing their cognitive effort.
+
+Consider the two-button button group when designing forms for questions with yes/no answers.
+
+It's important to note that button groups differ from [switches](/design-system/components/switches).

apps/site/src/content/design-system/components/button-group/design/Visual design/content.mdoc

@@ -0,0 +1 @@
+Button groups inherit styling from buttons, see [Buttons](/design-system/components/buttons) for more information.