Accessibility

Our commitment to accessibility

Hi there. We’re Sensortree Pty. Ltd, the company that builds Clovo. We want everyone to be able to use Clovo — members booking a class, studio operators running their business, and visitors learning about us on the web. This statement describes our current accessibility posture, what we’re working on, and how to tell us when we get it wrong.

We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA across our products. WCAG is the international standard for digital accessibility, published by the World Wide Web Consortium (W3C), and is the same standard referenced by Australian, U.S., U.K., and EU public-sector procurement rules.

Scope of this statement

This statement applies to the digital experiences we build and operate:

The Clovo marketing website at clovo.au.

Clovo Studio, the studio-operator dashboard at studio.clovo.au.

Clovo Landing Pages, the studio-branded customer-facing pages we host on subdomains of clovo.au and on studios’ own domains.

The Clovo iOS app, available on the App Store.

The Clovo Android app, available on Google Play.

The Clovo WordPress Plugin and Clovo Live Activity widget.

It does not apply to content controlled by individual studios that use Clovo (covered separately under Studio-controlled content below) or to third-party services we integrate with (covered under Third-party content).

Conformance status

The Web Content Accessibility Guidelines (WCAG) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA. Conformance can also be described as fully conforms, partially conforms, or does not conform.

Clovo partially conforms with WCAG 2.2 Level AA. “Partially conforms” means that some parts of the content do not fully conform to the accessibility standard. We have chosen the more conservative wording deliberately: while substantial portions of our products meet AA, we have known gaps that we have not yet remediated, and we want to be honest about that rather than over-claim.

Conformance is not uniform across our products. The product summaries below were reviewed against current source code and available internal test records on 12 September 2026. The marketing website summary remains based on the 18 August 2026 review. This is not a formal third-party conformance audit and does not replace manual assistive-technology testing. Source changes may precede deployment or app-store availability; the version you use may differ.

Clovo marketing website (clovo.au) — substantially conforms with WCAG 2.2 Level AA. The current source includes a skip-to-main-content link, declared page language, visible keyboard-focus treatment, reduced-motion handling for site animation, and strong contrast for primary text. Known issues remain in the navigation mega-dropdown and a handful of secondary surfaces.

Clovo Studio dashboard (studio.clovo.au): partially conforms. Alongside skip links, visible keyboard focus, labelled forms and reduced-motion safeguards, recent work improves text, form-control and client-tag contrast in light and dark themes. Reports now provide expandable, keyboard-accessible data tables alongside charts, and multiple line and area series use different dash patterns. Focused automated checks found no accessibility violations on seven dashboard pages in both themes. These checks do not establish conformance across every page, interaction or assistive technology; the remaining verification gaps below still apply.

Clovo iOS app: partially conforms. Text scaling, text and icon status cues, shared VoiceOver labels on major cards, and a single underlying verification-code field are in place. The replacement decorative illustrations now respect Reduce Motion and are hidden from VoiceOver. Remaining review areas include motion elsewhere, map descriptions, Live Activity text scaling and progress announcements, and screen-reader coverage in purchase, shop and administration flows.

Clovo Android app: partially conforms. Many controls expose roles and state descriptions, and some sections identify headings to TalkBack. Recent fixes improve the visibility of plan prices, names and other inherited text in dark mode, including administration screens. Remaining review areas include touch targets, verification-code entry, heading coverage, localised descriptions, motion preferences and contrast with studio-supplied colours. Local source changes also replace several decorative animations with static icons; their availability in the published app has not been verified.

Detailed gap registers for each platform are maintained internally and used to prioritise accessibility work each release.

Standards we measure against

Web (clovo.au, Clovo Studio, Clovo Landing Pages): WCAG 2.2 Level AA.

iOS app: WCAG 2.2 Level AA, expressed through Apple’s Accessibility framework — VoiceOver, Dynamic Type, Reduce Motion, Reduce Transparency, Bold Text, and the Apple Human Interface Guidelines for Accessibility.

Android app: WCAG 2.2 Level AA, expressed through the Android Accessibility framework — TalkBack, font scaling, the Compose semantics modifier, the Material Design 3 accessibility guidance, and the Android Accessibility Developer Guidelines.

Compatibility with assistive technologies

Clovo is designed to work with recent versions of mainstream operating systems, browsers, and assistive technologies. The combinations below are our declared review matrix; this statement is not a full compatibility certification, and older configurations may work but are not actively supported.

