+
+ 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.
+
+
+
WCAG accessibility compliance
+
We follow the 4 principles of web accessibility upon which WCAG is based:
+
+ - Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
+ - Operable – User interface components and navigation must be operable.
+ - Understandable – Information and the operation of the user interface must be understandable.
+ - 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.
+
+
+
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
+
+ - 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.
+
+
+
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.
+
+
+
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.
+
+
+
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 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
+
+ - 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 page's main title, 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 an 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.
+