From 348226210b595d499965eb8fa93c4620915de3f8 Mon Sep 17 00:00:00 2001 From: asikinack Date: Tue, 9 Jul 2024 13:18:01 -0600 Subject: [PATCH 1/6] DO NOT TEST - adding space --- src/routes/get-started/Roadmap.tsx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/get-started/Roadmap.tsx b/src/routes/get-started/Roadmap.tsx index 8ca222d37..22dad06c8 100644 --- a/src/routes/get-started/Roadmap.tsx +++ b/src/routes/get-started/Roadmap.tsx @@ -33,7 +33,7 @@ export default function RoadmapPage() {
  • Objective: To simplify the design and development process by offering predefined page layouts and comprehensive guidelines on the structure and workflow of - citizen-facing forms. + citizen-facing forms.
  • Benefit: Accelerates delivery, ensures consistency, and maintains From fd32f239ef52436d9866bc6114cfe7d07e4fe767 Mon Sep 17 00:00:00 2001 From: Vanessa Tran Date: Wed, 10 Jul 2024 09:26:34 -0600 Subject: [PATCH 2/6] chore: add Accessibility.tsx --- src/App.tsx | 2 + src/routes/get-started/Accessibility.tsx | 124 ++++++++++++++++++++ src/routes/get-started/GetStartedLayout.tsx | 1 + 3 files changed, 127 insertions(+) create mode 100644 src/routes/get-started/Accessibility.tsx diff --git a/src/App.tsx b/src/App.tsx index ee9f965fb..9e9bbfd29 100644 --- a/src/App.tsx +++ b/src/App.tsx @@ -109,6 +109,7 @@ import TaskListPage from "@routes/patterns/TaskListPage"; import QuestionPage from "@routes/patterns/QuestionPage"; import ReviewPage from "@routes/patterns/ReviewPage"; import ResultPage from "@routes/patterns/ResultPage"; +import AccessibilityPage from "@routes/get-started/Accessibility.tsx"; interface DeviceWidthProviderProps { @@ -207,6 +208,7 @@ const router = createBrowserRouter( } /> + } /> } /> } /> diff --git a/src/routes/get-started/Accessibility.tsx b/src/routes/get-started/Accessibility.tsx new file mode 100644 index 000000000..76bb06b52 --- /dev/null +++ b/src/routes/get-started/Accessibility.tsx @@ -0,0 +1,124 @@ +import { ComponentContent } from "@components/component-content/ComponentContent"; + +export default function AccessibilityPage() { + return ( + +

    Accessibility

    +

    + A high level summary of the work the design system team plans to complete in 2024. For more + information on the latest releases, visit the{" "} + + release notes + + +

    +
    +

    + Please note the roadmap is subject to changes as we learn more information. We will + communicate any updates on the direction of the design system so that product teams can + align, prepare, and strategize their work as applicable. +

    +

    + See our{" "} + + GitHub design system backlog + {" "} + for more details on our priorities and day-to-day activities. +

    + +

    Now

    +

    Work that is currently in progress.

    +

    Citizen-facing form documentation and examples:

    +
      +
    • + Objective: To simplify the design and development process by offering + predefined page layouts and comprehensive guidelines on the structure and workflow of + citizen-facing forms. +
      • +
    • + Benefit: Accelerates delivery, ensures consistency, and maintains + high quality across projects. +
      • + +
    + +

    Angular library wrappers:

    +
      +
    • + Objective: To streamline the integration of our components with Angular, + enhancing natural development flows and real-time error checking. +
      • +
    • + Benefit: Increases efficiency and reduces development time, enabling + Angular developers to utilize design system components more effectively. +
      • + +
    + +

    Next

    +

    Work that we have a clear definition around, discovery is well underway, or we have moved + to the design phase.

    +

    Sample citizen-facing form:

    +
      +
    • + Objective: To create an implementation of a citizen-facing form through + an end-to-end sample service that integrates all components as they would appear in actual + use. +
      • +
    • + Benefit: Provides a practical example to facilitate the adoption of the + citizen-facing form pattern. +
      • + +
    + +

    Design documentation enhancement:

    +
      +
    • + Objective: To centralize design resources by migrating design and usage + guidelines from Figma to our design system website. +
      • +
    • + Benefit: Improves accessibility of documentation for teams and allows + for the refinement of content based on feedback from earlier iterations. +
      • + +
    + +

    Future

    +

    Work that is currently in the early phases of discovery and may see substantial changes + as the work becomes more defined.

    +

    Continued focus on patterns:

    +

    Patterns will help drive consistency and quality across digital services. They also + allow teams to get to working software more quickly, leaving more time for content design, + user and stakeholder engagement, and testing.

    +

    Complex form pattern:

    +
      +
    • + Definition: For frequent or expert users, this pattern emphasizes speed + and flexibility, streamlining repeated form interactions. +
      • +
    • + Context: Ideal for scenarios where efficiency and speed are prioritized + over clarity and error prevention. +
      • + +
    + +

    Case management patterns:

    +
      +
    • + Definition: To support professional users in managing, reviewing, and + processing cases within work contexts. +
      • +
    • + Context: Used in services where cases are created, reviewed, actioned, + and processed, supporting "case" workflows. +
      • + +
    + +
    +     + ); +} diff --git a/src/routes/get-started/GetStartedLayout.tsx b/src/routes/get-started/GetStartedLayout.tsx index 27ccbddb6..428c03e46 100644 --- a/src/routes/get-started/GetStartedLayout.tsx +++ b/src/routes/get-started/GetStartedLayout.tsx @@ -18,6 +18,7 @@ export default function GetStartedLayout() { Supported Browsers QA testing + Accessibility Roadmap User experience guidelines From 010ba175b4c8973359619c92d6aa830e22fc33d7 Mon Sep 17 00:00:00 2001 From: asikinack Date: Mon, 22 Jul 2024 16:16:35 -0600 Subject: [PATCH 3/6] DO NOT TEST - Updating accessibility content --- src/routes/get-started/Accessibility.tsx | 173 ++++++++++++++--------- 1 file changed, 109 insertions(+), 64 deletions(-) diff --git a/src/routes/get-started/Accessibility.tsx b/src/routes/get-started/Accessibility.tsx index 76bb06b52..a7a36c2c8 100644 --- a/src/routes/get-started/Accessibility.tsx +++ b/src/routes/get-started/Accessibility.tsx @@ -5,119 +5,164 @@ export default function AccessibilityPage() {

    Accessibility

    - A high level summary of the work the design system team plans to complete in 2024. For more - information on the latest releases, visit the{" "} - - release notes - - + We are dedicated to creating inclusive and equitable digital services for all citizens and workers.

    - Please note the roadmap is subject to changes as we learn more information. We will - communicate any updates on the direction of the design system so that product teams can - align, prepare, and strategize their work as applicable. -

    -

    - See our{" "} - - GitHub design system backlog - {" "} - for more details on our priorities and day-to-day activities. + Each component is designed and developed to ensure it meets the required accessibility standards of WCAG AA. The design system has been designed to be accessible by all users, including those with disabilities.

    -

    Now

    -

    Work that is currently in progress.

    -

    Citizen-facing form documentation and examples:

    -
      -
    • - Objective: To simplify the design and development process by offering - predefined page layouts and comprehensive guidelines on the structure and workflow of - citizen-facing forms. +

      WCAG accessibility compliance

      +

      We follow the 4 principles of web accessibility upon which WCAG is based:

      +
        +
      1. Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
      2. - Benefit: Accelerates delivery, ensures consistency, and maintains - high quality across projects. + Operable – User interface components and navigation must be operable. +
        3. +
      3. + Undersandable – Information and the operation of the user interface must be understandable. +
        4. +
      4. + Robust – Content must be robust enough that it can be interpreted reliably by operating systems, web browsers, and assistive technologies.
        5. -
    + -

    Angular library wrappers:

    +

    Design considerations

    +

    Visuals

    • - Objective: To streamline the integration of our components with Angular, - enhancing natural development flows and real-time error checking. + Colour contrast - Our components all meet colour contrast ratios following WCAG 2.2 guidance. In Figma, you can use the Able plugin to check colour contrast in your designs.
    • - Benefit: Increases efficiency and reduces development time, enabling - Angular developers to utilize design system components more effectively. + Text-size - We recommend using text no smaller than 16px for adequate readability by all users. +
      • +
    • + Avoid using colour as the sole indicator of information - For instance, always supply an icon or text to communicate, rather than relying on colour alone. Colour-only changes do not work well for those who may be colour blind or have low vision.
    -

    Next

    -

    Work that we have a clear definition around, discovery is well underway, or we have moved - to the design phase.

    -

    Sample citizen-facing form:

    +

    Interaction

    +
      +
    • + Visually distinct designs for every component state - Such as focus, hover, focus + hover, active, selected, disabled, and anything else that might be relevant. +
      • +
    • + Large touch targets - Touch targets should be a minimum size of 24x24 CSS pixels of space to ensure they are large enough for people with limited mobility to accurately press what they're aiming for. +
      • +
    • + Avoid disabling elements on the page - If you need to disable something, consider hiding it altogether from the user and/or provide information to the user for how they can move forward. Do not disable buttons to submit a form, allow the user to submit the form and then use validation and error handling to help the user recover and correct their errors to move forward. +
      • +
    +

    Content

    • - Objective: To create an implementation of a citizen-facing form through - an end-to-end sample service that integrates all components as they would appear in actual - use. + Clear language - Use simple, straightforward language to ensure that content is easily understandable. Avoid jargon and technical terms; if they must be used ensure they are clearly defined. Aim for an accessible reading level to accommodate a broad audience.
    • - Benefit: Provides a practical example to facilitate the adoption of the - citizen-facing form pattern. + Structured headings and labels - Organize content using hierarchical headings and labels to provide a clear structure. This helps users, especially those with cognitive disabilities or those using screen readers, to navigate and comprehend information more effectively. +
      • +
    • + Feedback and error messages - Design clear, concise feedback and error messages that are easy to understand.
    -

    Design documentation enhancement:

    +

    Development considerations

    • - Objective: To centralize design resources by migrating design and usage - guidelines from Figma to our design system website. + Accessible Rich Internet Applications (ARIA) attributes provide ways to make applications more accessible by supplementing HTML so that common interactions in applications can be properly utilized with assistive technology. +
      • +
    • + Accessible Properties in Components - Our design system components come with automatically included ARIA behaviours and properties. These are clearly documented to help developers understand and correctly implement accessibility features without the need for extensive modifications. +
      • +
    • + Keyboard Navigation is essential for users who rely on keyboard-only interactions. All interactive elements are accessible through logical tab sequences with visible focus indicators present.
    • - Benefit: Improves accessibility of documentation for teams and allows - for the refinement of content based on feedback from earlier iterations. + Performance Optimization - Ensuring that websites are optimized for speed and responsiveness, which can significantly affect users with older technology or slower internet connections.
    -

    Future

    -

    Work that is currently in the early phases of discovery and may see substantial changes - as the work becomes more defined.

    -

    Continued focus on patterns:

    -

    Patterns will help drive consistency and quality across digital services. They also - allow teams to get to working software more quickly, leaving more time for content design, - user and stakeholder engagement, and testing.

    -

    Complex form pattern:

    +

    Accessibility testing

    +

    Building with accessible GOA components does not guarantee an accessible service. You need to keep testing to stay accessible.

    +

    We recommend a mix of automated, semi-automated, and manual testing in addition to actual tests with real people who need assistive accommodations to interact with services effectively.

    + +

    Screen reader tools

    • - Definition: For frequent or expert users, this pattern emphasizes speed - and flexibility, streamlining repeated form interactions. + NVDA (NonVisual Desktop Access - A free and open-source screen reader for Windows.
    • - Context: Ideal for scenarios where efficiency and speed are prioritized - over clarity and error prevention. + VoiceOver - An integrated screen reader in all Apple operating systems. +
      • +
    • + JAWS (Job Access With Speech) - A comprehensive screen reader for Windows. Request a licence.
    -

    Case management patterns:

    +

    Automated testing tools

    • - Definition: To support professional users in managing, reviewing, and - processing cases within work contexts. + Axe - An accessibility testing tool that works both as a browser extension and within development testing environments. +
      • +
    • + Wave - A suite of evaluation tools that helps authors make their web content more accessible to individuals with disabilities.
    • - Context: Used in services where cases are created, reviewed, actioned, - and processed, supporting "case" workflows. + Lighthouse - An open-source, automated tool for improving the quality of web pages, with audits for performance, accessibility, progressive web apps, and more.
    - + +

    Usability testing with persons with disabilities

    +
      +
    • Disability Employee Resource Group - A team of government employees who are committed to improving the accessibility of our digital products through direct involvement in user testing. Contact pamela.klebanov@gov.ab.ca and corinna.sales@gov.ab.ca for more information and to recruit users for testing.
      • +
    +

    ARIA roles and headings

    +

    Proper use of ARIA roles and HTML headings is essential for creating accessible web content. These elements help assistive technologies interpret the structure and function of a webpage, enabling users with disabilities to navigate and interact more effectively. Here’s how to implement basic roles and headings:

    +

    ARIA roles

    + <
      +
    • Landmark Roles - Use landmark roles to define areas of the page like banner, navigation, main, complementary, and content info. These roles enable users with assistive technologies to quickly navigate to specific sections of the page.
      • +
    • Widget Roles - Assign roles such as button, link, tab, tooltip, and alert to interactive elements to communicate the element’s purpose and state. This is crucial for users who rely on screen readers to interact with page elements.
      • +
    • Application Role - Use the application role sparingly, as it indicates to assistive technologies that traditional navigation and reading modes should be disabled. Use this role only when necessary to manage complex interactions.
      • +
    +

    HTML Headings

    +
      +
    • Structure - Use headings to structure content hierarchically. Begin with an h1 for the main title of the page, followed by h2 for main section titles, and h3 (and so forth) for subsections. This hierarchical use of headings helps users with screen readers understand the layout and navigate the content efficiently.
      • +
    • Consistency - Maintain consistency in heading usage across pages. This predictability aids users in quickly finding the information they need.
      • +
    + +

    Dynamic content

    +

    Dynamic content, which updates or changes without a full page reload, poses specific challenges for accessibility. Ensuring that these updates are perceivable and manageable by all users, especially those using assistive technologies, is crucial for maintaining an inclusive web environment. Here are key strategies for handling dynamic content accessibility:

    +

    Use of ARIA Live Regions

    +
      +
    • Purpose - ARIA live regions provide a way to programmatically notify assistive technologies of content changes without requiring user focus to shift to that content.
      • +
    • Implementation - Utilize attributes like aria-live (with values such as "polite", "assertive", or "off") to manage how updates are announced. For example, use "polite" for updates that are not urgent, so they do not interrupt what the user is currently doing.
      • +
    • Examples - Common applications include updating a error summary, notification messages, or the status of ongoing processes.
      • +
    +

    Role attribute

    +
      +
    • Application - Assign the role="status" or role="alert" to small regions where simple feedback about an operation in a user interface is needed. role="alert" automatically has an implicit aria-live value of "assertive", and it should be used for critical updates that require immediate attention.
      • +
    +

    Managing focus

    +
      +
    • Focus handling - In Single Page Applications (SPAs), manage focus to ensure that users understand where they are after dynamic content loads. For example, when opening a modal or navigating in a single-page application, move focus to the new content or back to a logical starting point after the content is dismissed or changed.
      • +
    • Navigation - Use ARIA roles like role="navigation" and techniques such as updating the browser's history API to improve the usability of dynamically changing content.
      • +
    +

    Skip to content link

    +

    Skip to content links are a crucial feature in web accessibility. These links allow users, especially those using screen readers or keyboard navigation, to bypass repetitive navigation links and directly access the main content of a page. Implementing skip navigation links effectively enhances the usability of a website for users with disabilities by reducing the effort required to reach actionable content.

    +
      +
    • Skip navigation links are typically positioned at the very beginning of the webpage, making them the first focusable element.
      • +
    • When activated, these links allow users to jump straight to a designated section of the page, usually the main content area, which helps avoid the frustration of tabbing through lengthy navigation menus.
      • +
    • For sighted keyboard users, it's crucial that these links become visible on focus, ensuring that they are both accessible and unobtrusive to the overall site design.
      • +
    +

    Design system component

    +

    We recognize the importance of this feature and have a skip navigation link component planned in our development backlog. View Github issue.

     ); From 5d9a774fa003ababa25ec532d5ca0a728d1e9c70 Mon Sep 17 00:00:00 2001 From: Vanessa Tran Date: Mon, 22 Jul 2024 16:38:25 -0600 Subject: [PATCH 4/6] fix: build error --- package-lock.json | 16 +-- package.json | 4 +- src/routes/get-started/Accessibility.tsx | 167 +++++++++-------------- 3 files changed, 71 insertions(+), 116 deletions(-) diff --git a/package-lock.json b/package-lock.json index a84f3feee..bf3351580 100644 --- a/package-lock.json +++ b/package-lock.json @@ -8,8 +8,8 @@ "name": "code-sandbox", "version": "0.0.0", "dependencies": { - "@abgov/react-components": "4.21.1", - "@abgov/web-components": "1.22.0", + "@abgov/react-components": "4.22.0", + "@abgov/web-components": "1.23.1", "@faker-js/faker": "^8.3.1", "highlight.js": "^11.8.0", "react": "^18.2.0", @@ -41,9 +41,9 @@ } }, "node_modules/@abgov/react-components": { - "version": "4.21.1", - "resolved": "https://registry.npmjs.org/@abgov/react-components/-/react-components-4.21.1.tgz", - "integrity": "sha512-PXLRcW1iIkOIXwOVFfOE0dUqmOhxzZuX2i2OCORtOrd388Da9zyT85lrJ8ZD5TUkDTKwnuHc6urc+nlj47hXNw==", + "version": "4.22.0", + "resolved": "https://registry.npmjs.org/@abgov/react-components/-/react-components-4.22.0.tgz", + "integrity": "sha512-VComCKY+j9kIkKLEUMyMOmdiO4GjBxV3sWuwmMMh9eNuP6Js+CLqg087AHWOzpsNGtcgIZRSAuEXBLQmyWvkcQ==", "peerDependencies": { "@types/react": "^17.0.0 || ^18.0.0", "react": "^17.0.0 || ^18.0.0", @@ -51,9 +51,9 @@ } }, "node_modules/@abgov/web-components": { - "version": "1.22.0", - "resolved": "https://registry.npmjs.org/@abgov/web-components/-/web-components-1.22.0.tgz", - "integrity": "sha512-J/rfNQbUNhErydAbbdAZ40k2E9BdCDugiicinSZsRteXBxV0XsFycs9yFjeiZrnYkv1zZfba5xv5l+fRTrXB3A==", + "version": "1.23.1", + "resolved": "https://registry.npmjs.org/@abgov/web-components/-/web-components-1.23.1.tgz", + "integrity": "sha512-vSVbKqfkZPg6gdSAwuYrT2m4LAKJjaUoOg1RrarSoc65rhWLm4yVC/VQTY7z0hUOn+kjOTdLw25eE6LLmMYFYA==", "peerDependencies": { "@sveltejs/vite-plugin-svelte": "3.x", "glob": "10.x", diff --git a/package.json b/package.json index 990fa5b91..ddc78a682 100644 --- a/package.json +++ b/package.json @@ -12,8 +12,8 @@ "prettier": "npx prettier . --write" }, "dependencies": { - "@abgov/react-components": "4.21.1", - "@abgov/web-components": "1.22.0", + "@abgov/react-components": "4.22.0", + "@abgov/web-components": "1.23.1", "@faker-js/faker": "^8.3.1", "highlight.js": "^11.8.0", "react": "^18.2.0", diff --git a/src/routes/get-started/Accessibility.tsx b/src/routes/get-started/Accessibility.tsx index a7a36c2c8..19134ef77 100644 --- a/src/routes/get-started/Accessibility.tsx +++ b/src/routes/get-started/Accessibility.tsx @@ -13,155 +13,110 @@ export default function AccessibilityPage() {

    WCAG accessibility compliance

    -

    We follow the 4 principles of web accessibility upon which WCAG is based:

    +

    We follow the 4 principles of web accessibility upon which WCAG is based:

      -
    1. Perceivable – Information and user interface components must be presentable to users in ways they can perceive. -
      2. -
    2. - Operable – User interface components and navigation must be operable. -
      3. -
    3. - Undersandable – Information and the operation of the user interface must be understandable. -
      4. -
    4. - Robust – Content must be robust enough that it can be interpreted reliably by operating systems, web browsers, and assistive technologies. -
      5. - +
    5. Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
      6. +
    6. Operable – User interface components and navigation must be operable.
      7. +
    7. Understandable – Information and the operation of the user interface must be understandable.
      8. +
    8. Robust – Content must be robust enough that it can be interpreted reliably by operating systems, web browsers, and assistive technologies.

    Design considerations

    Visuals

      -
    • - Colour contrast - Our components all meet colour contrast ratios following WCAG 2.2 guidance. In Figma, you can use the Able plugin to check colour contrast in your designs. -
      • -
    • - Text-size - We recommend using text no smaller than 16px for adequate readability by all users. -
      • -
    • - Avoid using colour as the sole indicator of information - For instance, always supply an icon or text to communicate, rather than relying on colour alone. Colour-only changes do not work well for those who may be colour blind or have low vision. -
      • - +
    • Colour contrast - Our components all meet colour contrast ratios following WCAG 2.2 guidance. In Figma, you can use the Able plugin to check colour contrast in your designs.
      • +
    • Text-size - We recommend using text no smaller than 16px for adequate readability by all users.
      • +
    • Avoid using colour as the sole indicator of information - For instance, always supply an icon or text to communicate, rather than relying on colour alone. Colour-only changes do not work well for those who may be colour blind or have low vision.

    Interaction

    -
      -
    • - Visually distinct designs for every component state - Such as focus, hover, focus + hover, active, selected, disabled, and anything else that might be relevant. -
      • -
    • - Large touch targets - Touch targets should be a minimum size of 24x24 CSS pixels of space to ensure they are large enough for people with limited mobility to accurately press what they're aiming for. -
      • -
    • - Avoid disabling elements on the page - If you need to disable something, consider hiding it altogether from the user and/or provide information to the user for how they can move forward. Do not disable buttons to submit a form, allow the user to submit the form and then use validation and error handling to help the user recover and correct their errors to move forward. -
      • -
    +
      +
    • Visually distinct designs for every component state - Such as focus, hover, focus + hover, active, selected, disabled, and anything else that might be relevant.
      • +
    • Large touch targets - Touch targets should be a minimum size of 24x24 CSS pixels of space to ensure they are large enough for people with limited mobility to accurately press what they're aiming for.
      • +
    • Avoid disabling elements on the page - If you need to disable something, consider hiding it altogether from the user and/or provide information to the user for how they can move forward. Do not disable buttons to submit a form, allow the user to submit the form and then use validation and error handling to help the user recover and correct their errors to move forward.
      • +
    +

    Content

      -
    • - Clear language - Use simple, straightforward language to ensure that content is easily understandable. Avoid jargon and technical terms; if they must be used ensure they are clearly defined. Aim for an accessible reading level to accommodate a broad audience. -
      • -
    • - Structured headings and labels - Organize content using hierarchical headings and labels to provide a clear structure. This helps users, especially those with cognitive disabilities or those using screen readers, to navigate and comprehend information more effectively. -
      • -
    • - Feedback and error messages - Design clear, concise feedback and error messages that are easy to understand. -
      • - +
    • Clear language - Use simple, straightforward language to ensure that content is easily understandable. Avoid jargon and technical terms; if they must be used ensure they are clearly defined. Aim for an accessible reading level to accommodate a broad audience.
      • +
    • Structured headings and labels - Organize content using hierarchical headings and labels to provide a clear structure. This helps users, especially those with cognitive disabilities or those using screen readers, to navigate and comprehend information more effectively.
      • +
    • Feedback and error messages - Design clear, concise feedback and error messages that are easy to understand.

    Development considerations

      -
    • - Accessible Rich Internet Applications (ARIA) attributes provide ways to make applications more accessible by supplementing HTML so that common interactions in applications can be properly utilized with assistive technology. -
      • -
    • - Accessible Properties in Components - Our design system components come with automatically included ARIA behaviours and properties. These are clearly documented to help developers understand and correctly implement accessibility features without the need for extensive modifications. -
      • -
    • - Keyboard Navigation is essential for users who rely on keyboard-only interactions. All interactive elements are accessible through logical tab sequences with visible focus indicators present. -
      • -
    • - Performance Optimization - Ensuring that websites are optimized for speed and responsiveness, which can significantly affect users with older technology or slower internet connections. -
      • - +
    • Accessible Rich Internet Applications (ARIA) attributes provide ways to make applications more accessible by supplementing HTML so that common interactions in applications can be properly utilized with assistive technology.
      • +
    • Accessible Properties in Components - Our design system components come with automatically included ARIA behaviours and properties. These are clearly documented to help developers understand and correctly implement accessibility features without the need for extensive modifications.
      • +
    • Keyboard Navigation is essential for users who rely on keyboard-only interactions. All interactive elements are accessible through logical tab sequences with visible focus indicators present.
      • +
    • Performance Optimization - Ensuring that websites are optimized for speed and responsiveness, which can significantly affect users with older technology or slower internet connections.

    Accessibility testing

    Building with accessible GOA components does not guarantee an accessible service. You need to keep testing to stay accessible.

    We recommend a mix of automated, semi-automated, and manual testing in addition to actual tests with real people who need assistive accommodations to interact with services effectively.

    - +

    Screen reader tools

      -
    • - NVDA (NonVisual Desktop Access - A free and open-source screen reader for Windows. -
      • -
    • - VoiceOver - An integrated screen reader in all Apple operating systems. -
      • -
    • - JAWS (Job Access With Speech) - A comprehensive screen reader for Windows. Request a licence. -
      • - +
    • NVDA (NonVisual Desktop Access) - A free and open-source screen reader for Windows.
      • +
    • VoiceOver - An integrated screen reader in all Apple operating systems.
      • +
    • JAWS (Job Access With Speech) - A comprehensive screen reader for Windows. Request a licence.
    - +

    Automated testing tools

      -
    • - Axe - An accessibility testing tool that works both as a browser extension and within development testing environments. -
      • -
    • - Wave - A suite of evaluation tools that helps authors make their web content more accessible to individuals with disabilities. -
      • -
    • - Lighthouse - An open-source, automated tool for improving the quality of web pages, with audits for performance, accessibility, progressive web apps, and more. -
      • - +
    • Axe - An accessibility testing tool that works both as a browser extension and within development testing environments.
      • +
    • Wave - A suite of evaluation tools that helps authors make their web content more accessible to individuals with disabilities.
      • +
    • Lighthouse - An open-source, automated tool for improving the quality of web pages, with audits for performance, accessibility, progressive web apps, and more.

    Usability testing with persons with disabilities

      -
    • Disability Employee Resource Group - A team of government employees who are committed to improving the accessibility of our digital products through direct involvement in user testing. Contact pamela.klebanov@gov.ab.ca and corinna.sales@gov.ab.ca for more information and to recruit users for testing.
      • -
    -

    ARIA roles and headings

    -

    Proper use of ARIA roles and HTML headings is essential for creating accessible web content. These elements help assistive technologies interpret the structure and function of a webpage, enabling users with disabilities to navigate and interact more effectively. Here’s how to implement basic roles and headings:

    +
  • Disability Employee Resource Group - A team of government employees who are committed to improving the accessibility of our digital products through direct involvement in user testing. Contact pamela.klebanov@gov.ab.ca and corinna.sales@gov.ab.ca for more information and to recruit users for testing.
    • + + +

    ARIA roles and headings

    +

    Proper use of ARIA roles and HTML headings is essential for creating accessible web content. These elements help assistive technologies interpret the structure and function of a webpage, enabling users with disabilities to navigate and interact more effectively. Here’s how to implement basic roles and headings:

    ARIA roles

    - <

    ARIA roles and headings

    -

    Proper use of ARIA roles and HTML headings is essential for creating accessible web content. These elements help assistive technologies interpret the structure and function of a webpage, enabling users with disabilities to navigate and interact more effectively. Here’s how to implement basic roles and headings:

    +

    Proper ARIA roles and HTML headings are essential for creating accessible web content. These elements help assistive technologies interpret the structure and function of a webpage, enabling users with disabilities to navigate and interact more effectively. Here’s how to implement basic roles and headings:

    ARIA roles