Web — recent versions of Safari (macOS, iOS), Chrome (macOS, Windows, Android), Firefox (macOS, Windows), and Edge (Windows), reviewed with VoiceOver on macOS and iOS, NVDA on Windows, and TalkBack on Android.

iOS — supported versions of iOS as declared in the App Store listing, reviewed with VoiceOver, Dynamic Type, Reduce Motion, Reduce Transparency, Bold Text, Smart Invert, and external keyboards via Bluetooth.

Android — supported versions of Android as declared on the Google Play listing, reviewed with TalkBack, system font scaling, high-contrast text, colour inversion, Switch Access, and external keyboards.

Clovo is not designed to be compatible with technologies more than two major versions older than the current release.

Technical specifications

Accessibility of Clovo relies on the following technologies to work with the particular combination of web browser and any assistive technology or plugins installed on your device: HTML, CSS, JavaScript, JSON, ARIA, SVG, and platform-native APIs (UIKit/SwiftUI for iOS; Android View/Jetpack Compose for Android). These technologies are relied upon for conformance with the accessibility standards used.

Known limitations — Clovo marketing website

The website was rebuilt on a static-export pipeline in 2025 and most pages have been audited against WCAG 2.2 AA. Limitations we are aware of:

The platform and company navigation mega-dropdowns rely on the underlying UIKit framework’s default behaviour. The dropdown trigger does not yet expose aria-expanded state, and the dropdown surface does not yet carry an explicit menu role. Keyboard activation works; screen-reader announcements may be less verbose than ideal. Remediation is planned.

One token in our colour system, used for muted metadata and timestamps only, falls below the 4.5:1 contrast ratio against the page canvas. We have a sitewide rule that this token is restricted to non-essential supplementary text. We are auditing for any usage outside that rule.

Heading order is monotonic on primary pages but has gaps on a small number of secondary article and case-study templates. We are addressing these as part of a broader template review.

Marketing video that auto-plays as a background asset is decorative, plays muted, and is paused under the user’s prefers-reduced-motion preference. We are reviewing whether to add an explicit pause control.

Known limitations — Clovo Studio dashboard

Clovo Studio is a web application with a Tailwind CSS frontend. Limitations we are aware of:

A global :focus-visible pattern with a 2-pixel ring is now present, but component-specific focus styles and controls that opt out of the shared rule still need manual keyboard verification for contrast and prominence.

Shared action buttons have been raised to the WCAG 2.2 minimum target size in the current source. Sitewide verification remains open for specialised controls, native-looking controls, and public-facing surfaces; the 24×24 CSS-pixel minimum is therefore not claimed for every interactive element.

Global prefers-reduced-motion CSS safeguards are present for transitions and site animations. Some JavaScript-driven transitions and component-specific motion still require manual verification, so reduced-motion conformance is not claimed across every dashboard state. The September light- and dark-theme review includes focused contrast, keyboard and reflow checks, but real screen-reader testing and coverage of all populated routes, open controls and error states remain outstanding.

The heading hierarchy on a small number of admin pages skips levels (for example, jumping from h1 to h3). This is being corrected.

Known limitations — Clovo iOS app

The Clovo iOS app is built with SwiftUI and a small number of UIKit views. Limitations we are aware of:

The replacement empty-state, trial, growth and payment-success illustrations respect the iOS Reduce Motion setting and are hidden from VoiceOver as decorative content. Other transitions still need review across the app. Haptic feedback remains in several flows; this review does not establish how every flow responds to device accessibility and feedback preferences.

The reusable map view (used to show studio locations) does not define its own container-level accessibility label. Some screens add a descriptive label at the call site, and decorative map thumbnails are hidden or combined into their parent card, but the underlying map accessibility still depends on the screen that embeds it.

The main OTP code-entry field now owns input in one underlying text field with a “Verification code” label and spoken value; its six-character visual presentation is hidden from VoiceOver. This is an improvement over the former six-field implementation, but it still needs manual VoiceOver verification across validation, retry, and one-time-code autofill states.

The Live Activity uses a mixture of system text styles and fixed-size time text in its lock-screen and Dynamic Island layouts. Text scaling and layout at larger accessibility sizes still need device testing. Countdown progress indicators do not have explicit accessibility labels, so their announcements and the surrounding time information still need VoiceOver verification.

