Accessibility

Accessibility ensures that web and mobile experiences work for everyone, regardless of ability or circumstance. By designing with accessibility in mind, we create products that are easier to use, more inclusive, and more resilient.

The benefits of accessible design

Supports equal access and participation
Enables people with a wide range of abilities to access content, complete tasks, and engage independently.
Aligns with accessibility standards and best practices
Encourages designs that meet recognised accessibility guidelines and expectations.
Creates clearer, more usable experiences for all users
Improves clarity, consistency, and usability across devices and contexts - benefiting everyone, not just users with disabilities.

Principles

At Releaf, we follow the POUR principles to guide how we design and build accessible digital experiences. These principles help ensure our products are usable, inclusive, and resilient across different users, devices, and technologies.

Perceivable
Content is presented in ways people can perceive, with appropriate text alternatives, sufficient colour contrast, and layouts that adapt to different screen sizes and zoom levels.
Operable
All functionality is usable with a keyboard, with visible focus, clear navigation, and interactions that support uninterrupted use.
Understandable
Interfaces behave in predictable ways, with clear labels, instructions, and helpful feedback when something goes wrong.
Robust
Our products work reliably across browsers, devices, and assistive technologies, and continue to do so as platforms evolve.

Standards

WCAG 2.1 AA WCAG 2.1 Level AA is used as a baseline reference for all products and design system components.
No keyboard traps All interactive elements must be operable via keyboard, with no keyboard traps.
Visible focus All interactive elements must have a visible focus indicator when navigated via keyboard.
Colour contrast meets requirements:
- Normal text: 4.5:1
- Large text (>= 24px or 18.66px bold): 3:1
- UI components and graphical objects: 3:1

Components

Every Releaf component should satisfy the following accessibility requirements:

Keyboard support

All interactive components are reachable via keyboard (e.g. Tab key).
Logical focus order matches the visual order.
No element requires a mouse to operate.
Use correct keyboard interactions for each role:
- Buttons: Enter / Space
- Links: Enter
- Menus/listboxes: arrow keys, Esc, typeahead where appropriate

Focus management

Focus must always be visible when navigating via keyboard.
On open/close of overlays (modals, popover, menu):
- Focus moves into the overlay on open.
- Focus returns to the trigger on close.
Modals must trap focus while open.

Semantics first

Prefer native HTML elements:

Use <button> for actions.
Use <a href> for navigation.
Use <input>, <select>, <textarea> for form controls.

If you must use a non-native element, you must implement:

Correct role
tabIndex management
Keyboard behaviours
ARIA attributes
Focus styles

Labels and names

All interactive elements must have an accessible name:

Visible label text (best)
- aria-label when no visible label is possible
- aria-labelledby to reference existing text

Avoid:

Placeholder only labels
Icon only buttons without an accessible name

Forms and validation

Labelling

Every field should have a <label> associated via htmlFor / id.
Hint text can use aria-describedby.

Errors

Errors should be:
- Specific
- Actionable
- Announced to screen readers
For individual fields:
- aria-invalid="true"
- aria-describedby should include the error message id

Colour

Don’t rely on colour alone. Any status indication (error/success/warning/info) must include:

Text (“Error”, “Success” etc)
An icon with text, not icon only
Or another non-colour indicator

We maintain contrast through design tokens.

Motion

Avoid large, distracting animations.
Ensure motion is not required to understand content.
Respect user preferences:
- prefers-reduced-motion: reduce

Content and headings

Use headings in order (h1 -> h2 -> h3 etc), do not skip levels.
Link text must describe the destination, avoid the use of “click here”.

Images and icons

For decorative images, use alt="".
For informative images, use meaningful alt text.
Icons used as controls must have:
- Accessible name (e.g. label text or aria-label)
- Focusable and keyboard operable if interactive

Overlays

role="dialog" or role="alertdialog" (when urgent)
aria-modal="true"
Accessible name aria-labelledby (preferred) or aria-label
Focus moved into dialog on open
Focus trapped inside
Close via:
- Close button
- Esc
Return focus to trigger on close

Tables

Use <table> for tabular data only.
Always include:
- <caption> where useful
- <th> for headers
- Proper scope attributes when needed