Thirst's Commitment to Accessibility

• Make every core learner experience accessible by default.
• Continuously test and improve accessibility across design, code, and content.
• Respond quickly to issues, with clear routes to request help or alternative formats.
• Share our progress openly.

• Web Content Accessibility Guidelines (WCAG) 2.1, Level AA
  These guidelines cover colour contrast, keyboard access, screen reader support, structure, error handling, media alternatives, and more.

• WAI-ARIA (Accessible Rich Internet Applications) used sparingly—only when native HTML isn’t enough.

• Platform conventions for iOS, Android, Windows, and macOS to make keyboard, touch, and assistive-tech patterns predictable.

Keyboard-first navigation

• Every interactive element is reachable and operable with a keyboard.

• Consistent Tab order and visible focus states make it clear where you are.

• Skip links let you jump straight to main content and navigation.

Built for assistive tech

• Clear heading hierarchy, landmarks, and roles help screen readers map pages accurately.

• Labelled controls, descriptive link text, and live-region announcements keep context and status changes easy to follow.

• Tested with common screen readers (e.g., NVDA, JAWS, VoiceOver) on modern browsers.

Readable by design

• AA-level colour contrast for text and UI controls.

• Supports user text spacing and browser zoom (up to 200%) without loss of content or functionality.

• Content reflows gracefully on small screens to avoid horizontal scrolling.

Media made accessible

• Captions for videos; transcripts for audio.

• Support for audio descriptions where needed.

• No auto-playing media with sound; playback controls are keyboard and screen-reader accessible.

Forms that don’t fail learners

• Clear, associated labels and instructions.

• Helpful error messages with suggestions to fix issues.

• Logical grouping and ordering for quizzes, enrolments, and feedback forms.

• Error prevention on important actions (e.g., confirmations before submission).

Motion, visuals, and preferences

• Respects reduced-motion preferences; no essential information is conveyed by colour alone.

• Icons and state changes always include a text alternative.

Mobile without compromise

• Responsive layouts with reflow and orientation support.

• Tap targets sized for touch; gestures never replace essential actions.

• Screen readers on iOS and Android are supported for core learner tasks.

• Learning experiences: course discovery, modules, assessments, certifications, and reporting dashboards for learners are designed to meet WCAG 2.1 AA.

• Notifications and to-dos: accessible from keyboard and screen readers; status changes are announced.

• Content authoring guidance: creators get prompts and tips for captions, alt text, headings, and contrast.

Note: Some older/legacy admin screens may not yet meet the same level; we’re modernising these areas as part of our ongoing roadmap.

• Design reviews: Accessibility checks at wireframe and component levels (contrast, focus order, semantics).

• Semantic HTML first: ARIA is added only when native elements can’t express the right role or state.

• Keyboard testing: Every new component and flow must be usable without a mouse.

• Screen reader passes: NVDA/JAWS (Windows) and VoiceOver (macOS/iOS) on supported browsers.

• Automated checks: axe and similar tooling integrated into CI to catch regressions early.

• Content guidelines: in-product nudges for alt text, captions, headings, link text, and language clarity.

• Continuous improvement: accessibility issues are triaged with priority; fixes are verified and regression-tested.

We support the two most recent versions of major browsers and operating systems commonly used in workplaces:

• Desktop browsers: Chrome, Microsoft Edge, Firefox, Safari

• Mobile browsers: Safari on iOS, Chrome on Android

• Screen readers: NVDA/JAWS with Chrome/Edge/Firefox on Windows; VoiceOver with Safari on macOS/iOS

If you use a different setup, we’ll do our best to help you access learning effectively.

Great platform accessibility pairs with accessible content. We encourage (and help) creators to:

• Provide captions/transcripts for media and avoid auto-play with sound.

• Use clear headings (H1–H3), lists, and descriptive link text (avoid “click here”).

• Add meaningful alt text for images or mark decorative images as such.

• Keep language concise; avoid jargon where possible.

• Check contrast for text over images or brand colours.

• Avoid conveying meaning by colour alone (add labels or patterns).

If you experience a barrier in Thirst or need an alternative format, tell us:

• Email: [email protected]

We aim to acknowledge accessibility reports within 2 business days and provide an initial resolution or plan within 10 business days. Urgent learning-access issues are prioritised.

If you or a member of your team requires a specific accommodation (for example, extended quiz time, alternative assessment formats, or support for a particular assistive technology), contact us at [email protected] and we’ll work with your administrator to help.

Thirst sometimes surfaces content or tools from third parties (e.g., embedded videos, external modules). While we encourage and guide partners to meet accessibility standards, their conformance may vary. If something blocks access, please let us know and we’ll help find an accessible alternative.

Thirst is designed to conform to WCAG 2.1 Level AA across core learner experiences. We continuously test, remediate, and improve accessibility, and we treat reported issues as product defects.

Last updated: 12 August 2025

We’re always learning, alongside your learners. If you have suggestions to make Thirst more accessible, we’d love to hear them: [email protected].