Adoption of the centralised VoiceOver labelling pattern is not complete: the major class, trainer, membership, location, super-credit-pass and usage-indicator components are annotated, but trial offers, direct-purchase flows, parts of the Member Shop and some admin-only screens are not yet covered.

Known limitations — Clovo Android app

The Clovo Android app is built with Kotlin and Jetpack Compose on Material 3. Limitations we are aware of:

Some section headings now use the Compose semantics { heading() } annotation, but heading semantics are not yet applied consistently across the Our Studio, Booking, Class Detail, account, and admin screens. TalkBack may therefore infer heading status from text size on some screens rather than receiving an explicit cue.

The 48-dp minimum interactive component size is not enforced sitewide via Modifier.minimumInteractiveComponentSize(). The back-navigation button on detail screens is 36 dp; some icon-only controls and page indicators are similarly below target.

A number of contentDescription, state, and click descriptions are hard-coded English strings rather than localised string resources. TalkBack will therefore announce these in English even when the device is set to another supported language.

Some motion consults the system animator-duration scale; for example, the device-tilt effect returns a still state when animations are disabled. The local source reviewed on 12 September replaces the decorative trial, empty-state and sign-in and purchase-success animations with static icons. Those changes are not yet committed in the reviewed checkout and have not been verified in the published app. Other Compose transitions still need testing with system animations reduced or disabled.

The custom OTP field does not expose a container-level group for TalkBack, so each digit is announced as an independent input rather than as a single six-digit code field.

Recent changes correct inherited foreground colours in dark mode, including plan prices and administration content. Chip and card backgrounds still need rendered contrast checks against every foreground and studio-supplied colour combination in both themes.

Studio-controlled (user-generated) content

Clovo is a platform: studios that use Clovo to run their business control a meaningful portion of what their members and prospective members see. The accessibility of that content is, by design, the responsibility of the studio operator.

Content under studio control includes — but is not limited to — the studio name; the studio logo and other uploaded imagery; brand primary and secondary colours used on customer-facing pages; class names, descriptions, and class-type icons; trainer names, photographs, biographies, and titles; location names and descriptions; membership plan, credit-pack, and trial offer names and descriptions; Member Shop product names, images, and descriptions; announcements and welcome-email copy; and liability waiver content.

Clovo provides accessible scaffolding (semantic structure, focus management, font scaling, motion respect, screen-reader compatibility), but we cannot guarantee that the content a studio supplies meets WCAG 2.2 Level AA. For example: a studio-supplied logo may be presented without alt text in places where alt text would be ideal; a studio’s chosen brand colours may produce insufficient contrast against white or against another brand colour; a class or membership name may use abbreviations or punctuation that screen readers cannot pronounce sensibly; a studio image may convey information that is not present in the accompanying text.

If you encounter a specific access barrier on a studio-branded page, we encourage you to contact that studio directly. If the barrier is in Clovo’s scaffolding rather than the studio’s content, please contact us using the details below — we will help identify which is which.

Guidance for studio operators

If you operate a studio on Clovo, the items below give you a quick checklist for keeping your customer-facing content accessible. Following them is the easiest way to make sure your members can book and pay regardless of how they interact with the web.

Brand colours: choose primary and secondary brand colours that pass a 4.5:1 contrast ratio against white and against each other. The branding settings page in Clovo Studio shows you a live contrast indicator next to each colour picker, with Good (≥ 4.5:1), Fair (≥ 3:1) and Low (< 3:1) badges and the actual ratio against white and dark backgrounds — aim for Good. The indicator does not check your primary against your secondary, or text on your branded chips and overlays, so if those combinations matter to you, double-check with a free online WCAG contrast checker. If you’re unsure, dark colours on white or white on dark colours are reliably safe.

Logos: upload a logo with a transparent or solid background that doesn’t depend on a particular page colour to be readable. SVG and high-resolution PNG are best.

Imagery: when you upload trainer photos, class images or shop product photos, use clear, well-lit images. Avoid important text baked into images — text inside images is invisible to screen readers and zooms poorly.

Class and product names: write them out in plain language. Avoid all-caps, leetspeak, decorative characters, or emoji as load-bearing meaning. “Reformer Pilates — Beginners” is read better than “REFORMER!! 🔥 BEGINNERS”.

