Skip to main content
Audact
See the offer

Accessibility statement

Last updated: 27 August 2026

1. Our commitment

AUDACT AI LIMITED (Ireland, CRO 822514) is committed to making its website accessible to the widest possible audience, including users with disabilities. This statement applies to audact.ai and all its sub-routes.

We aim to meet the requirements of the European Accessibility Act (Directive (EU) 2019/882) and the harmonised standard EN 301 549 V3.2.1, which references the Web Content Accessibility Guidelines (WCAG) 2.1 at conformance level AA.

2. Conformance status

The Audact website is partially conformant with WCAG 2.1 level AA. Partially conformant means that some parts of the content do not fully conform to the accessibility standard.

What keeps it at partial is named in section 3: the enterprise contact form does not mark the field that caused an error, autocomplete hints are missing from the select lists and from the no-JavaScript variant of the agency-application form, and no test with a screen reader has been carried out. No third-party audit has been carried out either.

We are actively addressing the known issues listed below and aim to be fully conformant by Q4 2026. What has been measured, control by control, is on the short accessibility page; that page and this one say the same thing.

3. Known issues

  • The enterprise contact form reports an error in a single message and does not mark the field that caused it. Measured on 27 August 2026 at 1440 px: submitting /for-enterprise with its required fields empty leaves no field carrying aria-invalid and no field pointing at a message with aria-describedby. Four other forms on this site do mark the field, the agency-application form among them since today, which is what makes this one a gap rather than a house style.
  • Autocomplete hints are present on the text fields — the agency name, the email address and, on the enterprise form, the contact name — and absent from the select lists. The no-JavaScript variant of the application form carries none at all.
  • No test with a screen reader has been carried out. The expanded and collapsed state of the mobile menu, the navigation groups and the collapsible part of the application form is set and does change — measured in Chromium — but whether every screen reader announces it is untested.
  • Seven locales declared a language they did not render (measured 24–25 September 2026).
  • The first keyboard stop after the skip link could sit behind the sticky header (measured 24–25 September 2026).

Four items that stood on this list no longer hold. They are recorded here rather than deleted, so that the change is visible and dated.

Resolved — the agency-application form now marks the field that caused the error. Measured on 27 August 2026 in Chromium at 1440 and 390 px, in English, German and Dutch: submitting with the agency name, the work email or the vertical left empty leaves each of those three fields carrying aria-invalid, pointing with aria-describedby at its own message, which renders with role=alert and aria-live=assertive; the focus moves to the first of them. An entry that is not an email address produces the second message rather than the first, so both branches were measured. The read-out was proved first on the Compliance Pulse signup, a form that already had it, and the same read-out reports nothing on the enterprise contact form, which is where this gap now stands in the list above.

Resolved — live-region announcements on the agency-application form. This list said they were being added; they were already there. An error renders with role=alert and aria-live=assertive, and the confirmation with role=status and aria-live=polite.

Resolved — a static alternative for visitors who prefer reduced motion. Under prefers-reduced-motion: reduce, each of the five canvases on the home page shows two states in 1.8 seconds: blank, then final. Without the preference two of them pass through five and seven, which is what makes the first figure mean anything.

Resolved — contrast on small body text. The palette was revised. 176 English pages at 1440 px, and 17 pages in three languages at 1440 and 390 px, show no text below its contrast threshold. That measurement does not cover the platform dashboard, and it does not separately cover the seven locales that fall back to English. Re-measured on 28 August 2026, and it had missed one thing. Lighthouse found three colours below the threshold on /en/demos — a page that was inside those 176. The palette was not at fault: a 40% opacity layer over the not-yet-reached rows of two demo timelines composited #7C8DA6 down to #384357 (1.87:1), #B2B9C4 to #4D5563 (2.48:1) and #E2E8F0 to #606875 (3.32:1). The earlier sweep read the colour set on the text and not the colour the screen shows, and its positive control was an injected low-contrast line — which carries no opacity above it and could therefore never have caught this. The opacity is gone; those rows are now held back by colour alone, at #7C8DA6 on #0A1223, which is 5.53:1. From 28 August 2026 contrast is measured with the opacity of every ancestor composited in.

4. Feedback & contact

If you experience an accessibility barrier on our website or have a question about this statement, please email accessibility@audact.ai.

We aim to acknowledge your message within 5 business days and provide a substantive response within 30 days.

5. Enforcement procedure

If you are dissatisfied with our response, you may file a complaint with the supervisory authority in your EU Member State. In Germany, this is the Schlichtungsstelle nach dem Behindertengleichstellungsgesetz. In the Netherlands, the College voor de Rechten van de Mens oversees accessibility complaints.

6. Technical specifications

Accessibility of the Audact website relies on the following technologies: HTML, WAI-ARIA, CSS, and JavaScript. These technologies are relied upon for conformance with the accessibility standards used.

7. Assessment approach

Audact assesses the accessibility of this website with browser measurements and manual review against the WCAG level AA criteria: contrast measured against the background actually rendered behind each text, focus visibility per operable element, landmark and skip-link structure, label association per form field, and animation frames counted under both motion preferences. Lighthouse runs against the production build.

axe-core, WAVE and Pa11y appear in the audit plan in section 8 and are not in use today — they are not dependencies of this site.

This is a self-assessment. No third-party audit has been carried out, and no auditor has been engaged; the first is planned for Q4 2026 and the plan is set out below.

8. WCAG 2.2 AA formal audit roadmap

We are upgrading our accessibility target from WCAG 2.1 AA to WCAG 2.2 AA with a formal third-party audit programme.

  • Target completion: Q4 2026 (full WCAG 2.2 AA conformance for the marketing site; customer portal follows in Q1-Q2 2027).
  • Scope: a 10-15 page representative sample first (homepage, /for-agencies, /pricing, /trust, /receipt-explorer, the agency-application form, plus key /compliance and /legal pages), then expanding to a full audit of all public routes.
  • Automated tooling first: axe-core (CI integration), WAVE, Pa11y, and Lighthouse accessibility audits before manual review.
  • Manual screen-reader testing: NVDA (Windows / Firefox), JAWS (Windows / Chrome), and VoiceOver (macOS / Safari and iOS) on the core conversion flow.
  • Keyboard-only and reduced-motion regression sweeps on every release.

We will publish each audit report’s executive summary on this page once complete.

Related documents