digitalnsw · oisa · Nov 25, 2024 · Oct 22, 2024 · Oct 30, 2024 · Nov 3, 2024
diff --git a/contribute.md b/contribute.md
@@ -152,7 +152,7 @@ New components must follow the system as closely as possible, particularly the s
 
 ### Tested
 
-**Accessibility.** A component on its own must be accessible to [WCAG 2.1 level AA.](https://www.w3.org/TR/WCAG21/) Some documentation on how this has been checked, tested, or decisions made to support accessibility should be supplied.
+**Accessibility.** A component on its own must be accessible to [WCAG 2.2 level AA.](https://www.w3.org/TR/WCAG22/) Some documentation on how this has been checked, tested, or decisions made to support accessibility should be supplied.
 
 **Browser and device tested.** All components should meet our [browser support requirements.](https://github.com/govau/design-system-components#browser-support)
 

diff --git a/src/components/accordion/_guidance.hbs b/src/components/accordion/_guidance.hbs
@@ -45,4 +45,4 @@ layout: blank-layout.hbs
 <p>Consider tabs if the user would likely need to flick between content sections.</p>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
diff --git a/src/components/back-to-top/_guidance.hbs b/src/components/back-to-top/_guidance.hbs
@@ -47,4 +47,4 @@ layout: blank-layout.hbs
 {{/_docs-code}}
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
diff --git a/src/components/breadcrumbs/_guidance.hbs b/src/components/breadcrumbs/_guidance.hbs
@@ -11,7 +11,7 @@ layout: blank-layout.hbs
 	<li>reflect the names of the parent-level pages ensuring you use the same labels and casing as the main IA</li>
 </ul>
 
-<p><strong>Parent page</strong><br>Starts with the "Home" page and links users to parent-level pages in the IA</p>
+<p><strong>Parent page</strong><br>Starts with the "Home" page and links users to parent-level pages in the IA.</p>
 <p><strong>Icon</strong><br>The chevrons between the names shows the visual hierarchy between pages.</p>
 <p><strong>Current page</strong><br>Indicates the current page the user is viewing.</p>
 <p><strong>Ellipsis</strong><br>Provides a clickable option to expand and reveal the full breadcrumb path for mobile users.</p>
@@ -26,4 +26,4 @@ layout: blank-layout.hbs
 <p>The ellipsis button is injected into the list of breadcrumb items by adding <code>js-breadcrumbs</code> class into the nav element that wraps the breadcrumb items.</p>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
diff --git a/src/components/button/_guidance.hbs b/src/components/button/_guidance.hbs
@@ -33,4 +33,7 @@ layout: blank-layout.hbs
   <li>Consider the GOV.UK guidance on how to <a target="_blank" href="https://design-system.service.gov.uk/components/button/#stop-users-from-accidentally-sending-information-more-than-once">stop users from accidentally sending information more than once</a></li> 
   <li>Overusing buttons and button-style links makes them less noticable</li> 
   <li>A comprehensive review of buttons vs. links is available from Indiana University - <a target="_blank" href="https://ux.iu.edu/writings/buttons-vs-links-basic/">Buttons &amp; Links - the Basics</a></li> 
-</ul>
+</ul>
+
+<h2>Accessibility</h2>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
diff --git a/src/components/callout/_guidance.hbs b/src/components/callout/_guidance.hbs
@@ -25,4 +25,4 @@ layout: blank-layout.hbs
 <p>Callouts can contain an icon, a title and a message. Callouts should be short, easy to scan, informative and clear.</p>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
diff --git a/src/components/card-carousel/_carousel.scss b/src/components/card-carousel/_carousel.scss
@@ -161,6 +161,7 @@
     z-index: 1;
     transition: 0.2s;
     border: 2px solid var(--nsw-brand-dark);
+    cursor: pointer;
 
     &:hover {
       @include nsw-hover();
@@ -229,7 +230,7 @@
     transform: translateX(-50%);
 
     @include breakpoint('md') {
-      bottom: 1.5em;
+      bottom: 0.8em;
     }
 
     li {
@@ -287,21 +288,16 @@
   &__nav-item {
     button {
       background-color: transparent;
-      width: 1.2em;
-      height: 1.2em;
-      padding: 0;
+      width: 1.6em;
+      height: 1.6em;
+      padding: 4px;
       border-radius: 50%;
       border: 2px solid var(--nsw-brand-dark);
       transition: all 300ms ease-in-out;
       cursor: pointer;
       line-height: 0;
       margin: 0 0.25em;
 
-      @include breakpoint('md') {
-        width: 0.9em;
-        height: 0.9em;
-      }
-
       &:focus {
         @include nsw-focus(false);
         outline-offset: 2px;
@@ -319,16 +315,10 @@
 
     &--selected button {
       background-color: var(--nsw-brand-dark);
-      border-radius: 7px;
-      width: 2.2em;
 
       .nsw-section--invert & {
         background-color: var(--nsw-white);
       }
-
-      @include breakpoint('md') {
-        width: 1.6em;
-      }
     }
   }
 

diff --git a/src/components/card-carousel/_guidance.hbs b/src/components/card-carousel/_guidance.hbs
@@ -59,7 +59,7 @@ layout: blank-layout.hbs
 <p>If the carousel items number is smaller than the number of visible items, and you want them to be centered in the viewport, add a <code>data-justify-content="on"</code> to the <code>.nsw-carousel</code> item. By default items will be aligned to the left.</p>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
 
 <p>The card carousel conforms to the <a href="https://www.w3.org/WAI/ARIA/apg/patterns/carousel">W3C Carousel Design Pattern</a> and includes a <a href="https://www.w3.org/TR/wai-aria-1.2/#dfn-live-region">Live Region</a> that allows screen readers to read content whenever carousel slides change.</p>
 

diff --git a/src/components/card/_guidance.hbs b/src/components/card/_guidance.hbs
@@ -69,4 +69,4 @@ layout: blank-layout.hbs
 <p>When a user interacts with a card it inverts colour to indicate to the user which card they are currently focused on and reinforces the clickable area.</p>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
diff --git a/src/components/close-button/index.hbs b/src/components/close-button/index.hbs
@@ -30,7 +30,7 @@ meta-index: true
 {{/_docs-example}}
 
 <h3>Accessibility</h3>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
 
 <p>Do:</p>
 <ul>

diff --git a/src/components/content-block/_guidance.hbs b/src/components/content-block/_guidance.hbs
@@ -53,4 +53,4 @@ layout: blank-layout.hbs
 </ul>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
diff --git a/src/components/date-input/_guidance.hbs b/src/components/date-input/_guidance.hbs
@@ -44,4 +44,11 @@ layout: blank-layout.hbs
 <p>The year input is set to accept only a four-digit number while the month and day inputs can accept up to a two-digit number.</p>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
+
+<h3>Ensuring compliance through usage</h3>
+
+<h4>Redundant entry</h4>
+
+<p>To ensure WCAG 2.2 AA compliance for a date input component, proper usage and configuration are essential. Although the component supports accessibility at a basic level, it’s important to minimise redundant entry by retaining any previously entered dates if a user returns to the form. Make sure that the input field is clearly labelled, with guidance on the correct date format, and allow for easy error correction without requiring re-entry of the date.</p>
+<p>Adhering to these practices ensures a smoother, more accessible experience that meets compliance standards.</p>
diff --git a/src/components/date-picker/_guidance.hbs b/src/components/date-picker/_guidance.hbs
@@ -106,10 +106,17 @@ layout: blank-layout.hbs
 {{/_docs-code}}
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
 
 <p>The dialog contains a calendar that uses the grid pattern to present buttons that enable the user to choose a day from the calendar. Choosing a date from the calendar closes the dialog and populates the date input field. When the dialog is opened, if the input field is empty, or does not contain a valid date, then the current date is focused in the calendar. Otherwise, the focus is placed on the day in the calendar that matches the value of the date input field.</p>
 
+<h3>Ensuring compliance through usage</h3>
+
+<h4>Redundant entry</h4>
+
+<p>To ensure WCAG 2.2 AA compliance for a date picker, correct usage and configuration are key. While the component offers an accessible foundation, it's important to minimise redundant input by retaining previously selected dates if users return to the form. Ensure that keyboard navigation is fully functional, and provide clear labels and instructions for selecting dates. If errors occur, users should be able to correct them without needing to re-select the date.</p>
+<p>Following these usage practices supports an inclusive experience that meets accessibility standards.</p>
+
 <h3>Keyboard support</h3>
 
 <p>Users can navigate the calendar by using the cursor keys to move around the calendar, and can use the enter key or spacebar to select a date.</p>

diff --git a/src/components/dialog/_guidance.hbs b/src/components/dialog/_guidance.hbs
@@ -41,4 +41,11 @@ layout: blank-layout.hbs
 </ul>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
+
+<h3>Ensuring compliance through usage</h3>
+
+<h4>Consistent help</h4>
+<p>When using the Dialog component in your project, focus on creating a smooth, accessible experience by implementing it thoughtfully within your design flow. As the Dialog will automatically handle focus management, ensure any actions leading to the Dialog's opening are intuitive and necessary for your users. Use clear and concise text for any buttons or links within the Dialog to guide users seamlessly through the interaction.</p>
+<p>If the Dialog contains forms or complex choices, provide logical steps that align with the user journey, making it easy to understand and complete actions. Ensure the Dialog's purpose and content are directly relevant to the task at hand, allowing users to engage with the Dialog naturally and exit smoothly.</p>
+<p>This approach will create a cohesive, accessible experience that feels effortless to navigate.</p>
diff --git a/src/components/file-upload/_guidance.hbs b/src/components/file-upload/_guidance.hbs
@@ -71,4 +71,16 @@ layout: blank-layout.hbs
 <p>Error messages inform the user when there is an issue with the data they have input. Provide helpful error messages to clearly explain to the user what the issue is and how they can effectively address the errors. Check out <a href="https://design-system.service.gov.uk/components/file-upload/#error-messages">GOV.UK Design System's error messages for file uploads</a> for some best practice examples.</p>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
+
+<h3>Ensuring compliance through usage</h3>
+
+<h4>Redundant entry</h4>
+
+<p>To ensure WCAG 2.2 AA compliance for a file upload input, proper usage and configuration are essential. While the component provides a base level of accessibility, it's crucial to minimise redundant entry by configuring it so that users don't need to re-upload files or re-enter information they've previously provided. This includes allowing error correction without requiring re-entry and ensuring files remain accessible for review in multi-upload scenarios.</p>
+
+<h4>Consistent help</h4>
+
+<p>To create a consistent and accessible experience with the file upload component, provide clear, actionable guidance to support user interactions. Label the file upload field accurately, and include brief instructions on requirements like accepted file types or size limits, so users know exactly how to proceed. Use consistent language and formatting across all file upload interactions, ensuring users can easily recognise and understand the process.</p>
+
+<p>Adhering to these practices in usage supports a smooth, accessible experience and meets the necessary compliance standards.</p>
diff --git a/src/components/filters/_filters.scss b/src/components/filters/_filters.scss
@@ -337,6 +337,7 @@
       border: 0;
       background: none;
       padding: 0;
+      cursor: pointer;
 
       @include breakpoint('lg') {
         font-size: var(--nsw-font-size-sm-desktop);

diff --git a/src/components/filters/_guidance.hbs b/src/components/filters/_guidance.hbs
@@ -72,14 +72,29 @@ layout: blank-layout.hbs
 <p>For batch updates:</p>
 
 <ul>
-    <li>"Back" bar is sticky to top of screen and on selection closes filtering window with no updates to results.</li>
-    <li>"Apply filters" button is sticky to bottom of screen and on selection closes filtering window and displays updated results.</li>
-    <li>"Apply filters" is disabled if no filters are selected</li>
-    <li>When a filter is selected the icon changes to filled version and displays number of filters selected in brackets.</li>
+  <li>"Back" bar is sticky to top of screen and on selection closes filtering window with no updates to results.</li>
+  <li>"Apply filters" button is sticky to bottom of screen and on selection closes filtering window and displays updated results.</li>
+  <li>"Apply filters" is disabled if no filters are selected</li>
+  <li>When a filter is selected the icon changes to filled version and displays number of filters selected in brackets.</li>
 </ul>
 
 <p>For instant updates:</p>
 
 <ul>
-    <li>For filters that open down, when a filter is selected the icon changes to filled version and displays number of filters selected in brackets</li>
-</ul>
+  <li>For filters that open down, when a filter is selected the icon changes to filled version and displays number of filters selected in brackets</li>
+</ul>
+
+<h2>Accessibility</h2>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
+
+<h3>Ensuring compliance through usage</h3>
+
+<h4>Redundant entry</h4>
+
+<p>To ensure WCAG 2.2 AA compliance for a full array of filter components, correct usage and configuration are vital. While each component provides a foundation for accessibility, it's essential to minimise redundant entry by retaining previously selected or entered filter values if a user revisits the page or refines their search. Ensure all filter options are clearly labelled and provide instructions where needed, so users understand the available choices and input formats. Additionally, allow users to modify their filter selections easily without resetting other filters.</p>
+
+<h4>Consistent help</h4>
+
+<p>Ensure each input, whether it's a text field, checkbox, radio button, dropdown, or date input, is clearly labelled with descriptive text to communicate its purpose. Consistent error messaging and validation feedback are crucial; provide users with clear, actionable instructions if errors occur, without requiring them to re-enter data unnecessarily. Keyboard navigation should be maintained across all inputs, with each respective field focus indicator allowing users to move easily between fields clearly.</p>
+
+<p>Following these practices will help create accessible, user-friendly forms that offer a seamless experience across various input types.</p>
diff --git a/src/components/footer/_guidance.hbs b/src/components/footer/_guidance.hbs
@@ -30,5 +30,5 @@ layout: blank-layout.hbs
 <p>The copyright statement is required as it is applies to all pages of the site.</p>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
 
diff --git a/src/components/form/_form.scss b/src/components/form/_form.scss
@@ -66,6 +66,10 @@ $nsw-form-tick: '<svg fill="#ffffff" version="1.1" xmlns="http://www.w3.org/2000
       font-weight: var(--nsw-font-normal);
     }
 
+    + select {
+      cursor: pointer;
+    }
+
     + input,
     + textarea,
     + select,
@@ -372,6 +376,7 @@ $nsw-form-tick: '<svg fill="#ffffff" version="1.1" xmlns="http://www.w3.org/2000
     min-height: rem(32px);
     display: block;
     position: relative;
+    cursor: pointer;
 
     &::before {
       content: '';

diff --git a/src/components/form/_guidance.hbs b/src/components/form/_guidance.hbs
@@ -49,4 +49,16 @@ layout: blank-layout.hbs
 </ul>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>
+
+<h3>Ensuring compliance through usage</h3>
+
+<h4>Redundant entry</h4>
+
+<p>To ensure WCAG 2.2 AA compliance for a full array of filter components, correct usage and configuration are vital. While each component provides a foundation for accessibility, it's essential to minimise redundant entry by retaining previously selected or entered filter values if a user revisits the page or refines their search. Ensure all filter options are clearly labelled and provide instructions where needed, so users understand the available choices and input formats. Additionally, allow users to modify their filter selections easily without resetting other filters.</p>
+
+<h4>Consistent help</h4>
+
+<p>Ensure each input, whether it's a text field, checkbox, radio button, dropdown, or date input, is clearly labelled with descriptive text to communicate its purpose. Consistent error messaging and validation feedback are crucial; provide users with clear, actionable instructions if errors occur, without requiring them to re-enter data unnecessarily. Keyboard navigation should be maintained across all inputs, with each respective field focus indicator allowing users to move easily between fields clearly.</p>
+
+<p>Following these practices will help create accessible, user-friendly forms that offer a seamless experience across various input types.</p>
diff --git a/src/components/global-alert/_guidance.hbs b/src/components/global-alert/_guidance.hbs
@@ -30,4 +30,4 @@ layout: blank-layout.hbs
 <p>Do not display in response to an action initiated by a user interaction or system event.</p>
 
 <h2>Accessibility</h2>
-<p>All components are responsive and meet WCAG 2.1 AA accessibility guidelines.</p>
+<p>All components are responsive and designed to comply with WCAG 2.2 AA accessibility standards. Full compliance depends on using and configuring the components correctly.</p>