Descriptions: keep paragraphs short. Lead with what the class is and who it’s for. If the class has a duration, intensity level, or equipment requirement, state it in words rather than relying on icons alone.

Trainer bios: include the trainer’s qualifications and approach in text. Don’t put their name in an image.

Welcome emails and announcements: when you customise email or in-app announcements, write the link text to describe its destination (“Read our cancellation policy”, not “Click here”).

Liability waivers: write waivers in plain language at a sensible reading level.

If your studio is itself subject to public-sector accessibility obligations (for example, you’re a council-run leisure centre or a registered NDIS provider), you remain responsible for meeting those obligations on the content you supply through Clovo. We’re happy to help — get in touch.

Third-party content

Some parts of Clovo are powered by third-party services. Their accessibility is governed by their own statements and is outside our direct control.

Stripe — used for payment processing. Card-entry forms and Stripe-hosted checkout flows are governed by Stripe’s accessibility statement.

Apple Maps and Google Maps — used to display studio locations. Map content and pan/zoom interactions are governed by the underlying platform.

App Store and Google Play — used to distribute the Clovo iOS and Android apps. The store listings themselves are governed by Apple and Google.

Email and SMS providers — used to deliver booking notifications, password resets, and marketing communications.

Where third-party content is essential to a flow (for example, payment) we test that the flow is operable end-to-end with a screen reader and keyboard, but we cannot independently warrant the accessibility of the third-party surface.

How we test and assess accessibility

Our accessibility work is a mix of automated checks, manual testing, and design-system discipline.

Design-system level — colour tokens, focus styles, typography, and spacing are defined as design tokens with documented accessibility intent. Adding a new component requires meeting the token rules, which encode accessibility decisions (for example, focus rings, text-on-surface contrast pairs).

Automated checks — we use static analysis and accessibility linters during development and CI.

Manual review areas — keyboard-only navigation; screen-reader smoke tests with VoiceOver, NVDA, and TalkBack on critical flows (sign up, sign in, browse studios, book a class, manage a membership, take payment); zoom and reflow at 200% and at the largest accessibility text size each platform offers; reduce-motion and high-contrast modes. The source review recorded above does not by itself certify that every one of these checks has passed on every route and device.

External assessment — we have not yet commissioned an independent third-party accessibility conformance audit. We plan to do so once the open remediation items above are closed.

This statement was prepared on 18 August 2026 and updated on 12 September 2026 by Sensortree Pty. Ltd. The update reflects a source-level review of Clovo Studio, iOS and Android changes and the recorded dashboard dark-mode accessibility checks. It does not represent a fresh whole-product audit or confirmation of app-store release status.

Feedback and reporting a barrier

We welcome your feedback on the accessibility of Clovo. If you encounter a barrier, or if there’s an assistive technology or workflow we should be supporting better, please tell us.

Email: hello@clovo.au.

Web: contact form on clovo.au/support.

Postal: please request a postal address by email and we will provide one.

Please include in your message the name of the page, screen, or feature; the device, operating system, and assistive technology you were using; and a description of the barrier or what didn’t work as expected. Screenshots, screen recordings, or descriptions of the steps you took are very helpful.

We aim to acknowledge accessibility feedback within five business days and to provide a substantive response — including, where appropriate, a remediation plan or workaround — within twenty business days. If a fix is going to take longer than that, we’ll tell you why and give you a realistic timeframe.

Formal complaints and enforcement

If you’re not satisfied with how we’ve responded to your accessibility feedback, you have the right to make a formal complaint to a regulatory authority.

In Australia, the Disability Discrimination Act 1992 (Cth) prohibits disability discrimination in the provision of goods, services, and facilities, including digital ones. Complaints can be lodged with the Australian Human Rights Commission at humanrights.gov.au.

If you’re based outside Australia, the equivalent body in your country may also be able to help — for example, the Equality and Human Rights Commission in the United Kingdom, the U.S. Department of Justice in the United States, or your national equality body in the European Union.

Continuous improvement

This statement is a living document. We review it at least every twelve months and whenever a major release of any of our products materially changes its accessibility posture. The known-limitations sections above are the items currently on our radar; we will update them as we close issues and as new ones are identified.

If you’ve read this far, thank you. Accessibility is a long, plural commitment, not a one-off project, and we take both the gaps we’re honest about above and the work to close them seriously.