Accessibility We design digital products that everyone can use, regardless of ability or circumstance. This guide outlines principles, design practices, and tools to support accessible and inclusive experiences. Design System components meet WCAG 2.2 Level AA standards. Teams must still ensure accessibility across the full product experience.

Accessibility and inclusion

Inclusive design is broader than meeting an accessibility standard. It aims to make experiences usable for as many people as possible, regardless of ability or circumstance. Disabilities are not always visible or permanent. Similar barriers can affect someone with:
  • Permanent needs: Long-term conditions (for example, limb difference, ADHD).
  • Temporary needs: Short-term conditions (for example, a fractured arm, low sleep).
  • Situational needs: Context-driven limitations (for example, bright sunlight, one-handed use, noisy environments).
Designing for permanent needs often improves the experience for temporary and situational needs too.

Making digital products accessible and inclusive

Use a mix of standards and real-world validation

  • WCAG compliance: Use the Web Content Accessibility Guidelines (WCAG) as your baseline for web accessibility.
  • Usability testing: Test with a diverse set of users to confirm tasks are clear and workflows match expectations.
  • Accessibility testing: Include people with disabilities in testing. This often finds barriers that a checklist or automated scan can miss.

Key principles of accessibility

Follow the four WCAG principles .

Perceivable

Users must be able to sense information.
  • Provide text alternatives for non-text content.
  • Support reflow and resizing without losing meaning.
  • Ensure content is easy to see and hear.

Operable

Users must be able to operate all functionality.
  • Support full keyboard access.
  • Provide enough time to complete tasks.
  • Support clear navigation.

Understandable

Content must be clear and predictable.
  • Use clear language and consistent patterns.
  • Keep interactions and layouts consistent.
  • Help users avoid and correct mistakes.

Robust

Content must work with current and future tools.
  • Support different browsers and assistive technologies.
  • Use clear semantic structure.

Design considerations

Visuals

Colour contrast

Use a minimum ratio of:
  • 4.5:1 for normal text.
  • 3:1 for large text.
Helpful tools include:

Do not rely on colour alone

Use icons or text alongside colour. Colour-only information or changes are hard to distinguish for users with colour blindness or limited vision.

Semantic colours

Use consistent meaning, such as green for success and red for errors.

Text size

Use the default body text size for primary content. Smaller text sizes should be used sparingly and only for secondary or less important information.

Interactions

Component states

Include focus, hover, active, selected, and disabled states to guide users.

Target size

Make clickable and touch targets at least 24 x 24 pixels, including any padding around the content.

Avoid unnecessary disabled states

Allow users to attempt actions and provide guidance instead of blocking interaction where possible. Or, hide the control until it becomes relevant.

Content

Clear language

Use simple, inclusive language. Grade 9 is a good starting point, but choose the reading level that best fits your users and the purpose of the content.

Headings and labels

Use structured headings to organize content.

Alternative text

Provide meaningful descriptions for images and accessible labels for links and buttons.

Multimedia

Provide captions or transcripts for all video and audio content. These offer a different way for users with hearing loss, low vision, or blindness to access content.

Time on task

  • Allow enough time to complete tasks, for example, completing tasks like one-time password validation, and other sessions that may expire.
  • Support saving and returning when tasks are longer or can be interrupted.

Input assistance and system feedback

Provide clear instructions, inline help, and error messages that explain what happened and how to fix it.

Device-friendly design

  • Ensure content remains usable when text is enlarged.
  • Design for multiple screen sizes and orientations.

Development considerations

ARIA (Accessible Rich Internet Applications)

  • Use ARIA to add accessibility information when native HTML is not enough.
  • Design System components include default ARIA roles and behaviours.

Headings and structure

  • Use a logical heading structure (`H1`, `H2`, etc.) to reflect page hierarchy.
  • Heading level does not need to match visual size. Heading structure matters more than styling.

Dynamic content

Dynamic updates must be accessible. Here are some ways to handle dynamic content for accessibility:

ARIA live regions

ARIA live regions let assistive technologies announce updates to page content without a full page reload. Use:
  • aria-live="polite" for non-urgent updates.
  • aria-live="assertive" for important updates.
  • aria-live="off" to disable announcements.
See the Callout and Notification components for examples of how updates are handled for assistive technology.

Form updates

Notify users when form changes or new fields appear. Use ARIA role="alert" or live regions to notify users when new questions show up.

Managing focus

Manage focus to help users understand where they are after dynamic content loads. For example:
  • Move focus to newly opened dialogs.
  • Return focus when dialogs close.
Provide a "Skip to content" link so keyboard and screen reader users can bypass repeated navigation:
  • Place it early in the DOM.
  • Make it visible on focus.
  • Move focus to the main content region when activated.

Keyboard navigation

Keyboard navigation is important for users who only use a keyboard to interact with websites and apps. It allows them to move around and do things without a mouse or touch screen.
  • Ensure all interactive elements work with keyboard input.
  • Provide a clear, visible focus indicator.

Optimizing performance

Faster loading and responsiveness improves accessibility for people on older devices, slower connections, or mobile networks.

Accessibility testing

Use manual testing (with screen readers) and automated tools.

Screen readers

Automated tools

Additional resources

Join design system drop-in hours to:
  • Get feedback on your service
  • Propose new components or patterns
  • Suggest updates to existing resources
  • Ask questions
  • Share feedback
Drop-in sessions are available to Government of Alberta product teams. Book time in drop in hours