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.
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.
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.
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.
Skip to content link
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.
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
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