Accessibility statement for Cloudax Connect

Cloudax Ltd

Last reviewed: 3 May 2026

1. Introduction

This accessibility statement applies to the Cloudax Connect web application (connect.cloud.ax) operated by Cloudax Ltd, a company registered in England and Wales (Company No. 14717183).

Cloudax Connect is committed to making its product accessible to as many people as possible, including disabled users, in line with the spirit of the Equality Act 2010 and the Web Content Accessibility Guidelines (WCAG) 2.2 AA.

We have designed Connect so you should be able to:

  • Navigate the entire app using only a keyboard.
  • Zoom in to 200% without text spilling off-screen.
  • Use a screen reader (we test against NVDA and VoiceOver).
  • Switch on a high-contrast theme, larger text, dyslexia-friendly font, reduced motion and reduced transparency from your account settings (Account → Accessibility).
  • Have your operating system’s reduced-motion and high-contrast preferences respected automatically.

AbilityNet has advice on making your device easier to use if you have a disability.

2. Compliance status

Cloudax Connect is partially compliant with the Web Content Accessibility Guidelines version 2.2 AA standard, due to the non-compliances and exemptions listed below.

3. Non-accessible content

The content listed below is non-accessible for the following reasons:

3.1 Non-compliance with the WCAG 2.2 AA standard

  • In the visual flow editor, drag-and-drop interactions do not yet have an equivalent keyboard alternative for placing nodes onto the canvas (WCAG 2.1.1). The canvas itself is keyboard-navigable (Tab to focus a node, arrow keys to move it, Delete to remove it, Cmd/Ctrl+Z to undo) and is announced as an application region with an accessible name, but adding a node currently requires a pointer. A keyboard fallback is on the roadmap.
  • Some live status updates (call timers, agent presence dots, campaign progress) are not yet wired into our globalaria-live announcer (WCAG 4.1.3). The infrastructure ships with this release: useAnnouncer() in src/components/live-announcer.tsx, and we are rolling it through the remaining real-time surfaces.
  • Heading hierarchy on a few large pages (the agent editor, the calls page) currently jumps from the (visually-hidden) h1 to h3/h4 without an explicit h2 for each tab. We are gradually promoting the most prominent section headings to h2 as we touch each page (WCAG 1.3.1, 2.4.6).
  • Some legacy icon-only buttons may still be missing an accessible name. We are continuing the sweep to add aria-label where needed (WCAG 4.1.2).

3.2 Disproportionate burden

We do not currently invoke any disproportionate-burden exemption.

3.3 Content outside the scope of accessibility regulations

  • Pre-recorded audio that is part of an agent’s call recording (this is third-party content, played back for reference and review purposes).

4. What we’re doing to improve accessibility

Accessibility is reviewed at the start of every quarter as part of our product roadmap. We:

  • Run automated accessibility checks (axe-core) against every pull request.
  • Test every new feature with keyboard-only navigation before release.
  • Maintain a built-in accessibility settings panel (Account → Accessibility) so users can opt into high contrast, larger text, reduced motion, dyslexia-friendly fonts, always-underlined links and reduced transparency without changing operating-system settings.
  • Build accessibility into our shared component primitives. inputs accept errorId / describedBy and propagate aria-invalid automatically; data tables emit scope="col" on headers and accept an aria-caption; buttons enforce a 24×24 CSS-pixel hit target (WCAG 2.2 SC 2.5.8); a global useAnnouncer() hook lets any feature push status updates into a polite or assertive ARIA live region.
  • Run a quarterly screen-reader smoke test (NVDA on Windows, VoiceOver on macOS & iOS) against the most-trafficked journeys: sign-in, accept-invite, navigate sidebar, search the command palette (⌘K), open the agent editor, start a campaign, browse call logs, change account settings.
  • Track all reported accessibility issues as P1 in our internal ticketing system.

5. Preparation of this accessibility statement

This statement was prepared on 3 May 2026 following an internal self-assessment of Cloudax Connect against the WCAG 2.2 AA standard. The assessment combined automated testing (axe-core, Lighthouse) with manual keyboard and screen-reader testing on the most-trafficked screens (Dashboard, Calls, Agents, Knowledge, Billing, Settings).

The statement was last reviewed on 3 May 2026 and is reviewed at least once every 12 months.

6. Feedback and contact information

If you find an accessibility problem on Cloudax Connect or need information in a different format, please tell us so we can fix it. The fastest way to reach the team is through the in-app support page (Support) or by emailing [email protected].

We aim to acknowledge accessibility reports within 2 working days and to fix or provide a workaround for high-impact issues within 10 working days.

7. Enforcement procedure

If you contact us with a complaint about the accessibility of Cloudax Connect and you’re not happy with the response, you can contact the Equality Advisory and Support Service (EASS).

Note: Cloudax Connect is a private business-to-business product, not a public-sector website, so it is not subject to the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. We follow that regulation’s WCAG 2.2 AA target as a voluntary benchmark.

8. Related policies